>
> First task.
>
> We've pretty much settled on IPv4 addressing the same keeping the
> last octet. We need to settle on IPv6 addressing.
>
> Owen Delong has suggested that we embed the ASN and switch & port into
> the IPv6 address, others have said it isn't needed. We have such large
> space, we can do just about any scheme. I'd just have to precalculate
> each IPv6 address and send it off to everybody.
>
Almost... What I suggested was embedding the ASN. Nothing about switch/port
because that could be variable and you don't want to have to redo all your
peering just for a port move.
I suggested :0::
Where:
is the IPv6 /64 prefix
is the 32-bit AS Number (0:ASN for 16 bit ASNs)
is a member-chosen instance number for that
particular connection
would only really matter for members that have more than one
connection, and most would likely choose 0 or 1 for their first (or only)
connection and count up from there.
> We'll just start by taking the first IPv6 network, leaving the others
> in reserve.
>
I support this.
> Would it be nice to have something like 2001:504:27:0:0:1e49:1:3/64
> (in particular to identify ipHouse), vs. 2001:504:27:0:0:1055:1:4/64
> (to identify TDS?).
>
As suggested above, I'd rather see it be like:
ipHouse: 2001:504:27::1e49:/64
TDS: 2001:504:27::1055:/64
I think 16 bits is more than enough to describe the instance number.
You run into a potential problem (though not particularly important in this
case) where 32-bit ASNs could create addresses with 1s in the first 12 bits
of the suffix (which is theoretically bad form for static assignments in IPv6)
if you put non-ASN info in the last 2 quartets. That's one of the reasons I
suggest putting 0 in the first quartet and putting the ASN in the next 2
quartets followed by a 16-bit instance number in the last quartet.
> Or just match up how things are now with 2001:504:27:0::3 & ::4?
> (the existing IP addresses started out with port # at the end, but of
> course things had to change up as we went along, the port #s would stay
> correct on IPv6).
>
> Do the same with the route servers? Or make them shorter? 2001:504:27::1?
Presumably the route servers have an ASN. I'd make them 2001:504:27:::
where would either be {0,1} or {1,2} depending on what fraction of the group
prefers to count from 1 vs. count from 0.
>
>
> Second task.
> Scheduling.
>
> In order for people to start announcing prefixes with nexthop
> addresses as the new IPs, everybody needs to at least have the new
> prefix on as a secondary or another IP address on their MICE facing
> interfaces to reach them. Not everybody has done that yet, although
> many did do the IPv4 portion already.
>
> How about we set a drop-dead due date of 10/1/2012 for allowing
> everybody to do this in whatever maintenance window they see
> appropriate. 3 weeks out is pretty reasonable I think, but I don't
> know other's policies on scheduling their windows if they want to
> minimize whatever impact this causes (minimal I think).
>
Seems reasonable to me.
>
> Third task.
> BGP cutover.
>
> The route servers are listening now on 206.108.255.1 & 206.108.255.2 as
> well as the old IPs. BIRD hasn't been restarted yet though.
> I plan on creating new BIRD configs with the router-id in 206.108.255.0
> & 2001:504:27::/64 for every member.
>
> This should allow any member past the secondary IP day to change to
> connect to the new IP, announce as their new IP, and have their
> prefixes be reachable by all members. This can happen on their
> schedule at any time after the 10/1/2012 date.
>
Seems reasonable.
> Bilateral peering members can update between themselves at any point
> in time once they have their IP assignments if their gear supports
> that level of control, but multilateral peering to the route servers
> should still be announcing the old IP addresses as next-hop for now
> until after the 10/1/2012 date.
>
Agreed.
>
> Final task.
> Final cleanup of old IP addressing.
>
> As people cutover after the 10/1/2012 date, I expect them to swap
> primary and secondary IP addresses in their MICE facing interfaces
> (assuming cisco config here) but until everybody is cutover,
> members will probably want to retain a secondary in the old range in
> order to reach people that haven't changed their BGP setup yet.
>
Hopefully most people did the primary/secondary swap during the
switch cutover and put the new IPv4 address in as secondary.
I don't believe this is an issue for IPv6.
> Should we set a date of 1/1/2013 as final cleanup and IP address turn
> in day back to Airstream? After that, nobody should be announcing any
> prefixes with next hop in the old IP address range. Members should
> make sure that they remove the secondary IP address after this date on
> whatever maintenance window is required (again should be minimal
> impact as this is now the secondary IP address).
>
I think 1/1/2013 is awfully far out and also problematic due to the intersection
with holidays, etc. I would suggest 11/15/2012 as a much more realistic date
because it gets things done with some room to address issues before
things start heading into the holiday-dense period from Thanksgiving through
new-years.
How about breaking this up a little-bit...
11/15/2012 is the day we turn off the old addresses on the route servers
and expect everyone to have turned down all their peering sessions on the
old addresses.
1/1/2013 is the day we hand the addresses back to Air Stream.
Between 11/15/2012 and 1/1/2013, we should occasionally ping-sweep
and harass any stragglers that haven't turned off the AirStream addresses
yet.
> Failure to remove the secondary could impact Airstream in the future
> if they reassign these IP blocks, so this should be completed at some point.
>
Yes, we should be good neighbors.
>
>
> Questions?
>
> Are their any concerns or questions about this schedule and plan?
See above in-line.
> Anything anybody would do differently?
IBID
> Are the schedule dates reasonable?
Mostly. See above suggested tweaks.
Thanks for writing this up and spearheading this, Doug.
Owen
########################################################################
To unsubscribe from the MICE-DISCUSS list, click the following link:
http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
