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

From: Bob Hinden <[email-masked]>
Date: Thu, 21 Oct 2010 11:46:32 -0700

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

---

From: Bob Hinden <[email-masked]>
Date: Thu, 21 Oct 2010 11:56:00 -0700

One personal comment, 

I think the title should be changed to something like "Line Identification Destination Option" as it is proposing to create a new destination option and uses tunneling.  In other words, it is no longer adding line identification to RS messages.

Bob

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 21 Oct 2010 15:50:10 -0700 (PDT)

----- Original Message ----
> From: Bob Hinden <[email-masked]>
> To: IPv6 WG Mailing List <[email-masked]>
> Cc: Bob Hinden <[email-masked]>
> Sent: Thu, October 21, 2010 1:56:00 PM
> Subject: Re: Consensus call on adopting <draft-krishnan-6man-rs-mark-08.txt>
> 
> One personal comment, 
> 
> I think the title should be changed to something  like "Line Identification 
>Destination Option" as it is proposing to create a new  destination option and 
>uses tunneling.  In other words, it is no longer  adding line identification to 
>RS messages.

I agree and support the adoption call.

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 21 Oct 2010 13:34:31 -0700 (PDT)

----- Original Message ----

Regards,

Behcet

---

From: Randy Bush <[email-masked]>
Date: Fri, 22 Oct 2010 09:48:38 -0400

> I think the title should be changed to something like "Line
> Identification Destination Option" as it is proposing to create a new
> destination option and uses tunneling.  In other words, it is no
> longer adding line identification to RS messages.

makes sense.  but should not be a prereq for wg taking the document on,
which i support.

randy

---

From: Philip Homburg <[email-masked]>
Date: Fri, 22 Oct 2010 16:06:20 +0200

Maybe this draft should say something about what happens if the 3 router 
solicitations sent by the host are lost.

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 22 Oct 2010 10:08:15 -0400

Hi Philip,

> solicitations sent by the host are lost.

Certainly. We have added Section 5.3 to version -08 of the draft to 
account for the case where the host-initiated RSs are lost.

Thanks
Suresh

---

From: Philip Homburg <[email-masked]>
Date: Fri, 22 Oct 2010 16:25:54 +0200

>account for the case where the host-initiated RSs are lost.

Sorry, I missed that. That sounds good.

But now I'm a bit confused. Given that the AN now has to ability to originate
RS messages, why is it forwarding the end-device' RS at all? Is that only to
support SEND?

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 22 Oct 2010 10:45:57 -0400

Hi Philip,

> Sorry, I missed that. That sounds good.

Great.

> RS messages, why is it forwarding the end-device' RS at all? Is that only to

Exactly. The ability to send host-initiated RSs through is mainly for 
supporting SEND pass through, as this capability was deemed very 
important by the WG.

Thanks
Suresh

---

From: Philip Homburg <[email-masked]>
Date: Fri, 22 Oct 2010 17:01:16 +0200

>supporting SEND pass through, as this capability was deemed very 

Then I guess the obvious next question is how this interacts with SEND if
the original 3 RS messages are lost.

---

From: Bob Hinden <[email-masked]>
Date: Fri, 22 Oct 2010 08:01:45 -0700

Correction:  The consensus call will end on October 28, 2010.

Bob

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 22 Oct 2010 11:05:42 -0400

Hi Philip,

> the original 3 RS messages are lost. 

