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

George,

Thanks for your valuable comments. Please see my replies in lines.

Sheng

> -----Original Message-----
> From: George, Wesley [mailto:wesley.george@twcable.com]
> Sent: Wednesday, June 22, 2011 1:24 AM
> To: Jiangsheng; renum@ietf.org
> Subject: RE: Work plan towards IETF 81 and contributions needed
> 
> 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]." 

Will do in the new draft-jiang-6renum-enterprise.

> 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 am not sure we can cover this. If Ipv6 renumbering, the basic idea is the network change the prefix, then all addresses need to be changed accordingly. Statically assigned addresses seems not fit in this scenarios. Or I need more explanation.

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

Have added RFC2874 "DNS Extensions to Support IPv6 Address Aggregation and Renumbering" in the new draft

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

Will add more clarification.

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

En... It seems make sense. However, I am not sure to put section 2.2 into section 2.3. This contents are worth an independent section with a changed title or more clarification text. 

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

Good point. Will add some text into the new version. However, the gaps will be addressed in a separated document.

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

Will address this in 6renum gap analysis draft.

> 2.4 - embedded RP needs an informative reference to RFC 3956

Will add this.

Thanks,

Sheng

> 
> Thanks,
> 
> Wes George
> 
> -----Original Message-----
> From: renum-bounces@ietf.org [mailto:renum-bounces@ietf.org] On Behalf
> Of Jiangsheng
> Sent: Wednesday, June 15, 2011 9:07 PM
> To: renum@ietf.org
> 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
> renum@ietf.org
> 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.