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

[Wojciech Dec <[e-mail]>]

Hi Suresh, All,

the initial requirements/constrains were not clear, and as they begun to
come to the surface after the solution was first proposed, the morphing of
the solution appears to have begun affecting some of the requirements to fit
the needs of the solution.

Technically, the mechanism described in draft 08, and previous versions for
that matter, has critical flaws and/or is based on unsustainable assumptions
(as detailed in my previous mail). The consequences of these are severe and
result in the possibility of an unrecoverable loss of connectivity for end
users, and/or a reliance upon operator intervention.

To deal with such flaws, the solution has begun, and likely would need to
continue developing in the direction of creating a remote L2 link
control/signalling protocol and/or a mishmash of link-state signalling and
keepalives, if not add further protocol abuse (eg the send RS to indicate a
line-up in draft -08). This IMO is not in line with the role and strengths
of 6man, and in fact looks headed for overlapping with other WGs (eg ANCP,
if not others), where such mechanisms are defined.

For these reasons I do not think that the WG should be adopting this draft
and progressing it further. Your reply does not offer any redress to the
issues raised.

If interested in more details read on, but based on the summary above and
previous mail, I rest my case...


On 26 October 2010 17:26, Suresh Krishnan <[e-mail]>wrote:

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

I'm pointing out that the requirements and constrains have not been
expressed clearly, and in the context of the architecture. What I do find
issue with is that the few (often implicit) requirements or constrains that
have come forward have undergone changes as the solution evolved. This
hardly inspires confidence in the requirements.

>
>

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


Given the list of capabilities that draft -08 attributes to the AN, it is
evident that the AN is doing  much more than "limited
inspection/modification of IPv6 packets". Your terminology section provides
a proof of where apparent requirements or assumptions are not met by the
solution, or are about to be changed to meet the solution.

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


I'm referring to a useful concept called a state machine: If one induces a
change of state (on interface UP), it is often useful and in fact necessary
to have a means of reverting that state change (on interface DOWN).
Interfaces do go down, subscribers terminate, etc.
My explanation of the issue refers to edge router (the term from your draft)
consistently, but if that's not clear enough I'll ask more specifically:
When would the edge router stop sending RAs? Or, why should the edge router
send RAs to lines that have gone down?


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

The point is that the draft appears to be heading the way of either
inventing a link/access control protocol (the synthetic RS is a port-up
message/hack), or requiring the presence of one (eg ANCP) alongside. In the
latter case, ie with ANCP there, the IPinIP tunnel is not at all necessary,
since a control protocol between the AN and Edge router is there and can be
used for the needs of IPv6 (and others). In both cases however, I do not see
6man as the right place to define this further.


>
> "  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?


An access interface down, is one example...

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


Indeed. The edge router you envisage appears to assume that it will never
loose state (across reloads, etc), which is an unreasonable assumption and a
fundamental flaw.
It is actually not very different from the lost-rs issue, which you and
others also failed to see for some time. After a CPE obtains an RA (with
PIO), it will not issue RSes as per rfc4861. Neither will the Access-Node
synthesize RSes as long as the line is up. Should *anything* happen to the
RS induced state on the edge router, a given CPE will not see an RA (with
PIO) ever again, and thus loose connectivity until manually re-set...

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


The way such hosts (DHCP less ones) can be supported is by having a router
as a CPE/RG to which hosts connect locally. Such a router is by current
definition a DHCPv6 client.
It so happens that our esteemed colleagues in Cablelabs, who by and large
have a very similar high level usage case, have opted for a solution using
the combination of; requiring that hosts/devices support DHCPv6 when behind
bridged modems, or allowing SLAAC-only hosts/devices used behind a routed
CPE (customer or operator supplied).
Your scenario of applicability/draft does not quite explain why the above is
not suitable.

Quite frankly, envisaging an operator supporting a bridged ethernet service
with a myriad of SLAAC only customer IPv6 (and IPv4) devices (with no PPP),
each of which expose the operator to connectivity/support issues appears
highly questionable, should one choose to think about it some more...

Thanks,
Wojtek.


>
> Thanks
> Suresh
>
>