The AN-initiated RSs in this case will not be SEND protected RSs (since 
we do not have the host's private key), but the edge router is still 
free to send SEND protected RAs back to the host in response to this RS. 
Then the host and the edge router can use SEND for protecting any 
further ND messages.

Thanks
Suresh

---

From: Philip Homburg <[email-masked]>
Date: Fri, 22 Oct 2010 18:11:18 +0200

>Then the host and the edge router can use SEND for protecting any 

I wonder what to make of that. If the SEND protected RS messages can be
replaced with AN-initiated (unprotected) RS messages, then what purpose does
protecting those messages serve in the SEND framework?

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 22 Oct 2010 10:25:45 -0700

Philip Homburg wrote:
> >> Then I guess the obvious next question is how this interacts with
> >> SEND if the original 3 RS messages are lost.
> >
> replaced with AN-initiated (unprotected) RS messages, then what purpose
> does protecting those messages serve in the SEND framework?

The customer host will receive a SEND protected RA, which makes it possible to validate that it comes from a legitimate router (via certificates validation) and is not being replayed (via timestamps.)

BTW - I support adoption of this draft.

--julien

---

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 22 Oct 2010 14:10:26 -0400

Yes.  There is certainly sufficient interest in the WG on this topic.

On 10/21/2010 2:46 PM, Bob Hinden wrote:
> Bob&  Brian
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Sat, 23 Oct 2010 10:42:13 +0200

In your letter dated Fri, 22 Oct 2010 10:25:45 -0700 you wrote:
>The customer host will receive a SEND protected RA, which makes it possible=
> to validate that it comes from a legitimate router (via certificates valid=
>ation) and is not being replayed (via timestamps.)

This implies that the end-device has to be able to match RS messages using 
timestamp, i.e. its clock has to be sufficiantly accurate (to within
5 minutes, according to the SEND RFC) to do that or (in the case of
failure) you would get hard to diagnose problems. An end-device that
requires its own nonce would fail similarly.

I think the draft needs more text about the interaction with SEND in the
case of failure.

---

From: <[email-masked]>
Date: Mon, 25 Oct 2010 13:15:29 +0200

I support the adoption of this doc. It makes sense and is needed.
Regards
	Olaf

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im 
> Auftrag von Bob Hinden
> Gesendet: Freitag, 22. Oktober 2010 17:02
> An: IPv6 WG Mailing List
> Cc: Brian Haberman; Bob Hinden
> Betreff: Re: Consensus call on adopting 
> <draft-krishnan-6man-rs-mark-08.txt>
> 
> > 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
> >
> >
> >
> >
> >

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 25 Oct 2010 08:30:37 -0700

Philip Homburg wrote:
> >> I wonder what to make of that. If the SEND protected RS messages can
> >> be replaced with AN-initiated (unprotected) RS messages, then what
> >> purpose does protecting those messages serve in the SEND framework?
> >
> > The customer host will receive a SEND protected RA, which makes it
> > possible to validate that it comes from a legitimate router (via 
> > certificates validation) and is not being replayed (via timestamps.)
> 
> This implies that the end-device has to be able to match RS messages
> using timestamp, i.e. its clock has to be sufficiantly accurate (to within
> failure) you would get hard to diagnose problems. 

That would be a failure of SEND that is orthogonal to the presence of the mechanism described in <draft-krishnan-6man-rs-mark-08.txt>.

> An end-device that requires its own nonce would fail similarly.

If the end-device wants to receive a solicited RA containing "its own nonce", it sends an RS with said nonce, the AN encapsulates the RS up to the edge router, the edge router replies with an RA containing the nonce.
 
> I think the draft needs more text about the interaction with SEND in
> the case of failure.

I disagree -- I do not see what in the mechanism described in <draft-krishnan-6man-rs-mark-08.txt> affects SEND failure modes.

--julien

---

From: Philip Homburg <[email-masked]>
Date: Mon, 25 Oct 2010 20:35:10 +0200

In your letter dated Mon, 25 Oct 2010 08:30:37 -0700 you wrote:
>> using timestamp, i.e. its clock has to be sufficiantly accurate (to withi>n
>That would be a failure of SEND that is orthogonal to the presence of the m>echanism described in <draft-krishnan-6man-rs-mark-08.txt>.

I guess you are right. SEND seems to leave out changes to the protocol
parameters for sending RS messages that are required for SEND to function
properly. But that is unrelated to this draft.

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 26 Oct 2010 16:27:27 +0200

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 <[email-masked]> wrote:

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

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 26 Oct 2010 11:26:53 -0400

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

> interfaces, yet the mechanism described in draft -08 sees the Access 
> Node with given the capability to:
> - Receive RSes from CPEs
> 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.

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

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

> 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

---

From: Balázs Varga A <[email-masked]>
Date: Wed, 27 Oct 2010 10:32:06 +0200

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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,

AN                           ...

Thanks
Suresh

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 27 Oct 2010 20:38:44 +0200

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 <[email-masked]>wrote:

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

> Please read the terminology section (1.1) where you will see the following
> text
>
> AN                           ...
> 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.

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

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

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

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

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

---

From: Ole Troan <[email-masked]>
Date: Thu, 28 Oct 2010 11:45:40 +0200

Comments/Questions:

1) N:1 deployment model. reference 5517, 3069, 4562 perhaps
2) I don't think the deployment model, i.e where you are using a single link that you are trying to create some level
   of 'subscriber isolation on, and require "routing (e.g. on line-ids" in a middlebox, is restricted to DSL. generalise
   the Introduction?
3) define how the tunneling works, which source / destination addresses are used. are there other existing signaling mechanisms that be used instead of 'piggybacking' on user traffic to signal to the network.

4) the proposal is to tunnel ND packets between the AN and the edge router. are you certain that in this model there aren't other IPv6 protocols that also have to be tunneled? which would call for a slightly more general approach?

