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

[Wojciech Dec <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>