Hello, I would like to state that I am very much not in favour of the WG adopting this document, due to a number of reasons presented below.
1. Requirements and architecture These were never clear to start with, and the requirements/context appears to undergo changes with each new version of the draft. The latest draft features the adoption of a special type of bi-directional IPinIP tunnel between the AN and which one could well say as altering the architecture. Where will the use of this tunnel stop? 2. IP interface The authors have on previous occasions claimed that a requirement/restriction was for the Layer2 Access-Node NOT to have IP interfaces, yet the mechanism described in draft -08 sees the Access Node with given the capability to: - Receive RSes from CPEs - Encapsulate/De-encapsulate an IPinIP tunnel packet - Send/Receive IP traffic. - Insert/Process IPv6 options - Source RSes on behalf of all access lines - "direct" (route?) RAs based on a line-id Is it a bird? Is it an aeroplane? Likely neither, but it sure looks like the Access Node having IP interfaces and/or the characteristics of ones, along with a "routing by line-id" application. 3. State maintenance and induction by means of RSes Draft -08 addresses the previously raised "lost RS case" by defining what amounts to be a proxy-RS sending capability on the Access-Node (AN), which is triggered by access-node's link-UP events. Through these means, state is induced on the Edge Router. In other words, the synthetic RS isent by the AN is used to signal to the Edge Router that a link on the AN has come up, and calls the Edge Router to start sending periodic RA messages to this link. This mechanism clearly tries to be a poor man's remote link control protocol and has at least one critical flaw: Once a link has gone UP, and state induced in the edge router, there is no mechanism short of manual intervention to signal a link DOWN, and remove the edge router state (and have it stop sending the RAs). This is very much different from the classic behaviour of a router, which would not be expected to continue sending RAs on "down" interfaces for eternity. This aspect of the mechanism has in fact all the hallmarks of proceeding to re-invent the Access Node Control Protocol (ANCP), which very much has the notion of signalling interface Port-up and port-downs to non directly connected Routers. I do not believe that 6man is the right place to be defining a remote link state signalling mechanism, and draft-krishan-...-08 looks like very much (in need of) going down that path. 4. Unrecoverable failure condition. It is worth noting that with the draft-krishnan-08 solution, should the Edge Router loose for any reason the induced state, the system falls back into a state of unrecoverable connectivity loss for the end users/CPEs. Any CPEs that obtained or have heard a previous RA from an Edge Router will following rfc4862 NOT send an RS, and neither will the AN synthesize an RS as long as the line is still up. A likely answer of "Our Edge Router will never loose state" does not sound comforting, and simply points to another intrinsic weakness of the solution. 5. Alternative solution to the problem The high level problem that appears to be covered here is one of how to provide a different prefix/address to different devices/CPEs when such devices are on a shared medium as seen by the Edge Router. I would like to indicate that DHCPv6 solves this problem rather well, and provides any needed line-id insertion characteristics (via the LDRA draft). The scenario described in draft-krishnan does not indicate why the use of DHCPv6 to solve the problem is not an option. Given that LDRA functionality on an AN is almost a given, so as to support routed CPEs with DHCP-PD, it seems highly onerous for the WG to define a rather contrived IPinIP tunneling solution instead of just using what is already there. This point probably also comes down to "requirements", and it would appear that the draft's driving, and unstated requirement is a "MUST not use DHCPv6" without giving cause. Thanks, Wojtek. On 21 October 2010 20:46, Bob Hinden <bob.hin...@gmail.com> wrote: > 6MAN WG, > > This is a consensus call on adopting: > > Title : Line identification in IPv6 Router Solicitation > messages > Author(s) : S. Krishnan, et al. > Filename : draft-krishnan-6man-rs-mark-08.txt > Pages : 9 > Date : 2010-09-20 > > http://tools.ietf.org/html/draft-krishnan-6man-rs-mark-08 > > as a 6MAN working group document. The authors believe this version > resolves issues raised on the mailing list in the last consensus call. > > Please state your opinion, positive or negative, on the mailing or to the > chairs. This consensus call will end on October 18, 2010. > > Regards, > Bob & Brian > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------