5) does the AN have to do any other action based on the fact that it is receiving an RS? I'm specifically thinking of state required for SAVI for example. DHCPv6 is stateful and even though DHCPv6 snooping isn't architecturally very clean, it is technically a more sound design than trying to achieve the same with ND. if the answer is no, then please ignore. ;-)

6) in section 5.3 you state that the AN MAY retransmit RSs. is how this is done going to be implementation dependent?
continue forever as in DHCP or timeout after 3 tries as in ND?
if ANCP is available as the section says, is it then specifies how the signaling would be done? or would that require additional standardisation? I guess the question is, is this a problem statement, a requirements document or a solution?

7) why does section 6.2 say that the edge router mustn't decrement the hop limit of the RA message?

8) in section 6.3. are you stating that you require something like ANCMP to be able to clean up state at the edge router?

9) section 7. LineIDlen is not in the figure. could you just encode the Remote-ID dhcp option instead? (RFC4649) 

<soapbox statement>: I'm biased against this subnet model (N:1)... recreating PPP functionality over Ethernet, trying to create user isolation on a shared IPv6 link, which after all IPv6 protocols are not designed for.

what are the options?
- tell BBF not to use DHCPv6?
- go somewhere else? ANCP? BBF?
- adopt in 6man... 

I'm not sure if 6man has the required expertise for this work.

cheers,
Ole

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 28 Oct 2010 15:07:24 -0400

Hi Ole,
   Thanks for your comments.

> 1) N:1 deployment model. reference 5517, 3069, 4562 perhaps

OK. Will do.

>    of 'subscriber isolation on, and require "routing (e.g. on line-ids" in a middlebox, is restricted to DSL. generalise

Jari suggested the same. Will do in the next revision.

> 3) define how the tunneling works, which source / destination addresses are used. are there other existing signaling mechanisms that be used instead of 'piggybacking' on user traffic to signal to t…

OK.

> 5) does the AN have to do any other action based on the fact that it is receiving an RS? I'm specifically thinking of state required for SAVI for example. DHCPv6 is stateful and even though DHCPv6…

The AN does not need to setup any kind of savi-like state on the receipt 
of the RS. The AN does need to setup such state on the receipt of the RA 
as is already described in the BBF document WT-177.

> continue forever as in DHCP or timeout after 3 tries as in ND?

My thought was to indefinitely retransmit until an RA is received and 
not stop with 3 retries.

> 7) why does section 6.2 say that the edge router mustn't decrement the hop limit of the RA message?

RA messages with hop count <> 255 will be dropped by the receivers as 
specified in Section 6.1.2. of RFC4861.

> <soapbox statement>: I'm biased against this subnet model (N:1)... recreating PPP functionality over Ethernet, trying to create user isolation on a shared IPv6 link, which after all IPv6 protocols…

Fine. I do see why you are objecting to the subnet model. The fact 
remains that there are operators using this model and are looking for a 
solution to move to IPv6.

> - tell BBF not to use DHCPv6?

I think you mean "to use DHCPv6" instead of "not to use DHCPv6"?

> - go somewhere else? ANCP? BBF?

There are no other solutions on the table.

> I'm not sure if 6man has the required expertise for this work.

By "this work" Do you mean that 6man

* does not have the expertise for defining a Destination Option
* does not have the expertise for for specifying the process for usage 
of the destination option?

Thanks
Suresh

---

From: Bob Hinden <[email-masked]>
Date: Thu, 28 Oct 2010 13:53:51 -0700

All,

The chairs believe there is a consensus to adopt this document as a 6man working group document.  The next version will be published as a w.g. document.

We also note that there are still open issues that need to be resolved before we could start a w.g. last call.

Thanks for all the feedback on this work.

Regards,

Bob & Brian

---

From: David Allan I <[email-masked]>
Date: Thu, 28 Oct 2010 17:58:24 -0400

A quick comment on the soapbox statement...

I appreciate the IETF has been kind of blind to this but this kind of asymmetric Ethernet subnet is actually much more prevalent and been around longer than you might think. In Metro Ethernet Forum terms it is known as an E-TREE, support for which is being discussed by the IETF L2VPN WG. IEEE 802.1ad(2005?) documents one possible means of implementing this in the form of Asymmetric VID (which I think is also known as private VLAN) and this has been carried forward into 802.1ah PBB/.1aq SPB. 

There is also physical media that behaves like this in the form of passive optical networks, which are p2p to the root and broadcast to the leaves. GPON and EPON becoming a very prevalent broadband deployment model.... 

BBF TR101(2006) is simply one instantiation of a useful construct that has been around for years...and if anything will become much more common over time...

