> 
> 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