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 <prefix>:0:<AS:NO>:<instance> Where: <prefix> is the IPv6 /64 prefix <AS:NO> is the 32-bit AS Number (0:ASN for 16 bit ASNs) <instance> is a member-chosen instance number for that particular connection <instance> 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:<instance>/64 TDS: 2001:504:27::1055:<instance>/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::<AS:NO>:<i> where <i> 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