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

[Jiangsheng <[e-mail]>]

Hi, George,

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

Sheng

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

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.

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

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.

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

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?

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

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.

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

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

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

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?

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

Also, doesn't most of this section belong in the gap-analysis draft?

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