Subject: [renum] comments on draft-jiang-6renum-enterprise-00

From: "George, Wesley" <[email-masked]>
Date: Tue, 19 Jul 2011 15:43:36 -0400

2 - I don't think that it's necessary to assume that the *network* is IPv6-only, or to call dual-stack a complicated IPv4/IPv6 coexisting scenario. Your current language makes this work irrelevant for 99.9% of the networks out there today (because they are either dual-stack or IPv4-only), which I think is probably not what we're going for when we say that IPv4 is not in scope.
I understand what you're trying to say with the comment "logical IPv6 plane is independent from IPv4" but I think there's probably a clearer way to say it.
In other words, it's perfectly acceptable to have a dual-stack network and leverage these recommendations. You just simply need to say that IPv4 renumbering is not directly covered by this work and if a network is dual-stack, IPv4 renumbering will have to be treated separately. Consider the fact that IPv4 and IPv6 allocations are often different, and while a topology change may trigger renumbering for both address-families, it is also possible that a dual-stack network has other events that trigger a renumbering event on just one of  multiple address-families. You could possibly identify which of these techniques are IP version-agnostic and therefore applicable to IPv4, but note that the further gap analysis will not focus on improving IPv4 renumbering where it diverges from IPv6.

3- I would recommend reviewing and categorizing the renumbering reasons in RFC2071 specifically in a subsequent revision, rather than your current generalization that some are out of date/not suitable. For that matter, should this document formally update RFC2071?

3.1/3.2 - Right now you have this somewhat limited to PA space -  you don't actually say that, but your use cases/examples are all making that assumption, and I doubt that was your intent.
Depending on how successful RIRs have been at doing sparse allocations, it's quite possible that if a network needs to request a larger block (assuming that they have a PI allocation) from their RIR, they may receive an entirely new block rather than simply having their existing block's bit-length changed. This will trigger a renumber similar to a switch to a new ISP.

4.1 Address types -
Does this draft need to discuss the common reasons for using statically-defined addresses, and perhaps identify some ways to reduce? You mention FQDN and DNS updates elsewhere in the document, but it may be useful to explicitly note that here. Also, I know you have a  placeholder entry for that in 5.3 of the gap analysis draft, but I would think that it would start here with things that can be done (BCP) today...

while this isn't necessarily a current use of ULA, http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00 is specifying use of ULA in the Smart Grid

5 - I don't understand what that first item "manual or script-driven procedures..." means/refers to - can you attempt to clarify in the next revision?
Also, doesn't most of this section belong in the gap-analysis draft?

Thanks,

Wes George
speaking as individual contributor

________________________________
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, 20 Jul 2011 06:51:31 +0000

Hi, George,

Thanks for your valuable comments. See my reply in lines.

Sheng

From: [email-masked] [mailto:[email-masked]] On Behalf Of George, Wesley
Sent: Wednesday, July 20, 2011 3:44 AM
To: [email-masked]
Subject: [renum] comments on draft-jiang-6renum-enterprise-00

<Sheng> My understanding is that focusing on IPv6 is the scope of this WG. It was decided during BoF and WG creating period. Dual-stack network is included, I think, but we only focus on IPv6 part of it.

<Sheng> It looks like the word "coexisting scenario" is misleading. We actually means IPv4/IPv6 transition scenarios. Dual-stack network is in the scope. Will make clearer description in next version. :)

<Sheng> We could adopt the style of RFC2071, but many of their reasons are out of date. Could you point out what our current generalization are not suitable so that we can change it in next version? Thanks.

<Sheng> OK, we can add this as one sub-scenario of caused by Internal Network Factors.

4.1 Address types -

<sheng> I guess it is fair in the draft to say the BCP is to reduce/avoid the usage of static addresses. Will do so in the next version.

<Sheng> This is a mistake quote from RFC 5887. It should be "manual or script-driven host address configuration procedures...". Will be fixed in the next version.

<Sheng> This was added by suggestion from Tim. He thought a brief list in this draft can be considered as a good input or start point of gap-analysis draft.

Thanks,

Wes George

---

From: "George, Wesley" <[email-masked]>
Date: Wed, 20 Jul 2011 08:35:32 -0400

Inline below

Thanks
Wes
Still as individual contributor

From: Jiangsheng [mailto:[email-masked]]
Sent: Wednesday, July 20, 2011 2:52 AM
To: George, Wesley; [email-masked]
Subject: RE: comments on draft-jiang-6renum-enterprise-00

Hi, George,

Sheng

WEG> I understand, and we're in agreement on the scope. I'm simply saying that right now I think the text goes out of its way to exclude IPv4 even when it would be able to take advantage of the work because it is IP version-agnostic. I think that your suggested update will help to clarify.

WEG> My problem is with "Some of renumbering reasons
   described in [RFC2071<http://tools.ietf.org/html/rfc2071>] has out of date, or not suitable in IPv6, or
   not suitable for enterprise networks."

Specifically, I have issue with the reference to 2071 and then the general statement "some ... out of date/not suitable" without specifying which are still acceptable, which are out of date/not suitable. "Some" is unclear/overly general by itself. If they are all unsuitable, make it clear that this is meant to replace those definitions as they are all unsuitable, and therefore list 2071 as being formally updated by this draft.

---

From: Jiangsheng <[email-masked]>
Date: Thu, 21 Jul 2011 07:59:34 +0000

<Sheng> Oops... Misunderstood earlier. We can analyze current available renumbering reasons more in details. But we are hesitating to mention these out of date reasons, which may not help. I guess the best we can do, is to state: we input renumbering reasons from RFC2071 if they are not out of data and still suitable in IPv6. On other side, we are not sure this could be update of 2071 because some reasons may be still suitable in IPv4, We only rule them out by our scope.