Cheers
Dave

---

From: Ole Troan <[email-masked]>
Date: Fri, 29 Oct 2010 10:32:57 +0200

David,

good point indeed.

perhaps it is time for the IETF to acknowledge the fact that these link types are common and to take a more architectural and wide approach to solving and adapting its protocols to this subnet model.

I'm concerned that we are standardising point solutions without understanding the problem. and I disagree with the chairs consensus call. (not that I necessarily think there are alternatives, but I'd like to see a big warning banner somewhere, not just a "we need to fix a few nits before last calling it).

cheers,
Ole

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 29 Oct 2010 11:39:16 +0200

Bob, Brian,

I'd like to push back on this consensus call. I am currently -1 on it.
Questions on the requirements, scope of solution, as well as its present
validity were raised and unanswered, in some cases totally, in others
incompletely or incoherently:

http://www.ietf.org/mail-archive/web/ipv6/current/msg12986.html
http://www.ietf.org/mail-archive/web/ipv6/current/msg12993.html

Summary of the problems:
- Requirements: Unarticulated in terms of why IETF standard track solutions
acceptable in similar deployments are not acceptable in this case.
- Requirements: The Solution attributes to the access node very distinct IP
interface, forwarding and processing capabilities, which was said to be
previously unacceptable
- Critical state and failure modes un-addressed, no smaller in consequence
to the ones that resulted in draft -07 not being accepted.
- ICMPv6 (RS) signalling is being (ab)used for line state signalling. Likely
overlap and conflict with other IETF WGs.

Thanks,
Woj.

On 28 October 2010 22:53, Bob Hinden <[email-masked]> wrote:

> All,
>
> The chairs believe there is a consensus to adopt this document as a 6man
> working group document.  The next version will be published as a w.g.
> document.
>
> >> 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
> >>
> >>
> >>
> >>
> >>
>

---

From: <[email-masked]>
Date: Fri, 29 Oct 2010 12:50:06 +0200

I appreciate the decision of the WG chairs to accept the I-D as v6ops working item since it reflects the majority of the raised opinions and acknowledges the need for a solution to make IPv6 happen in a very special, but nevertheless often implemented, network scenario. 

Kind regards
Olaf 

> Auftrag von Ole Troan
> Gesendet: Freitag, 29. Oktober 2010 10:33
> An: David Allan I
> Cc: Bob Hinden; Brian Haberman; IPv6 WG Mailing List; Suresh Krishnan
> perhaps it is time for the IETF to acknowledge the fact that 
> these link types are common and to take a more architectural 
> and wide approach to solving and adapting its protocols to 
> this subnet model.
> 
> I'm concerned that we are standardising point solutions 
> without understanding the problem. and I disagree with the 
> chairs consensus call. (not that I necessarily think there 
> are alternatives, but I'd like to see a big warning banner 
> somewhere, not just a "we need to fix a few nits before last 
> calling it).
> 
> cheers,
> Ole
> 
> 
> > <soapbox statement>: I'm biased against this subnet model 
> (N:1)... recreating PPP functionality over Ethernet, trying 
> to create user isolation on a shared IPv6 link, which after 
> all IPv6 protocols are not designed for.
> > 
> > I appreciate the IETF has been kind of blind to this but 
> this kind of asymmetric Ethernet subnet is actually much more 
> prevalent and been around longer than you might think. In 
> Metro Ethernet Forum terms it is known as an E-TREE, support 
> for which is being discussed by the IETF L2VPN WG. IEEE 
> 802.1ad(2005?) documents one possible means of implementing 
> this in the form of Asymmetric VID (which I think is also 
> known as private VLAN) and this has been carried forward into 
> 802.1ah PBB/.1aq SPB. 
> > 
> > There is also physical media that behaves like this in the 
> form of passive optical networks, which are p2p to the root 
> and broadcast to the leaves. GPON and EPON becoming a very 
> prevalent broadband deployment model.... 
> > 
> > BBF TR101(2006) is simply one instantiation of a useful 
> construct that has been around for years...and if anything 
> will become much more common over time...
> > 
> > Cheers
> > Dave
>

---

From: Alan Kavanagh <[email-masked]>
Date: Fri, 29 Oct 2010 08:09:23 -0400

Yes I fully agree Olaf and as David has also noted these N:1 VLAN deployment models exist in a lot of places and are not disappearing. Its also good that we don't force Service Provider with a given set of deployment models to change their network architecture just to endorse IPv6 which is not what SP's want to hear or embrace to roll out IPv6 ;-)

