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

From: Jiangsheng <[email-masked]>
Date: Thu, 16 Jun 2011 01:07:21 +0000

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

---

From: "George, Wesley" <[email-masked]>
Date: Tue, 21 Jun 2011 13:24:21 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Jiangsheng
Sent: Wednesday, June 15, 2011 9:07 PM
To: [email-masked]
Subject: [renum] Work plan towards IETF 81 and contributions needed

Hi, all,

Sheng
_______________________________________________
renum mailing list
[email-masked]
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.

---

From: Jiangsheng <[email-masked]>
Date: Wed, 22 Jun 2011 09:56:40 +0000

George,

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

Sheng

> From: George, Wesley [mailto:[email-masked]]
> Sent: Wednesday, June 22, 2011 1:24 AM
> To: Jiangsheng; [email-masked]
> Subject: RE: Work plan towards IETF 81 and contributions needed
> 
> 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.
> 
>       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
 
> 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.
> 
> 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.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Jun 2011 00:12:11 +1200

On 2011-06-22 21:56, Jiangsheng wrote:
...
> 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…

I'm not sure we can standardise anything for this but we can certainly write
BCP-type recommendations that configuration data for static addresses SHOULD
be kept in a central repository. I wonder if there can't be a protocol mechanism
in fact: get a dynamic address, ask a configuration server "I am server1.example.com,
please tell me my static address".

    Brian

---

From: "George, Wesley" <[email-masked]>
Date: Wed, 22 Jun 2011 15:34:26 -0400

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: Wednesday, June 22, 2011 8:12 AM
To: Jiangsheng
Cc: George, Wesley; [email-masked]
Subject: Re: [renum] Work plan towards IETF 81 and contributions needed

WEG> So in my mind, making renumbering easier falls into a couple of categories:
1) documenting how to leverage dynamic protocols to the maximum extent when renumbering is required
2) identifying gaps and proposing solutions in dynamic protocols to make renumbering even easier
3) documenting how to limit the places where static addresses must be used (vs FQDN or autoconf)
4) Identifying gaps and proposing solutions in other areas to reduce the number of places that static addresses are required
5) documenting any gaps in 4192 to make renumbering easier for a statically-numbered set of hosts and potentially identifying a problem statement for improving renumbering for static

I admit that #4 and 5 are non-trival, but I think they are still within our scope. We're not solving much of the renumbering problem if we limit ourselves to dynamically-addressed devices. Perhaps in order to break this into manageable chunks, this draft and its companion stays focused specifically on dynamic and another set of drafts are spun to cover static? I'm not sure how much overlap there would be, as if it's a lot it makes less sense to have separate drafts instead of separate sections of these common drafts...

---

From: Tim Chown <[email-masked]>
Date: Fri, 24 Jun 2011 16:22:59 +0100

> I admit that #4 and 5 are non-trival, but I think they are still within our scope. We're not solving much of the renumbering problem if we limit ourselves to dynamically-addressed devices. Perhaps…

I think this type of analysis is useful.  

Our charter focuses on producing two deliverables, one being an enterprise scenario text that includes documentation of existing practices and capabilities (which would include points 1 and 3 above), the other being a gap analysis, which can also draw on RFC4192 and RFC5877 (and include points 2, 4 and 5 above).

We should have a WG slot in Quebec, and the deadline for -00 drafts is Monday week (4th July).  I believe Sheng is working towards splitting his previous draft into starting points for the two new texts, and so I'd encourage any interested authors or contributors to contact Sheng to work on that over the next few days.   We can then use the meeting slot to have a good discussion about those texts, and hopefully generate pointers and ideas for their further development after the meeting.

Tim

---

From: "Leo Liu(bing)" <[email-masked]>
Date: Thu, 30 Jun 2011 02:24:26 +0000

Hi, Tim

Thanks for your suggestion. And thanks for George's comments again.
Replies are inline.

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Tim Chown
发送时间: 2011年6月24日 23:23
收件人: [email-masked]
主题: Re: [renum] Work plan towards IETF 81 and contributions needed

>Our charter focuses on producing two deliverables, one being an enterprise scenario text that includes documentation of existing practices and capabilities (which would include points 1 and 3 above)…

We've included George's comments as a sub-clause in "Address Configuration Gaps" section in the gap document, point 3, 4, and 5 could be a good initial discussion clue. For the point 1, 2, we've already did some considerations in the early guideline draft, which will be inherited in the gap analysis. Many thanks to George again for his valuable comments.

We'll submit the gap analysis 00 version on Monday. And any comments to the 00 version would be expected eagerly so that we may produce a 01 version before the cut-off date. 

Tim