Some quick comments based on my first pass review, all as an individual not a chair:
Right now, your problem statement is accurate, in that a router with no defined IPv4 addresses has no way to derive a 32-bit system ID without further user input, either in the form of a new algorithm or manually defining the ID. However, if you are asserting that effort should be made to preserve this link between the two, there needs to be better discussion of why the value shouldn't be arbitrary (e.g. a 32-bit random number) as long as it is unique in the scope that it needs to be. Yes, there are some instances that you've discussed in the introduction where it's marginally more useful to have the router-id correspond to a value present elsewhere on the device. However, I don't think you've really defined any specific problem that this causes, since it is unlikely that the only identifying information will be the router ID. Are there any places in the UI of standard routers or in actual data sent on the wire where the only information presented is the router-id, thus requiring there to be a correlation between that value and something elsewhere on the router? If so, it's possible that the underlying problem is that some implementations are assigning too much contextual value to an arbitrary field, and this document needs to have guidance to implementers that they should stop doing this. Either way, we need to get beyond hand-waving, and into more specific discussion of this problem space. What we have to do is separate convention (things that were done because the info was there) from legitimate areas where the lack of this information and correlation causes extra steps in troubleshooting or locating a given router. That will in turn drive your solution space - if there are places where that correlation needs to be preserved, then an algorithm for deriving IDs from IPv6 addresses in a way that is human-readable might be necessary. If not, then this is more about suggesting a couple of suitably random data sources on the router to use as input to generating a router-ID, possibly in conjunction with a method to detect and correct duplication within the scope where they must be unique. "there has been suggestion about avoiding protocol change" - better phrased as "protocol change may be unnecessary to address this problem" -- and more to the point, you need to explain what protocol change you're suggesting is unnecessary (that existing 32-bit ID fields should be increased to 64 or 128 bit fields or new fields added in order to accommodate an IPv6 address). This is obvious to me, because I had read your previous drafts suggesting that solution in the routing WGs, but should be explicitly stated in this draft for those not familiar with that background context. As the problem statement is refined, it may also help us work through the different scenarios so that we are able to say definitively whether there are any cases where the value of the router ID is important to the protocol and thus must be a valid IP address (v4 or v6), and whether or not there are any gaps where the protocol still needs to be updated to handle IPv6 addresses as IDs on an IPv6-only network. Those would likely spawn separate documents in the appropriate protocol's WG. Thanks, Wes George On 6/20/14, 4:34 AM, "Fan, Peng" <[email protected]> wrote: >Hi all, > >The following draft is about problems of managing router IDs in an >IPv6 only network as well as some solution ideas. It is an effort >based on the feedback during the last IETF meeting. Your review and >comments are appreciated. > >Best regards, >Peng > >---------- Forwarded message ---------- >From: [email protected] >Date: Fri, 20 Jun 2014 00:50:46 -0700 >Subject: New Version Notification for draft-fan-sunset4-router-id-00.txt >To: Peng Fan <[email protected]> > > >A new version of I-D, draft-fan-sunset4-router-id-00.txt >has been successfully submitted by Peng Fan and posted to the >IETF repository. > >Name: draft-fan-sunset4-router-id >Revision: 00 >Title: Managing Router Identifiers during IPv4 Sunset >Document date: 2014-06-20 >Group: Individual Submission >Pages: 3 >URL: >http://www.ietf.org/internet-drafts/draft-fan-sunset4-router-id-00.txt >Status: >https://datatracker.ietf.org/doc/draft-fan-sunset4-router-id/ >Htmlized: http://tools.ietf.org/html/draft-fan-sunset4-router-id-00 > > >Abstract: > This document describes problems of managing protocol identifiers > when turning off IPv4 and migrating to IPv6 only network, with some > potential solutions discussed. > > > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >sunset4 mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/sunset4 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. _______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4