Alan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: October-29-10 6:50 AM
To: [email-masked]; David Allan I
Cc: [email-masked]; [email-masked]; [email-masked]; Suresh Krishnan
Subject: AW: Consensus call on adopting <draft-krishnan-6man-rs-mark-08.txt>

Kind regards
Olaf 

> Von: [email-masked] [mailto:[email-masked]] Im Auftrag 
> von Ole Troan
> perhaps it is time for the IETF to acknowledge the fact that these 
> link types are common and to take a more architectural and wide 
> approach to solving and adapting its protocols to this subnet model.
> 
> I'm concerned that we are standardising point solutions without 
> understanding the problem. and I disagree with the chairs consensus 
> call. (not that I necessarily think there are alternatives, but I'd 
> like to see a big warning banner somewhere, not just a "we need to fix 
> a few nits before last calling it).
> 
> cheers,
> Ole
> 
> 
> (N:1)... recreating PPP functionality over Ethernet, trying to create 
> user isolation on a shared IPv6 link, which after all IPv6 protocols 
> are not designed for.
> > 
> prevalent and been around longer than you might think. In Metro 
> Ethernet Forum terms it is known as an E-TREE, support for which is 
> being discussed by the IETF L2VPN WG. IEEE
> 802.1ad(2005?) documents one possible means of implementing this in 
> the form of Asymmetric VID (which I think is also known as private 
> VLAN) and this has been carried forward into 802.1ah PBB/.1aq SPB.
> > 
> form of passive optical networks, which are p2p to the root and 
> broadcast to the leaves. GPON and EPON becoming a very prevalent 
> broadband deployment model....
> > 
> construct that has been around for years...and if anything will become 
> much more common over time...
> > 
> > Cheers
> > Dave
>

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 29 Oct 2010 16:49:08 +0200

On 29 October 2010 14:09, Alan Kavanagh <[email-masked]> wrote:

> Yes I fully agree Olaf and as David has also noted these N:1 VLAN
> deployment models exist in a lot of places and are not disappearing. Its
> also good that we don't force Service Provider with a given set of
> deployment models to change their network architecture just to endorse IPv6
> which is not what SP's want to hear or embrace to roll out IPv6 ;-)
>

This nicely indicates the disparity between the requirements and the
proposed solution, which has been highlighted on numerous occasions:
Introducing an IPinIP tunneling protocol and interface between the Access
Node and Router clearly changes the network architecture. Based on your
statement, deploying IPv6 without this change will not be possible, while it
has been amply discussed not to be so for a very broad set of cases.

If the requirement is for a no change to the network architecture, then
could you demonstrate how does this solution meet it?

-Woj.

> I appreciate the decision of the WG chairs to accept the I-D as v6ops
> working item since it reflects the majority of the raised opinions and
> acknowledges the need for a solution to make IPv6 happen in a very special,
> but nevertheless often implemented, network scenario.
>
> Kind regards
> Olaf
>
>

---

From: Alan Kavanagh <[email-masked]>
Date: Fri, 29 Oct 2010 16:34:12 -0400

Well i guess we clearly dont agree on that.

Alan

________________________________
From: Wojciech Dec [mailto:[email-masked]]
Sent: October-29-10 10:49 AM
To: Alan Kavanagh
Cc: [email-masked]; [email-masked]; David Allan I; [email-masked]; [email-masked]; [email-masked]; Suresh Krishnan
Subject: Re: Consensus call on adopting <draft-krishnan-6man-rs-mark-08.txt>

On 29 October 2010 14:09, Alan Kavanagh <[email-masked]<mailto:[email-masked]>> wrote:
Yes I fully agree Olaf and as David has also noted these N:1 VLAN deployment models exist in a lot of places and are not disappearing. Its also good that we don't force Service Provider with a given set of deployment models to change their network architecture just to endorse IPv6 which is not what SP's want to hear or embrace to roll out IPv6 ;-)

This nicely indicates the disparity between the requirements and the proposed solution, which has been highlighted on numerous occasions: Introducing an IPinIP tunneling protocol and interface between the Access Node and Router clearly changes the network architecture. Based on your statement, deploying IPv6 without this change will not be possible, while it has been amply discussed not to be so for a very broad set of cases.

If the requirement is for a no change to the network architecture, then could you demonstrate how does this solution meet it?

-Woj.

Alan

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: October-29-10 6:50 AM
To: [email-masked]<mailto:[email-masked]>; David Allan I
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Suresh Krishnan
Subject: AW: Consensus call on adopting <draft-krishnan-6man-rs-mark-08.txt>

Kind regards
Olaf

> Von: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] Im Auftrag
> von Ole Troan
> [email-masked]<mailto:[email-masked]>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------