RE: Consensus call on adopting <draft-krishnan-6man-rs-mark-08.txt>

[Balázs Varga A <[e-mail]>]

Hi,
Full agree with Suresh's comments and support the adaption call.
Kind regards
Bala'zs

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Suresh Krishnan
Sent: Tuesday, October 26, 2010 5:27 PM
To: Wojciech Dec
Cc: IPv6 WG Mailing List; Brian Haberman; Bob Hinden
Subject: Re: Consensus call on adopting <draft-krishnan-6man-rs-mark-08.txt>

Hi Woj,

On 10-10-26 10:27 AM, Wojciech Dec wrote:
> 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?

Can you tell us what changed about the requirements. The requirement has 
always been the following

* Support IPv6 hosts that are SLAAC-only in n:1 VLAN scenarios.

The solution has changed based on reviews and comments from the wg to 
the current IPinIP tunnel based approach. I am not sure what you are 
objecting to here. Are you objecting to the fact that the proposal has 
changed over time based on feedback?

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

It is neither a bird or an aeroplane as you have rightly figured out. 
Please read the terminology section (1.1) where you will see the 
following text

AN                           ...
                              It does not implement an IPv6 stack but
                              performs some limited inspection/
                              modification of IPv6 packets.

The AN has to have some IPv6 functionality (independent of this draft) 
in order for performing filtering and supporting anti-spoofing. As the 
editor of the BBF document defining those requirements, you should know.

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

What are you talking about? Are you talking about a link going down on a 
router or on the host side? If a link goes down on a router, nothing can 
pass through it. If a link goes down on a host any router will not 
change its RA sending behavior. A "classic" router keeps sending RAs 
whether or not there are any other hosts on the link.

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

Not true. The draft explicitly states the possibility of using ANCP, if 
it is supported on the AN, in order to signal this. See the following 
text in Section 5.3.

"  Alternately, the AN can send this notification about the subscriber
    circuit coming up using a out-of-band mechanism with acknowledgements
    like ANCP, if such mechanism is available."

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

Why do you think the draft is very much in need of going down this path? 
Do you see issues with the current version of the draft that require 
definition of additional link-state signaling mechanisms?

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

Why should the router suddenly forget the prefix(es) it was advertising 
on an interface, even after a reboot? I fail to see the issue.

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

DHCPv6 **is** the preferred solution, but that is beside the point. The 
question is, how do we support IPv6 hosts that do not support DHCPv6. 
You approach of changing the question to match your preferred answer, 
while novel, is not suitable for progress.

Thanks
Suresh

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------