Re: [renum] Work plan towards IETF 81 and contributions needed

["George, Wesley" <[e-mail]>]

I have reviewed draft-jiang-ipv6-site-renum-guideline and have some comments.

Section 2.1 -
I would remove "DHCPv6 reconfiguration "doesn't appear to be widely used for bulk renumbering purposes" [RFC5887]." In reality, none of these things are really used for bulk renumbering today. What we're supposed to be talking about is how to make that easier. Also, right now, this document favors SLAAC over DHCPv6. The reality is that no one is likely to choose SLAAC over DHCPv6 simply because of renumbering. Other factors will contribute to that decision, so it's better for us to simply discuss how to manage it most effectively with each. Discussing pros and cons for each is appropriate, but we need to be more even-handed in discussing how to manage renumbering regardless of which technology is used.

There is currently little or no discussion regarding renumbering of things with statically assigned addresses.
I think that there are probably two types of hosts - those who think that they need a static address, and those who actually do. It would be a good idea to discuss some of the places where typically static addresses are used, but could be eliminated in favor of dynamic addressing vs the places where it's likely static addresses are still required. You make reference to using dynamic DNS updates, but don't really draw the conclusion that this can be used to reduce dependence on statically-configured addresses.
In the case of static addressing, there are probably some pointers that can be made regarding how addresses are generated and allocated to ease renumbering, such as using a consistent addressing scheme across sites and purposes, so that if the network prefix must change, it's a simple find and replace of the upper bits. This may not work in all cases, because sometimes the size of the network prefix changes or there are other major changes to the address structure, but it may still be worth being discussed here.

DNS - it's not enough to simply say "It is recommended that the site have an automatic and systematic
      procedure for updating/synchronising its DNS records" without making a recommendation as to how this might be implemented - point to a BCP (if exist, or one is needed) for doing this on common platforms. Otherwise this is in a similar category to the assertion that making other global changes to your network configuration is easier if you have an automated tool to push configuration out to your network. Nice to know, but not actually helpful to the discussion.

Miscellaneous-
What does the following mean? "Addresses should not be used to configure network connectivity, such as tunnels." That you should point tunnel endpoints to FQDNs instead of IP addresses? Why specifically mention tunnels? What do you mean by configure network connectivity?


2.2 -
This section has several good recommendations, but they are not by any means recommendations to implement by default in a network. I see all of these as temporary changes made just prior to renumbering in order to manage a pending renumber. Recommending them as temporary changes would go a long way to reduce the cost/burden tradeoff in using any of these things to ease a renumber. In other words, all of section 2.2 probably belongs in section 2.3.

2.3 - This takes a very limited view of renumbering and treats it still as a very light-switch or flag day event. Remember that because IPv6 is capable of assigning multiple addresses to the same interface, it is quite possible to assign a new address, update the external pointers (DNS, configuration, etc), and then remove the old address. It's even possible to do this for things like BGP sessions (though today it requires standing up a duplicate BGP session, which has an opportunity for optimization as a part of this effort). Depending on the network, it may be possible to do this over a long enough period of time that impact to in-flight traffic is minimal, as sessions naturally end and are restarted using the new configuration, leases age out, etc.
The informative references list RFC4192, but the text does not mention it at all. If anything this should be taking that RFC and building on it - pointing out additional gaps in that process, places where the protocols could be updated to correct problems today, etc.

It may even make sense to recommend as a part of section 4/gap analysis that DHCPv6 and SLAAC supports this type of make-before-break provisioning, where it advises the host that there is a new prefix/address which is ADDED to the existing address rather than replacing it, and then gives the host time to make the migration (update its preferences for each prefix, signal upstream applications, etc) at a point that is appropriate for it before forcing the switch while the host may be in mid-communication. Even if this happens gradually over the hundreds of flows moving through a host, it will allow a reduction in the amount of traffic impact caused by the eventual removal of the old prefix.

2.4 - embedded RP needs an informative reference to RFC 3956


Thanks,

Wes George

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Jiangsheng
Sent: Wednesday, June 15, 2011 9:07 PM
To: [e-mail]
Subject: [renum] Work plan towards IETF 81 and contributions needed

Hi, all,

Since 6renum WG is chartered, we are now starting the preparation towards IETF 81. As described in the charter, "RFC 4192, RFC 5887, and draft-jiang-ipv6-site-renum-guideline are starting points for this work."

The current work plan is to split draft-jiang-ipv6-site-renum-guideline into two drafts according to the WG charter. Draft-jiang-6renum-enterprise would include newly-added enterprise renumbering scenario description and considerations/guidelines for enterprise renumbering events (mainly section 2 of draft-jiang-ipv6-site-renum-guideline). Draft-liu-6renum-gap-analysis would take the section 4 of draft-jiang-ipv6-site-renum-guideline "Requests to extend current protocol" as the start point of gap analysis and expand it.

Please read and comments on draft-jiang-ipv6-site-renum-guideline while we are working on the new drafts. We have a short time (less than three weeks before 00 version cut-off date). Any contributions/input are welcome. We are open to take additional contributors/authors.

Many thanks and best regards,

Sheng
_______________________________________________
renum mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/renum

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.