Re: [apps-discuss] Review of draft-ietf-6renum-gap-analysis-05

[Ted Hardie <[e-mail]>]

On Thu, Apr 11, 2013 at 8:00 PM, Liubing (Leo) <[e-mail]>wrote:

>  Hi, Ted****
>
> ** **
>
> Many thanks for your review, it would be helpful to refine the draft.
> Please see replies inline.****
>
> ** **
>
> Best regards,****
>
> Bing****
>
> ** **
>
> *From:* Ted Hardie [mailto:[e-mail]]
> *Sent:* Friday, April 12, 2013 6:51 AM
> *To:* [e-mail];
> [e-mail]
> *Subject:* Review of draft-ietf-6renum-gap-analysis-05****
>
> ** **
>
> I have been selected as the Applications Area Directorate reviewer
> for this draft (for background on appsdir, please see
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
> ).
>
> Please resolve these comments along with any other Last Call comments
> you may receive. Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
>
> Document:draft-ietf-6renum-gap-analysis-05****
>
> Title: IPv6 Site Renumbering Gap Analysis
> Reviewer: Ted Hardie
> Review Date: April 11, 2013****
>
>
> Summary: This document is basically ready to be published as an
> Informational draft.  There are minor issues which the authors may wish to
> address before final publication.
>
>
> Minor Issues:
>
> The document currently motivates its work with the following statement:***
> *
>
>    If IPv6 site renumbering continues to be considered****
>
>    difficult, network managers will turn to Provider Independent (PI)****
>
>    addressing for IPv6 to attempt to minimize the need for future****
>
>    renumbering. However, widespread use of PI may create very serious****
>
>    BGP4 scaling problems. It is thus desirable to develop tools and****
>
>    practices that may make renumbering a simpler process to reduce****
>
>    demand for IPv6 PI space.
>
> A citation for this would be useful.  It might also be worth it to
> highlight other potential risks--for example, the widespread deployment
> of ULAs, which do not admit of aggregation, or the deployment of
>
> ****
>
> [Bing] Ok, thanks for the suggestion. We’ll include the reference on BGP4 scaling issue, as well as considering whether there are other potential risks.****
>
> But for the specific ULA problem, it might be different. ULA is intended to be used within a certain scope, normally, within an enterprise network. So it won’t bother the global routing scalability.****
>
> In fact we suggest to use ULA along with PA in enterprise to avoid some renumbering or to make internal communication more stable when switching global prefixes. It was documented in the recently published 6renum RFC6879 (Please see section 4.1)****
>
> **
>
>
My feelings on ULAs are both largely unprintable and pretty well-known.
I'll spare you the re-iteration.


> **
>
> address translation technologies which make referral more difficult.  I note
> that RFC 5887 included some of these issues.  If the intent is to reference
> those from RFC 5887, I note that  the document currently says that it
>
> ****
>
> ** **
>
> "starts from existing work in [RFC5887],****
>
> [I-D.chown-v6ops-renumber-thinkabout] and [RFC4192]." but the references
> to these documents are informative.  If the document is meant to be an extension,
> rather than a replacement, such that these documents must be read to get the full****
>
> picture, than a normative reference may be better.****
>
> ** **
>
> [Bing] These documents are important input for the gap analysis draft. They indeed have not a few crossed content, but our intention on the gap draft was different, so it is neither extension nor replacement.****
>
> RFC5887&draft-thinkabout are more comprehensive analysis/guidelines on IPv6 renumbering issue; RFC4192 emphasizes on a “make before break” prefix switching operation.****
>
> This gap draft  addresses the IPv6 enterprise scenarios described in RFC6879, and focusing on identifying what is missing to make renum more automatic and less error-prone.****
>
>
>
> Well, we don't have a category for "informative, but really important
context", so I leave it to you to pick.  I would personally likely choose
normative to highlight their importance.



> For the session survivability section, a reference to RFC 6724 may be useful, so
> that those adding new global addresses understand how the application API to determine
>
> ****
>
> which address is used with interact with the addition of new addresses (if there
> is a specific draft or other treatment of that topic, that would be even better,
> but I am not personally aware of one).****
>
> ** **
>
> [Bing] OK. Address selection is indeed important. ****
>
>
>
> In section 6, the document currently says:
>
> ****
>
>
>    When nodes in a site have been renumbered, then all the entries in****
>
>    the site which contain the nodes' addresses must be updated. The****
>
>    entries mainly include DNS records and filters in various entities****
>
>    such as ACLs in firewalls/gateways.
>
> This appears to imply that these updates must take place after the renumbering
> event, but this is variable.  ACLs and filters may well be updated in advance;
> DNS may be updated concurrently or post facto.  A rewording to highlight that ****
>
> this is variable by record type may be useful.****
>
> ** **
>
> [Bing] Ok, thanks.
>
>
> Section 9.2, in the bullet entitled "DNS data structure optimization"
> The discusses a DNS feature proposed but declared historic. I don't think it****
>
> identifies the related renumbering gap in a way that is useful for a naive
> reader.  If it cannot be reworded to focus on the gap, I suggest it be
> removed.
>
> ****
>
> [Bing] When we wrote the draft, we considered if the IPv6 DNS record could be structured as separating prefix and suffix, that would be very helpful for renumbering. Because in IPv6, most of the time we just change the prefixes rather than the whole addresses.****
>
> We found A6 has the similar feature, but it has been moved to historic. However,  the idea of separating prefix and suffix is still considered valuable, but there might not  be able to develop a new DNS record in a short time, so we name the idea as “DNS data structure optimization” and put it into “gaps considered unsolvable”.****
>
> We can add some minor texts to explain the intention.****
>
>
> Thanks.  I do think it should be clear that you are not attempting to
resurrect the A6 vs. AAAA argument.


> In section 9.4, the document says:
>
>       For application layer, as [RFC5887] said, in general, we can****
>
>       assert that any implementation is at risk from renumbering if it****
>
>       does not check that an address is valid each time it opens a new****
>
>       communications session.
>
> This might be reworded to  include or focus on session resumption, rather than
> new communications sessions.  From an applications perspective, the laptop
> "sleep" function seems to be one of the bigger risks of this.
>
> ****
>
> [Bing] Ok, thanks.****
>
>
> Nit:
>
> For me personally, section 6.1 seemed needlessly pessimistic. ****
>
> [Bing] It is sad but true. And we are curious about how much operational issues there to prevent DDNS widely deployed in real networks.****
>
> If possible, we might consider to make a dedicated draft to talk about this issue in the future. ****
>
> ** **
>
>   Thanks for your quick reply,

Ted Hardie