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