Subject: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt

From: Brian Haberman <[email-masked]>
Date: Tue, 10 Aug 2010 14:08:26 -0400

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-06.txt
     Pages     : 9
     Date      : 2010-08-04

as a 6MAN working group document.  Please state your opinion, positive
or negative, on the mailing or to the chairs.  This consensus call will
end on August 27, 2010.

Regards,
Brian & Bob

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 11 Aug 2010 08:25:33 -0700 (PDT)

I support adoption of this draft, I think it is needed.

Regards,

Behcet

----- Original Message ----
> From: Brian Haberman <[email-masked]>
> To: IPv6 WG Mailing List <[email-masked]>
> Sent: Tue, August 10, 2010 1:08:26 PM
> Subject: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt
> 
> 6MAN WG,
> --------------------------------------------------------------------
> IETF  IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Wes Beebee <[email-masked]>
Date: Fri, 13 Aug 2010 13:33:15 -0400

Hemant and I discussed this draft.  Why doesn't the RG send an NS(DAD) for
the LLA out to the Edge Router and have the Edge Router set up a tunnel with
the RG.  Then, the RA can be tunnelled using the unicast LLA to the RG and
decapsulated at the RG.  This would avoid having the Edge Router to support
a new option and avoids having multicast messages sent with a unicast L2 -
but still achieves the goal of having a customized RA for each RG.

- Wes

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 13 Aug 2010 12:44:59 -0500

Right.  I proposed to encapsulate the return RA message since the
document proposes encapsulating the RS.  We get the drift that this
document is trying to bring ND to another feature parity that DHCPV6
supports - it's DHCPv6 PD.  So ND SLAAC should also support assignment
of a PD like DHCPv6 does.  

However, I cannot accept this document in its current state to be a 6man
WG work item because this document has a MUST in section 6.2 for sending
a multicast RA with unicast L2 address.  I and Wes have already blocked
the LastCall for such a doctored (L3 destination is multicast but L2
destination is unicast) multicast packet document in v6ops
(draft-gundavelli-v6ops-l2-unicast). 

Some other minor comments I have are below:

(a) In Figure 1 of this document a box is labeled as "Aggregation Node"
but this term is not used anywhere in section 2 or elsewhere in the
document.  
(b) In section one, the first word is "DSL" that is not expanded in
first use.  Please do so.
(c) Section 2: Replace "In a fixed Broadband Network" with "In a fixed
DSL Broadband Network" because cable broadband also maps to a fixed
Broadband Network.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wes Beebee (wbeebee)
Sent: Friday, August 13, 2010 1:33 PM
To: Brian Haberman; IPv6 WG Mailing List
Subject: Re: Consensus call on
adopting:draft-krishnan-6man-rs-mark-06.txt

Hemant and I discussed this draft.  Why doesn't the RG send an NS(DAD)
for
the LLA out to the Edge Router and have the Edge Router set up a tunnel
with
the RG.  Then, the RA can be tunnelled using the unicast LLA to the RG
and
decapsulated at the RG.  This would avoid having the Edge Router to
support
a new option and avoids having multicast messages sent with a unicast L2
-
but still achieves the goal of having a customized RA for each RG.

- Wes

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 13 Aug 2010 13:19:54 -0500

During the IETF 78, I met Ashok S. Joshi from Alcatel-Lucent who
appraised me of one key property of the DSL broadband network.  He said,
our cheap DSL devices in the home have about 3-5% of the devices with
duplicate mac-addresses. So what the DSL AN does is create a new
mac-addr per home and then this mac-addr is used to send data from the
AN to the Internet.  If the DSL AN does such a new mac-addr creation,
then our suggested tunnel for the RA back terminates at the AN.  The AN
has enough information to de-multiplex the tunneled RA to the individual
home. I have cced Ashok in this email to keep me honest. 

If existing tunneling mechanisms work, why do we need any of the
draft-gundavelli-v6ops-l2-unicast or this document in the IETF?  If DSL
folks really want such existing IPv6 mechanisms specified, one could do
so in the DSL standards bodies.

Hemant

-----Original Message-----
From: Hemant Singh (shemant) 
Sent: Friday, August 13, 2010 1:45 PM
To: Wes Beebee (wbeebee); Brian Haberman; IPv6 WG Mailing List
Cc: Hemant Singh (shemant)
Subject: RE: Consensus call on

Hemant

-----Original Message-----

- Wes

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 13 Aug 2010 15:57:24 -0400

Hi Wes,
   Thanks for the comments.

> but still achieves the goal of having a customized RA for each RG.

The return RA message cannot be encapsulated as a large majority of the 
Access Nodes do not have an IPv6 address (or even an IP stack for that 
matter). They are performing some layer 3 functions without having a 
complete IP stack.

Cheers
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 13 Aug 2010 16:13:18 -0400

Hi Hemant,
   Thanks for the comments. Please see responses inline

On 10-08-13 01:44 PM, Hemant Singh (shemant) wrote:
> document proposes encapsulating the RS.  

> We get the drift that this

Personally, I think SLAAC should stay simple and I do not support this 
SLAAC-PD idea. In either case, this needs to be a separate discussion.

> (draft-gundavelli-v6ops-l2-unicast). 

This is not a last call of the document :-). I am not sure that the 
issues you bring up against that document apply in this case. Can you 
specify what exactly is the issue with unicasting the RA.

> but this term is not used anywhere in section 2 or elsewhere in the

It is just background information about the BBF architecture that was 
requested by Margaret. It is not relevant to the mechanism proposed in 
the draft.

> (b) In section one, the first word is "DSL" that is not expanded in

OK.

> DSL Broadband Network" because cable broadband also maps to a fixed

OK.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 13 Aug 2010 16:16:35 -0400

Hi Hemant,

> so in the DSL standards bodies.

The mechanism specified in this document requires allocation of a 
destination option and it can be allocated one only through standards 
action. So, while the mechanism has been specified in the BBF specs 
already, the option to be used has not been allocated.

Thanks
Suresh

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 13 Aug 2010 13:22:05 -0700

On Aug 13, 2010, at 1:13 PM, Suresh Krishnan wrote:

> The return RA message cannot be encapsulated as a large majority of the Access Nodes do not have an IPv6 address (or even an IP stack for that matter). They are performing some layer 3 functions without having a complete IP stack.
> 
> Personally, I think SLAAC should stay simple and I do not support this SLAAC-PD idea. In either case, this needs to be a separate discussion.
> 
> This is not a last call of the document :-). I am not sure that the issues you bring up against that document apply in this case. Can you specify what exactly is the issue with unicasting the RA.
> 

I don't understand either. Why is it an issue for a sender node to transmit a packet on the link-layer as a unicast message, if its known there is only one receiver. I've not seen a single valid argument and so its fine, one is entitled for their opinions.

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 13 Aug 2010 13:49:44 -0700

I support the adoption of this document as a WG document.

Sri

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 13 Aug 2010 17:59:58 -0500

-----Original Message-----
From: Sri Gundavelli (sgundave) 
Sent: Friday, August 13, 2010 4:22 PM
To: Suresh Krishnan
Cc: Hemant Singh (shemant); IPv6 WG Mailing List; Brian Haberman
Subject: Re: Consensus call on

>I don't understand either. Why is it an issue for a sender node to
transmit a packet on the link-layer as a unicast message, if its known
there is only one receiver. I've not seen a single valid >argument and
so its fine, one is entitled for their opinions.

This is the email I sent out to Fred on 8/3/2010 in regards to your
draft - in double quotes below.  See my one reason for why your
document's rule will break MLDv2 protocol.  Ole agrees with me that yes,
MLDv2 sniffing will not work with your document's rule.  Further since
RFC 4862 uses MLDv2 for ND control messages such as an NS(DAD).  So now
the router node also fails to get an NS(DAD).  My summary is that IPv6
address auto configuration in RFC 4862 and RFC 4861 ND control is so
tied to MLDv2 and RFC 3810 that if MLDv2 breaks for L2 sniffing as
mentioned below, we just broke other IPv6 control.  

Hemant

"Fred,

Snipped from RFC 3810, section 7 is the following text.

[For each interface over which the router operates the MLD protocol, the
router must configure that interface to listen to all link-layer
multicast addresses that can be generated by IPv6 multicasts.  For
example, an Ethernet-attached router must set its Ethernet address
reception filter to accept all Ethernet multicast addresses that start
with the hexadecimal value 3333 [RFC2464]; in the case of an Ethernet
interface that does not support the filtering of such a multicast
address range, it must be configured to accept ALL Ethernet multicast
addresses, in order to meet the requirements of MLD.]
	
I can program such a L2 multicast filter in the CAM (Content Addressable
Memory) of Ethernet hardware with CAM.  So if this router directly
receives a multicast message with multicast destination but unicast L2,
the sniffing on 3333.xxxx.xxxx fails to capture this packet and the
router just failed MLDv2 gleaning of this message.  One may also note
that MLD is used by ND as specified in RFC 4862 and RFC 4861.

So what text do we add to the Sri document to exclude MLDv2 protocol
from their proposal?  

Hemant"

---

From: Fred Baker <[email-masked]>
Date: Fri, 13 Aug 2010 16:24:39 -0700

> So what text do we add to the Sri document to exclude MLDv2 protocol

I would recommend that you explain the point (why would it be inappropriate for an MLDv2 multicast to be sent to a unicast MAC address if the sender in fact knows that only that MAC address is relevant), and suggest text. 

Are you referring to

> 5.2.  On receiving a Router Advertisement from the subscriber
> 
>    Since the Router Advertisements are unicasted by the edge router
>    towards the subscriber the access node does not need to intercept the
>    downstream Router Advertisements.

or

> 6.2.  On sending a Router Advertisement towards the subscriber
> 
>    When the edge router sends out a Router Advertisement in response to
>    a tunneled RS that included an LIO option, it MUST unicast the RA at
>    layer 2 back to the sender of the RS.  If the source address of the
>    RS was the unspecified address, then the IPv6 destination address of
>    the RA MUST be set to the all-nodes multicast address, other wise the
>    IPv6 destination address is copied from the inner IPv6 source address
>    of the Router Soliciation.  In both cases the link-layer destination
>    address MUST be set to the unicast link-layer address which is in
>    Client Hardware Address field in the LIO.

? Those are the only two usages of the word "unicast" in the document. I'm not sure what to exclude MLDv2 from...

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 14 Aug 2010 16:05:12 -0500

Suresh,

Please see in line below.

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: Friday, August 13, 2010 4:13 PM
To: Hemant Singh (shemant)
Cc: Wes Beebee (wbeebee); Brian Haberman; IPv6 WG Mailing List
Subject: Re: Consensus call on

>matter). They are performing some layer 3 functions without having a 

Hmm, that's a very nebulous definition of the AN.  It would be good to
provide more details about the AN in the document so folks understand
what L3 functions the AN can do - match IP functionality of the AN to
the IPv6 node-req document so we know what all can the AN support.
Since the AN IPv6 functionality is fuzzy, is the AN ever an IPv6 router?
If not, then drop all text from the document that discusses not changing
Hop Limit in the tunneled RS packet.  The document also needs to explain
other boxes in Figure 1 for what IPv6 network functionality do they
support - especially the devices in the home.  What is the link-local
domain in Figure 1?  Which device(s) can create a link-local address and
issue DAD for the address?  If the DSL modem in the home (whose
specification lies totally in the DSL standards body) always first
creates an IPv6 link-local address, issues a NS(DAD) and then sends an
RS.  Then the RS will always have a src IPv6 address and then the RA
from the Edge Router can be unicast at L3 and L2 to the home.  However,
if the DSL standards bodies do not want to specify such behavior of the
DSL modem, then why not consider another alternative.  When the src IPv6
address in the received RS is the unspecified IPv6 address, the Edge
Router encapsulates the RA in an outer packet with LIO destination
option and sends the outer packet to the all-nodes destination.  If an
AN can capture an RS with all-routers destination, the AN can also
capture a packet with all-nodes destination address.  More than one AN
receives the encapsulated RA, right?  Each AN sees an LIO in destination
option and only the AN whose line id matches the LIO processes the
encapsulated RA and other ANs can drop the packet. 

Further, since section 5.2 says the AN does not need to process any
downstream unicast RA's, what is the functionality on the AN for
upstream RS's?  I understand the AN can process multicast destined RS
received on the AN upstream.  Is the IP functionality on the AN
sophisticated enough to also handle and process unicast RS?  The AN does
need to handle the unicast RS case and add an LIO.

Also, a host can send multiple RS messages. So does the new LIO need
extra fields like checksum or transaction id?

Ah, OK. So when the unicast RA reaches the home node, are you saying the
node initiates SLAAC and assigns one IPv6 address and as per RFC 4862,
the node MUST issue a NS(DAD).  What device in Figure 1 responds if a
duplicate is found?  Therefore what the document needs is to have a
section that explains the IPv6 addressing of the deployment and basic
address auto configuration operations before one can discuss RS and RA.

Thanks,

Hemant

---

From: Ole Troan <[email-masked]>
Date: Mon, 16 Aug 2010 10:36:24 +0200

Hemant,

> mentioned below, we just broke other IPv6 control.  

with regards to "Ole agrees...".
sure, but you didn't paste the rest of my argument. which is that you don't need MLD snooping for what is a unicast message on L2. after all this is only going to be sent to a single receiver.

how do you think MLD applies in this case?

(apologies to Suresh for hijacking this thread for a L2 unicast draft issue).

cheers,
Ole

---

From: <[email-masked]>
Date: Mon, 16 Aug 2010 14:52:01 +0200

I'm in favor for adopting this I-D as WG item. 
As already stated @ IETF77 I think this document is a very usefull and necessary piece of work in order to allow DSL like access networks (N:1 VLAN case) using SLAAC.

I unfortunately can't follow Hemants fears regarding DHCPv6 and SLAAC feature parity.
Just my 2 cent
	Olaf

PS: Besides that I would prefer to decouple the discussion and acceptance of this I-D from the discussion about needed extentions / modifications of I-D draft-gundavelli-v6ops-l2.

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 16 Aug 2010 18:28:37 -0400

Hi Hemant,

> From: Hemant Singh (shemant) [mailto:[email-masked]] 
> Sent: Saturday, August 14, 2010 5:05 PM
> To: Suresh Krishnan; Hemant Singh (shemant)
> Hmm, that's a very nebulous definition of the AN.  It would 
> be good to provide more details about the AN in the document 
> so folks understand what L3 functions the AN can do - match 
> IP functionality of the AN to the IPv6 node-req document so 
> we know what all can the AN support.

The AN functionality is defined in the BBF documents. I am not
sure we should cut and paste it from there. The document in question 
(TR-101) is listed as a normative reference in this draft.

> If not, then drop all text from the document that discusses 
> not changing Hop Limit in the tunneled RS packet.  The 
> document also needs to explain other boxes in Figure 1 for 
> what IPv6 network functionality do they support - especially 
> the devices in the home.  What is the link-local domain in 
> Figure 1?  Which device(s) can create a link-local address 
> and issue DAD for the address?  If the DSL modem in the home 
> (whose specification lies totally in the DSL standards body) 
> always first creates an IPv6 link-local address, issues a 
> NS(DAD) and then sends an RS.  Then the RS will always have a 
> src IPv6 address and then the RA from the Edge Router can be 
> unicast at L3 and L2 to the home.  However, if the DSL 
> standards bodies do not want to specify such behavior of the 
> DSL modem, then why not consider another alternative.  When 
> the src IPv6 address in the received RS is the unspecified 
> IPv6 address, the Edge Router encapsulates the RA in an outer 
> packet with LIO destination option and sends the outer packet 
> to the all-nodes destination.  If an AN can capture an RS 
> with all-routers destination, the AN can also capture a 
> packet with all-nodes destination address.  More than one AN 
> receives the encapsulated RA, right?  

No. The ethernet aggregation network will ensure (using MAC learning) 
that only the specific AN that has the sender attached will get the RA 
packet.

> Each AN sees an LIO in 
> destination option and only the AN whose line id matches the 
> LIO processes the encapsulated RA and other ANs can drop the packet. 
> 
> Further, since section 5.2 says the AN does not need to 
> process any downstream unicast RA's, what is the 
> functionality on the AN for upstream RS's?  I understand the 
> AN can process multicast destined RS received on the AN 
> upstream.  Is the IP functionality on the AN sophisticated 
> enough to also handle and process unicast RS?  The AN does 
> Also, a host can send multiple RS messages. So does the new 
> LIO need extra fields like checksum or transaction id?

I am not sure I understand the problem. The original RS packet is sent 
unchanged. IMHO, the LIO does not need any additional fields.

> Personally, I think SLAAC should stay simple and I do not 
> support this SLAAC-PD idea. In either case, this needs to be 
> a separate discussion.
> 
> Ah, OK. So when the unicast RA reaches the home node, are you 
> saying the node initiates SLAAC and assigns one IPv6 address 
> and as per RFC 4862, the node MUST issue a NS(DAD).  What 
> device in Figure 1 responds if a duplicate is found?  

None of the devices do. The goal of the LIO is to make sure that two 
different subscriber lines never get the same prefix for SLAAC. If you 
are talking about duplicate link-locals, there is a different solution 
proposed for it. Please see

draft-costa-6man-dad-proxy-00

> Therefore what the document needs is to have a section that 
> explains the IPv6 addressing of the deployment and basic 

As I said, the deployment models are covered in the BBF TR-101
document update for IPv6. It is listed as a normative reference.

Thanks
Suresh

---

From: Brian Haberman <[email-masked]>
Date: Tue, 17 Aug 2010 08:58:52 -0400

On 8/16/10 4:36 AM, Ole Troan wrote:
>> transmit a packet on the link-layer as a unicast message, if its
>> known there is only one receiver. I've not seen a single valid
>> >argument and so its fine, one is entitled for their opinions.
>> 
>> This is the email I sent out to Fred on 8/3/2010 in regards to
>> your draft - in double quotes below.  See my one reason for why
>> your document's rule will break MLDv2 protocol.  Ole agrees with me
>> that yes, MLDv2 sniffing will not work with your document's rule.
>> Further since RFC 4862 uses MLDv2 for ND control messages such as
>> an NS(DAD).  So now the router node also fails to get an NS(DAD).
>> My summary is that IPv6 address auto configuration in RFC 4862 and
>> RFC 4861 ND control is so tied to MLDv2 and RFC 3810 that if MLDv2
>> breaks for L2 sniffing as mentioned below, we just broke other IPv6
>> control.
> 
> with regards to "Ole agrees...". sure, but you didn't paste the rest
> of my argument. which is that you don't need MLD snooping for what is
> a unicast message on L2. after all this is only going to be sent to a
> single receiver.

Correct.  The MLD snooping functionality only looks at L3 information if
the L2 destination address is a multicast address.  In this case, L2 has
a unicast address and the MLD snooping function will never see the
packet (it will be forwarded using standard L2 logic).

> how do you think MLD applies in this case?

I agree.  It shouldn't.

> (apologies to Suresh for hijacking this thread for a L2 unicast draft

+1.

Regards,
Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 17 Aug 2010 10:37:05 -0500

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]] 
Sent: Tuesday, August 17, 2010 8:59 AM
To: Ole Troan
Cc: Hemant Singh (shemant); Sri Gundavelli (sgundave); Suresh Krishnan;
IPv6 WG Mailing List

>packet (it will be forwarded using standard L2 logic).

Brian, I changed the subject back to the Gundavelli document.  I am
saying a host sent an MLDv2 Report to a router.  There is no network
switch between this host and the router.  Now with the rule in the
Gundavelli document, the host sent the MLDv2 Report with the L3
multicast destination but L2 unicast destination.  The L2 sniffer on the
router fails to capture this packet and fails to forward the packet to
its ULP (Upper Layer Protocol) for multicast.  So now the packet is
shipped to the unicast ULP. Why can't the unicast ULP barf that it
received a packet with a L3 destination when it's a unicast ULP?  Why
shouldn't we test such a case with a router and a host sending such a
doctored MLDv2 Report?  One should use more than one router to test such
a case.  Or am I missing something - if yes, my humble apologies.

Thanks,

Hemant

---

From: Brian Haberman <[email-masked]>
Date: Tue, 17 Aug 2010 12:03:12 -0400

Hemant,

>> packet (it will be forwarded using standard L2 logic).

I do not grok this scenario.  Let me see if I can understand what you
are concerned about.

> a case.  Or am I missing something - if yes, my humble apologies.

A host generates an MLDv2 Report message that expresses interest in
receiving multicast traffic on group X.  The destination address in the
IPv6 header will be the All-MLDv2-Routers address (FF02::16).  However,
the Gundavelli draft allows the node to set the destination L2 address
to a unicast address of the only router on the link.  The host transmits
this message.

Now, what I see you arguing above is that the router will receive this
message, but may try and pass it to a *different* ULP.  I think we agree
that the router will receive the packet since it is addressed to one of
its L2 addresses.  Now, when it is parsing this message I don't see how
the L2 destination address will have any impact on which protocol this
message is handed to.  All the routing platforms I am familiar with
follow a coarse (and high-level) logic like:

1. Verify L2 validity (e.g., checksum)
2. Pass packet to protocol handler based on e.g., ethertype
3. For IPv6, parse Next Header field
4. Process MLDv2 Report

So, I can't see a scenario where the L2 destination address interferes
with the proper handling of the L3 information.

Regards,
Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 17 Aug 2010 12:38:09 -0500

Brian,

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]] 
Sent: Tuesday, August 17, 2010 12:03 PM
To: Hemant Singh (shemant)
Cc: Ole Troan; Sri Gundavelli (sgundave); Suresh Krishnan; IPv6 WG
Mailing List
Subject: Re: draft-gundavelli-v6ops-l2-unicast WGLC

>its L2 addresses.  

Yes, agreed.

>Now, when it is parsing this message I don't see how

>with the proper handling of the L3 information.

I agree that routers platforms have logic as your describe above.
However, there is no reason why some platform cannot have dedicated
logic from L2 multicast sniffer to a multicast-only ULP and likewise
from the L2 unicast code go to a unicast-only ULP.  Such platforms are
not the norm, so I will go with your logic above and rest my case.

Thanks,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 17 Aug 2010 17:15:32 -0500

Suresh,

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: Monday, August 16, 2010 6:29 PM
To: Hemant Singh (shemant)
Cc: Wes Beebee (wbeebee); Brian Haberman; IPv6 WG Mailing List
Subject: RE: Consensus call on

>(TR-101) is listed as a normative reference in this draft.

Thanks much for the TR reference and your clarifications.  Let me go
through the TR document and then get back to you.  However, I would
still strive (if it's not too much trouble) to describe the AN in your
document for IP properties like "is a LAN switch", can support an IPv6
address, will encapsulate ND RS message received from the home etc.
Conversely, just highlight what IPv6 functionality the AN can't support.

>that only the specific AN that has the sender attached will get the RA 

What do you mean by "ethernet aggregation network"? Is that the
Aggregation Node in Figure 1 of your document? I thought there is just a
VLAN between the Edge Router and then Aggregation Node. Then it is clear
from your document that there a VLANs between the Aggregation Node and
each of the AN's.  VLANs tell me the each of the Aggregation Node and
the AN's are at least a network switch.  So why wouldn't a RA destined
to the home from the Edge Router with a destination of FF02::1 not reach
other AN's?  Isn't a switch supposed to flood packets to all ports for
FF02::1?  See this text from RFC 4541 in square bracket below.

[In IPv6, the data forwarding rules are more straight forward because
MLD is mandated for addresses with scope 2 (link-scope) or greater. The
only exception is the address FF02::1 which is the all hosts
 link-scope address for which MLD messages are never sent.  Packets with
the all hosts link-scope address should be forwarded on all ports.]

Also how does the above text map to the doctored RA with L3 multicast
destination and L2 as unicast destination?

>unchanged. IMHO, the LIO does not need any additional fields.

The AN may receive any set of IPv6 packets, so first the AN somehow
captures the multicast destined RS.  Once such a multicast RS has been
captured, the AN encaps the RS in an outer packet and adds the LIO to
the outer packet.   Well, isn't this a common type of RS in your
document - meaning this multicast destined RS is commonly sent by the
host in the home?  My question was, how does the AN "sniff" or capture
the unicast RS since the AN also needs to encapsulate such an RS in an
outer packet right?  By understanding how does the AN "sniffs" a unicast
RS, I'd guess more of the L3 functionality of the AN as in how
sophisticated is the AN's IPv6 deep packet introspection.  Also, to
reiterate, doesn't the AN need to process a unicast RS as well?

>different subscriber lines never get the same prefix for SLAAC. 

I understand the goal.  Interesting.  Can you give an example prefix
sent in a PIO of a RA to a single home example, please? I want to see
how much address space is being wasted by giving a different prefix to
each home for the home to initiate SLAAC on.

>If you are talking about duplicate link-locals, there is a different
solution 
>draft-costa-6man-dad-proxy-00

Thanks for this document reference.  Another document for me to look at.
However, I need to know if the home device can create a link-local
address and then issue a NS(DAD)?  Such details should be added to your
document.  Then as I said earlier, why not tighten DSL modem specific
standards to say, the modem first creates a link-local address, performs
DAD, and only then issues an RS.  Then the RS is assured to include the
Source Link Layer Address Option(SLLAO).  On receiving such an RS, the
Edge Router can now just unicast the RA back to the home.  In a network
architecture, I find it better to send a unicast control packet like the
RA rather than sending an RA which is doctored for L2 as unicast with a
L3 multicast destination. Also, since your document in section 2 draws a
parallel to a DHCP relay agent, why not borrow one more idea from
DHCPv6? Note DHCPv6 messages travel over a link-local address.  So an
IPv6 host does not issue a DHCPv6 SOLICIT unless the host has a
link-local address.  That is what I am suggesting - don't send the RS
till the home device completes DAD for the link-local address.  Anyone
can keep me honest if it is prohibited by any of RFC 4862 or RFC 4861
for a host to wait for completing DAD for link-local address and then
issuing an RS.   Also, the home device in the DSL modem can certainly
support a link-local address.  At least the DSL modem has got to be a
full IPv6 device, doesn't it? If not, why not?

>document update for IPv6. It is listed as a normative reference.

As I said above, link-local address creation and performing DAD should
be highlighted for what device such functionality is possible in Figure
1.

Thanks much,

Hemant

---

From: Alan Kavanagh <[email-masked]>
Date: Tue, 17 Aug 2010 19:08:17 -0400

Hi Hemant

I want this state this quite clearly that the AN is a network entity that is described in the Broad Band Forum (BBF) in many Technical Reports (TR) and is not required to be explained in an IETF draft or cut and paste. I never say this being done for other IETF RFC's that BBF requested IETF to work on or utilise it. A perfect example that is used widely in BBF document and by numerous Fixed Broadband Deployments is Option-82 as noted in RFC 3046. So we should follow that same agnostic approach. 

The Aggregation Network is typically a Layer-2 network between the Access Node and Edge Node (BNG). The approach as is clearly covered in the draft is specifically in relation to an N:1 VLAN deployment model. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: August-17-10 6:16 PM
To: Suresh Krishnan
Cc: IPv6 WG Mailing List; Brian Haberman
Subject: RE: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt

Suresh,

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]]
Sent: Monday, August 16, 2010 6:29 PM
To: Hemant Singh (shemant)
Cc: Wes Beebee (wbeebee); Brian Haberman; IPv6 WG Mailing List
Subject: RE: Consensus call on

>The AN functionality is defined in the BBF documents. I am not sure we 
>should cut and paste it from there. The document in question

Thanks much for the TR reference and your clarifications.  Let me go through the TR document and then get back to you.  However, I would still strive (if it's not too much trouble) to describe the AN in your document for IP properties like "is a LAN switch", can support an IPv6 address, will encapsulate ND RS message received from the home etc.
Conversely, just highlight what IPv6 functionality the AN can't support.

Sorry I don't fully comprehend your next question, so ill try to explain. When the Access Node receives the RS packet sent by IPv6 host, this packet is encapsulated in another IPv6 packet with the destination option in order to denote the Line-ID Option. This packet is then forarded to the Edge Node. The AN would do this for all received RS packets on configured ports upstream for the subscriber premises line.

It has been decided in BBF that as we are "far from short of IPv6 Prefixes" that a unique prefix would be allocated to each home subscriber line. This can be done via DHCP_PD in the case of a Routed RG model or RA in the case you have a Bridged RG where by the RA is unicasted to ensure each IPv6 host is allocated a unique prefix. In some scenarios it may make sense to multicast the RA where by a single prefix is sent to the subscriber line, this would typically be the case for WiFi hot spot deployments as one typical example, others exist and vary from one SP to another etc etc etc..

For the DSL moden, or to be more precise the RG acting as a Layer-3 RG where by it sends out an NS_DAD when forming a LLA, from what I remember this is covered in one of the BBHome WG documents. I encourage you to write said contribution of your note to the BBF and present it to the BBHome WG. I understand your point on sending the NS_DAD before the RS, but unfortunately nothing prevents the latter and said solution must consider where we have IPv6 hosts directly connected where some will send an RS and do a DAD==0...unfortunate but true.

Note that the main reason for having a "Line ID Option" is to identify the Subscriber Line, so im not sure

BR
Alan

>that only the specific AN that has the sender attached will get the RA 

What do you mean by "ethernet aggregation network"? Is that the Aggregation Node in Figure 1 of your document? I thought there is just a VLAN between the Edge Router and then Aggregation Node. Then it is clear from your document that there a VLANs between the Aggregation Node and each of the AN's.  VLANs tell me the each of the Aggregation Node and the AN's are at least a network switch.  So why wouldn't a RA destined to the home from the Edge Router with a destination of FF02::1 not reach other AN's?  Isn't a switch supposed to flood packets to all ports for FF02::1?  See this text from RFC 4541 in square bracket below.

[In IPv6, the data forwarding rules are more straight forward because MLD is mandated for addresses with scope 2 (link-scope) or greater. The only exception is the address FF02::1 which is the all hosts  link-scope address for which MLD messages are never sent.  Packets with the all hosts link-scope address should be forwarded on all ports.]

Also how does the above text map to the doctored RA with L3 multicast destination and L2 as unicast destination?

>unchanged. IMHO, the LIO does not need any additional fields.

The AN may receive any set of IPv6 packets, so first the AN somehow captures the multicast destined RS.  Once such a multicast RS has been captured, the AN encaps the RS in an outer packet and adds the LIO to
the outer packet.   Well, isn't this a common type of RS in your
document - meaning this multicast destined RS is commonly sent by the host in the home?  My question was, how does the AN "sniff" or capture the unicast RS since the AN also needs to encapsulate such an RS in an outer packet right?  By understanding how does the AN "sniffs" a unicast RS, I'd guess more of the L3 functionality of the AN as in how sophisticated is the AN's IPv6 deep packet introspection.  Also, to reiterate, doesn't the AN need to process a unicast RS as well?

>different subscriber lines never get the same prefix for SLAAC.

I understand the goal.  Interesting.  Can you give an example prefix sent in a PIO of a RA to a single home example, please? I want to see how much address space is being wasted by giving a different prefix to each home for the home to initiate SLAAC on.

solution 

Thanks for this document reference.  Another document for me to look at.
However, I need to know if the home device can create a link-local address and then issue a NS(DAD)?  Such details should be added to your document.  Then as I said earlier, why not tighten DSL modem specific standards to say, the modem first creates a link-local address, performs DAD, and only then issues an RS.  Then the RS is assured to include the Source Link Layer Address Option(SLLAO).  On receiving such an RS, the Edge Router can now just unicast the RA back to the home.  In a network architecture, I find it better to send a unicast control packet like the RA rather than sending an RA which is doctored for L2 as unicast with a
L3 multicast destination. Also, since your document in section 2 draws a parallel to a DHCP relay agent, why not borrow one more idea from DHCPv6? Note DHCPv6 messages travel over a link-local address.  So an
IPv6 host does not issue a DHCPv6 SOLICIT unless the host has a link-local address.  That is what I am suggesting - don't send the RS till the home device completes DAD for the link-local address.  Anyone can keep me honest if it is prohibited by any of RFC 4862 or RFC 4861 for a host to wait for completing DAD for link-local address and then
issuing an RS.   Also, the home device in the DSL modem can certainly
support a link-local address.  At least the DSL modem has got to be a full IPv6 device, doesn't it? If not, why not?

>As I said, the deployment models are covered in the BBF TR-101 document 
>update for IPv6. It is listed as a normative reference.

As I said above, link-local address creation and performing DAD should be highlighted for what device such functionality is possible in Figure 1.

Thanks much,

Hemant

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 18 Aug 2010 13:11:02 +0200

Hi,

I have a question or two to the draft authors who can hopefully clarify the
expected context and working of this scheme, which at the moment is a bit
unclear.
In essence the problem this draft appears to be trying to solve is using
RS/RA messages to induce state into intermediate or IP edge devices like
what is done for DHCP, with the LIO being used to induce such state. All
this is presumably meant to take place following an RS message sent by a
client. Thus, my questions are:
How does this solution cope in a case where the client does not send an RS?
(or the RS sending has timed out)?

Thanks,
Woj.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 18 Aug 2010 10:03:16 -0400

Hi Woj,
   Thanks for your comments.

On 10-08-18 07:11 AM, Wojciech Dec wrote:
> Hi,
> 
> I have a question or two to the draft authors who can hopefully clarify 
> the expected context and working of this scheme, which at the moment is 
> a bit unclear.
> How does this solution cope in a case where the client does not send an 
> RS? (or the RS sending has timed out)?

The first sign of life from the client is either an RS or a DHCPv6 
message. If the network does not see either of the messages, there will 
be no address allocated/prefix advertised to the client. The client will 
not have any connectivity.

Thanks
Suresh

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 18 Aug 2010 16:46:23 +0200

Hi Suresh,

thanks for your reply. Continued inline...

On 18 August 2010 16:03, Suresh Krishnan <[email-masked]>wrote:

>> the expected context and working of this scheme, which at the moment is a
>> bit unclear.
> The first sign of life from the client is either an RS or a DHCPv6 message.
> If the network does not see either of the messages, there will be no address
> allocated/prefix advertised to the client. The client will not have any
> connectivity.
>

Hmm, but if the first sign of life is a DHCPv6 message from a client , then
why would the RS LIO be needed ?

Now, in the case of a non DHCPv6 client, given that such clients are do time
out from sending RS messages, how does the solution cater to that? Just
leaving clients with no connectivity seems like a highly undesirable
proposition/outcome...

-Woj.

---

From: Alan Kavanagh <[email-masked]>
Date: Wed, 18 Aug 2010 10:51:23 -0400

Hi Woj

Its the same issue for DHCPv6, if the client dont send a DHCP_Solicit you dont get an address. Also, the RS similar to the DHCP_Solicit is used to "kick_start" the IP Sub session and as you know there are lots of hosts whom dont have a DHCPv6 client and will not have a DHCPv6 client.

The RS LIO is used to cater for hosts who do not have a DHCPv6 Client. Also the LIO is used to identify the subscriber line and tie rules etc to this sub line.

Alan

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wojciech Dec
Sent: August-18-10 10:46 AM
To: Suresh Krishnan
Cc: Brian Haberman; IPv6 WG Mailing List
Subject: Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt

Hi Suresh,

On 18 August 2010 16:03, Suresh Krishnan <[email-masked]<mailto:[email-masked]>> wrote:
Hi Woj,
 Thanks for your comments.

I have a question or two to the draft authors who can hopefully clarify the expected context and working of this scheme, which at the moment is a bit unclear.
In essence the problem this draft appears to be trying to solve is using RS/RA messages to induce state into intermediate or IP edge devices like what is done for DHCP, with the LIO being used to induce such state. All this is presumably meant to take place following an RS message sent by a client. Thus, my questions are:
How does this solution cope in a case where the client does not send an RS? (or the RS sending has timed out)?

The first sign of life from the client is either an RS or a DHCPv6 message. If the network does not see either of the messages, there will be no address allocated/prefix advertised to the client. The client will not have any connectivity.

Hmm, but if the first sign of life is a DHCPv6 message from a client , then why would the RS LIO be needed ?

Now, in the case of a non DHCPv6 client, given that such clients are do time out from sending RS messages, how does the solution cater to that? Just leaving clients with no connectivity seems like a highly undesirable proposition/outcome...

-Woj.

Thanks
Suresh

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 18 Aug 2010 17:01:24 +0200

Hi Alan,

that wasn't quite the question I asked. DHCPv6 has a well defined mechanism
to periodically retry, while RS client sending simply timeout. This would
seemingly leave such clients in the proposed scheme with no connectivity.

-Woj.

On 18 August 2010 16:51, Alan Kavanagh <[email-masked]> wrote:

>  Hi Woj
>
> Its the same issue for DHCPv6, if the client dont send a DHCP_Solicit you
> dont get an address. Also, the RS similar to the DHCP_Solicit is used to
> "kick_start" the IP Sub session and as you know there are lots of hosts whom
> dont have a DHCPv6 client and will not have a DHCPv6 client.
>
> The RS LIO is used to cater for hosts who do not have a DHCPv6 Client. Also
> the LIO is used to identify the subscriber line and tie rules etc to this
> sub line.
>
> Alan
>
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Wojciech Dec
> *Sent:* August-18-10 10:46 AM
> *To:* Suresh Krishnan
> *Cc:* Brian Haberman; IPv6 WG Mailing List
> *Subject:* Re: Consensus call on
>> message. If the network does not see either of the messages, there will be
>> no address allocated/prefix advertised to the client. The client will not
>> have any connectivity.
>>
>
> Now, in the case of a non DHCPv6 client, given that such clients are do
> time out from sending RS messages, how does the solution cater to that? Just

---

From: Ole Troan <[email-masked]>
Date: Wed, 18 Aug 2010 17:07:33 +0200

> The RS LIO is used to cater for hosts who do not have a DHCPv6 Client. Also the LIO is used to identify the subscriber line and tie rules etc to this sub line.

an IPv6 host sends 3 RS's within about 3 seconds. if no RA is received then the host concludes that there are no IPv6 routers on the link. in contrast DHCPv6 which will continue to solicit for a DHCP server indefinitely.

on these link types do you also send multicast RAs? what is the probability of loosing the 3 first RS messages from a client?

cheers,
Ole

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 18 Aug 2010 11:07:05 -0400

Hi Woj,

On 10-08-18 11:01 AM, Wojciech Dec wrote:
> Hi Alan,
> 
> that wasn't quite the question I asked. DHCPv6 has a well defined 
> mechanism to periodically retry, while RS client sending simply timeout. 
> This would seemingly leave such clients in the proposed scheme with no 
> connectivity.

I do see your problem, but that problem is common to all existing SLAAC 
clients and is not specific to LIO. If your problem is "RFC4861/62 
compliant clients give up after retransmitting an RS 3 times", I am not 
sure what this draft can do about it.

Thanks
Suresh

---

From: Ole Troan <[email-masked]>
Date: Wed, 18 Aug 2010 17:11:35 +0200

Suresh,

>> that wasn't quite the question I asked. DHCPv6 has a well defined mechanism to periodically retry, while RS client sending simply timeout. This would seemingly leave such clients in the proposed scheme with no connectivity.
> 
> I do see your problem, but that problem is common to all existing SLAAC clients and is not specific to LIO. If your problem is "RFC4861/62 compliant clients give up after retransmitting an RS 3 times", I am not sure what this draft can do about it.

I think the main difference is that for all other SLAAC hosts, they will receive a multicast RA which will trigger SLAAC.
is that also going to happen in this case?

cheers,
Ole

---

From: Alan Kavanagh <[email-masked]>
Date: Wed, 18 Aug 2010 12:01:21 -0400

Hi Ole

I believe its also true in that the host tx the RS and Edge node then responds with the RA as oppose to the Edge node txing the RA. This is really a BBF issue on how the BNG operates and should be taken up in BBF.

Alan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: August-18-10 11:12 AM
To: Suresh Krishnan
Cc: Brian Haberman; IPv6 WG Mailing List
Subject: Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt

Suresh,

cheers,
Ole

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 19 Aug 2010 13:59:16 +0200

SInce the WG is being asked to adopt a draft it would seem rather natural to
explain the context of the usage more clearly, especially as it appears that
this usage context has a rather serious pitfall when used alongside a
regular IPv6 client (leaving such a client with no connectivity after an RS
timeout).

-Woj.

On 18 August 2010 18:01, Alan Kavanagh <[email-masked]> wrote:

> Hi Ole
>
> I believe its also true in that the host tx the RS and Edge node then
> responds with the RA as oppose to the Edge node txing the RA. This is really
> a BBF issue on how the BNG operates and should be taken up in BBF.
>
> Alan
>
>
> Ole Troan
> clients and is not specific to LIO. If your problem is "RFC4861/62 compliant
> clients give up after retransmitting an RS 3 times", I am not sure what this
> draft can do about it.
>
> I think the main difference is that for all other SLAAC hosts, they will
> receive a multicast RA which will trigger SLAAC.

---

From: Alan Kavanagh <[email-masked]>
Date: Thu, 19 Aug 2010 08:47:34 -0400

Hi Woj

Don't you have that same problem regardless of the LIO?

If you have an IPv6 host directly connected to say your loving Residential Gateway and it sends 3 RS messages you have the same issue, right?

Also, the likelihood of losing 3 RS messages are highly unlikely, you would have better probability doing the Lottery and winning!

BR
Alan

________________________________
From: Wojciech Dec [mailto:[email-masked]]
Sent: August-19-10 7:59 AM
To: Alan Kavanagh
Cc: Ole Troan; Suresh Krishnan; Brian Haberman; IPv6 WG Mailing List
Subject: Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt

SInce the WG is being asked to adopt a draft it would seem rather natural to explain the context of the usage more clearly, especially as it appears that this usage context has a rather serious pitfall when used alongside a regular IPv6 client (leaving such a client with no connectivity after an RS timeout).

-Woj.

On 18 August 2010 18:01, Alan Kavanagh <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ole

Alan

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ole Troan
Sent: August-18-10 11:12 AM
To: Suresh Krishnan
Cc: Brian Haberman; IPv6 WG Mailing List
Subject: Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt

Suresh,

cheers,
Ole
--------------------------------------------------------------------
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
--------------------------------------------------------------------

---

From: Ole Troan <[email-masked]>
Date: Thu, 19 Aug 2010 15:01:39 +0200

Alan,

> Also, the likelihood of losing 3 RS messages are highly unlikely, you would have better probability doing the Lottery and winning!

SLAAC works with periodic RAs. so in the above scenario SLAAC would work, it would just take a little longer.
if what is proposed in rs-mark is only to use 'triggered by RS' unicast RA's then I think you are breaking how SLAAC is intended to work.
if you _do_ send periodic multicast advertisements even without PIO options, you should be OK I think.

cheers,
Ole

---

From: Alan Kavanagh <[email-masked]>
Date: Thu, 19 Aug 2010 09:07:31 -0400

Hi Ole

So I see two tracks here, as I noted last year in BBF. 1. You sent the RA periodically multicasted for the defautl router address advertisement. In this you can also multicast a Prefix as would be the case in some situations, i.e. hotspot deployments connected over a TR-101 network. 2. The Edge node waits for the RS before sending the RA to trigger sub rules and allocate an IPv6 Prefix specifically for this identified host.

Reality is this will be used by numerous Fixed Service Providers whom have an N:1 VLAN model and will not change this because of IPv6 :-)

On the periodic RA's I agree for the default router address but for PIO options that is configurable ;-)....i would not like all my hosts on an Edge node to be multicasting the same prefix to thousands of sub lines....hmmm!

Alan 

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: August-19-10 9:02 AM
To: Alan Kavanagh
Cc: Wojciech Dec; Suresh Krishnan; Brian Haberman; IPv6 WG Mailing List
Subject: Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt

Alan,

cheers,
Ole

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 19 Aug 2010 15:22:43 +0200

There seems to be reason to explain the context/workings more clearly, both
in terms of multicasting an RA and the overall expected BBF usage.

-Woj.

On 19 August 2010 15:07, Alan Kavanagh <[email-masked]> wrote:

> Hi Ole
>
> So I see two tracks here, as I noted last year in BBF. 1. You sent the RA
> periodically multicasted for the defautl router address advertisement. In
> this you can also multicast a Prefix as would be the case in some
> situations, i.e. hotspot deployments connected over a TR-101 network. 2. The
> Edge node waits for the RS before sending the RA to trigger sub rules and
> allocate an IPv6 Prefix specifically for this identified host.
>
> Reality is this will be used by numerous Fixed Service Providers whom have
> an N:1 VLAN model and will not change this because of IPv6 :-)
>
> On the periodic RA's I agree for the default router address but for PIO
> options that is configurable ;-)....i would not like all my hosts on an Edge
> node to be multicasting the same prefix to thousands of sub lines....hmmm!
>
> Alan
>
> > If you have an IPv6 host directly connected to say your loving
> Residential Gateway and it sends 3 RS messages you have the same issue,
> right?
> >
> > Also, the likelihood of losing 3 RS messages are highly unlikely, you
> would have better probability doing the Lottery and winning!
>
> if what is proposed in rs-mark is only to use 'triggered by RS' unicast
> RA's then I think you are breaking how SLAAC is intended to work.

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 19 Aug 2010 09:39:27 -0400

Hi Ole,

> if what is proposed in rs-mark is only to use 'triggered by RS' unicast RA's then I think you are breaking how SLAAC is intended to work.

That is not what is being proposed in the draft. If you can point to 
such text in the draft, I will gladly remove it. To reiterate, there is 
nothing in the  draft that proposes not sending multicast RAs without 
receiving RSs.

> if you _do_ send periodic multicast advertisements even without PIO options, you should be OK I think.

This is the case.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 19 Aug 2010 09:43:09 -0400

Hi Woj,

On 10-08-19 09:22 AM, Wojciech Dec wrote:
> There seems to be reason to explain the context/workings more clearly, 
> both in terms of multicasting an RA and the overall expected BBF usage.

The draft describes how the sender of the RA deals with a tunneled RS 
with a LIO. No RS received, nothing in the draft is applicable. 
Multicasting an unsolicited RA is performed as per RFC4861/RFC4862. This 
is not something covered in the draft. I am not sure what you want me to 
explain here. As the editor of the BBF spec in question, I would have 
thought that you would be more qualified than me to explain the BBF usage.

Thanks
Suresh

---

From: Brian Haberman <[email-masked]>
Date: Thu, 19 Aug 2010 12:26:10 -0400

Suresh,

> thought that you would be more qualified than me to explain the BBF usage.

I think there is some misunderstanding going on here and I believe it
may have to do with the lack of detail (and maybe some typos) in the
draft.  It appears that sections 5 & 6 could be made more clear with a
few additions.

First, it would be useful to expand all the acronyms in Figure 1 so that
there is a clear understanding what the roles are of all the nodes in
the diagram.  A *short* description of each node's role would be quite
useful.

Second, it would be useful if the text in sections 5 & 6 referenced the
figure so that we know what nodes are originating which messages.  For
example, section 5.1 talks about receiving an RS from a subscriber, but
there is no node in the diagram labeled as the subscriber.  Which node
sends that RS?

Finally, I found the section heading of 6.1 confusing.  It references a
subscriber, but the text only talks about the access node.  One can
infer how this works, but it would be better if it was clarified so that
we don't have differing views of what is going on.

Regards,
Brian

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 19 Aug 2010 19:06:09 -0400

Hi Brian,
   Thanks for the comments. I will submit a revised version tomorrow.

> the diagram.  A *short* description of each node's role would be quite

Sounds good. Will do.

> there is no node in the diagram labeled as the subscriber.  Which node

I will modify the figure to show the host that sends the RS.

OK.

Thanks
Suresh

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 20 Aug 2010 09:34:23 +0200

Hi Suresh,

Good to hear that you will be clarifying the draft. I take it that showing
the full intended RS/RA message exchange will be part of that clarification.

Thanks,
Woj.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 20 Aug 2010 16:56:40 -0400

> draft.  It appears that sections 5 & 6 could be made more clear with a

Thank you. You said what I was going to say. :-)

> the diagram.  A *short* description of each node's role would be quite

Please expand *all* the acronyms. What is a PON for example?

And to hammer the point home, the figure includes an entity called an
"RG". But the text never refers to this entity, whatever it is...

And what is a "CPE"? That is a *very* generic term for any device the
customer owns... Are these the laptops and other client devices?

Also, please be sure to state which enities have full IP stacks (and
addresses) and which do not, since that is part of the problem
motivation...

The intro also talks about VLANS and N:1, but I don't understand how
they are used. E.g., in the figure, is everything in one VLAN? Is each
AN in its own VLAN?

And be very clear about which devices are in *different* customer's
homes.

Finally, most homes nowadays have a router between hosts and
ISP. Which device in your picture plays that role?

> 3.  Applicability
> 
>    The line identification option is intended to be used only for the
>    N:1 VLAN deployment model.  For the other VLAN deployment models
>    there is no need to carry line identification.

Maybe it's just me, but I have yet to see a simple, one paragraph (or
less) explanation of what the N:1 VLAN model is. Please include such a
definition/explanation in the draft.

I look forward to seeing a revised document. Until I understand the
problem more clearly, I cannot say whether I support the WG taking on
this work.

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 20 Aug 2010 16:33:50 -0500

Suresh,

>Sent: Friday, August 13, 2010 4:17 PM

>already, the option to be used has not been allocated.

Sorry, you missed my point.  Your document proposes this text in section
5.1:

[It MUST also insert the hardware address of the client (from the source
hardware address of the RS) into the client hardware address field of
the option.]

However if you see my email above, if the DSL Forum decides to have the
AN create a new hardware (or mac-addr) address for the client, then the
text above from your document has to change.  The reason for the change
is because now the AN does NOT copy the hardware address from the src of
the RS but instead creates a new one and copies the new one into the
client hardware address field of the LIO.  Such new creation of a client
hardware address means the AN will have to maintain a hardware address
translation table (HAT).

Hemant

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 20 Aug 2010 18:51:59 -0400

Hi Woj,

On 10-08-20 03:34 AM, Wojciech Dec wrote:
> Hi Suresh,
> 
> Good to hear that you will be clarifying the draft. I take it that 
> showing the full intended RS/RA message exchange will be part of that 
> clarification.

Absolutely.

Cheers
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 20 Aug 2010 19:06:17 -0400

Hi Thomas,
   Thanks for the comments. I acknowledge the lack of detail in the 
draft and this is due to the fact that I assumed referencing the 
relevant BBF document (TR-101) was sufficient. I will clarify these 
details in the next revision.

Thanks
Suresh

---

From: "Soininen, Jonne (NSN-FI/Espoo)" <[email-masked]>
Date: Mon, 23 Aug 2010 13:55:41 +0300

Hi,

Like I said in the discussion in the 6man WG in Anaheim, I do support taking
up this work. 

The long mails that have come in the mailing list show that the draft does
still need some work, but I don't see that as a problem for adopting the
draft at this point.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: jouni korhonen <[email-masked]>
Date: Mon, 23 Aug 2010 16:16:59 +0300

Hi,

I support adopting this document as a basis for a WG document. the functionality it describes is indeed useful in certain deployments.

- Jouni

---

From: <[email-masked]>
Date: Mon, 23 Aug 2010 15:18:55 +0200

+1

Ciao
	Olaf

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im 
> Auftrag von jouni korhonen
> Gesendet: Montag, 23. August 2010 15:17
> An: Brian Haberman
> Cc: IPv6 WG Mailing List
> Betreff: Re: Consensus call on 
> I support adopting this document as a basis for a WG 
> document. the functionality it describes is indeed useful in 
> certain deployments.
> 
> - Jouni
>

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 24 Aug 2010 21:40:23 -0400

Hi Thomas/Brian,
   I submitted a new revision with the changes you requested. Can you 
please look over the new revision available at

http://www.ietf.org/id/draft-krishnan-6man-rs-mark-07.txt

and let me know if it addresses your concerns

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 24 Aug 2010 21:46:17 -0400

Hi Woj,

> showing the full intended RS/RA message exchange will be part of that 

I think that the issue you and Ole raised about the lost RSs is an 
important one and is, I believe, applicable to all SLAAC hosts even if 
they do not implement this spec. For this reason, I have written a short 
draft about this failure scenario and my expected view of how the host 
can/will recover and what the network needs to do in order to assist. I 
intend to publish it soon. I will send a pointer to the ML after I do 
so. Please take a look and let me know if addresses your concern.

Thanks
Suresh

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 25 Aug 2010 10:31:13 +0200

Hi Suresh,

thanks for looking further into this problem, and publishing an updated
draft 07. Let me however stress that this problem is one very strictly tied
to the (supposed?) usage context of the RS-mark mechanism, and thus it
really needs to be described/addressed in the rs-mark draft, not some other.
The reason for this is simple: On regular SLAAC networks, RAs get
periodically ad-infinitum multicast to all nodes allowing such nodes to
perform SLAAC, thus the loss/timeout of a client in sending RSes does not
matter much.
In contrast, and in what I currently understand as the RS-mark usage
scenario to be, no such periodic multicast RA is sent until the client sends
an RS. Hence, clients that time out from sending RSes have no chance of
running SLAAC or connecting, other than perhaps through some manual
intervention.
Draft 07 does not appear to address this issue, while it most definitely
should given its rather serious consequences for regular ICMPv6 clients.
Could you explain to us the mechanism from recovering from this problem (eg
CPE reload?)? On the email thread, there was mention of a) this being an
allowed un-recoverable failuire scenario or b) multicasting RAs downstream.
The text in draft 07 does not reflect either, so which one is it?

Regards,
Woj.

On 25 August 2010 03:46, Suresh Krishnan <[email-masked]>wrote:

> important one and is, I believe, applicable to all SLAAC hosts even if they
> do not implement this spec. For this reason, I have written a short draft
> about this failure scenario and my expected view of how the host can/will
> recover and what the network needs to do in order to assist. I intend to
> publish it soon. I will send a pointer to the ML after I do so. Please take
> a look and let me know if addresses your concern.
>
> Thanks
> Suresh
>
>

---

From: Thomas Narten <[email-masked]>
Date: Wed, 25 Aug 2010 09:03:27 -0400

Hi Suresh.

Thanks for the revised document. It is much clearer now.

Some followup questions.

1) in Figure 1, it would help to explain whether everything to the
left of the edge router is in the same "broadcast domain". I.e, all
nodes attached to the network can send packets directly to each
other. 

2) What is the address assignment model. Is the entire left part of
the network one IPv6 link, with each node having an address out of the
same prefix? It would be good to more clearly identify what is an
individual customer. I assume that the Host/RG is a "customer".

Also, what on-link prefixes are assigned? Is the intention that
traffic between (say) Host1 and Host2 (behind differnet RGs) go
directly to each other, or does such traffic need to go through the
Edge Router?

3) For customers, do they all get addresses out of the same prefix? Or
do they get differnet prefixes? I guess the key question I'm asking is
why does the edge router need to know what circuit a given RG is on
when responding to an RS. What informaiton does the RS return that
depends on that circuit ID or that might vary from one RG to another.

Thomas

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 25 Aug 2010 11:18:21 -0400

Hi Woj,

On 10-08-25 04:31 AM, Wojciech Dec wrote:
> draft 07. Let me however stress that this problem is one very strictly 
> tied to the (supposed?) usage context of the RS-mark mechanism, and thus 
> it really needs to be described/addressed in the rs-mark draft, not some 
> other.

I respectfully disagree. Here's why. The RS-mark mechanism describes how 
RSs are marked and how the responding solicited-RAs are sent. It has got 
nothing to do with other neighbor discovery messages. e.g. Unsolicited 
multicast RAs, Redirects, DAD NS/NAs, Address resolution NS/NAs etc. 
which are sent as defined in RFC4861/62. The draft simply does not 
mention anything about these other messages. If you can clarify why you 
think this is relevant to this draft, I will certainly add it here.

> perform SLAAC, thus the loss/timeout of a client in sending RSes does 
> not matter much.
> scenario to be, no such periodic multicast RA is sent until the client 
> sends an RS. 

This is not true. The draft does not modify RFC4861/RFC4862 behavior in 
any way for unsolicited multicast RAs.

 > Hence, clients that time out from sending RSes have no
 > chance of running SLAAC or connecting, other than perhaps through some
 > manual intervention.
> Could you explain to us the mechanism from recovering from this problem 
> (eg CPE reload?)? On the email thread, there was mention of a) this 
> being an allowed un-recoverable failuire scenario or b) multicasting RAs 
> downstream.  The text in draft 07 does not reflect either, so which one 
> is it?

Multicasting an RA is not optional. Period. So b) is a given. The draft 
does not have to specify this. It needs to be done in any compliant 
network. The question is whether this periodic unsolicited multicast RA 
needs to contain a PIO usable for SLAAC. For this, my answer is a NO.

Cheers
Suresh

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 25 Aug 2010 17:56:16 +0200

On 25 August 2010 17:18, Suresh Krishnan <[email-masked]>wrote:

> multicast RAs, Redirects, DAD NS/NAs, Address resolution NS/NAs etc. which
> are sent as defined in RFC4861/62. The draft simply does not mention
> anything about these other messages. If you can clarify why you think this
> is relevant to this draft, I will certainly add it here.

Your argument seems to be saying that the draft is not to discuss/mention
the overall context/intended usage of the mechanism and that steam rolling a
simple RS-marking mechanism is what should be followed.
I'm arguing, as are others, that the overall context and an understanding of
the scenario where the RS-mark mechanism is to be used is required, as there
appear to be issues there that are of relevance to the IPv6 community. Given
that you are one of the authors/proponents of this draft/mechanism in both
the IETF and in the BBF simultaneously, it's only fair to ask you the
question to explain the context & assumptions, given that they are no-where
to be seen publicly.

>> an RS.
> This is not true. The draft does not modify RFC4861/RFC4862 behavior in any
> way for unsolicited multicast RAs.

Sigh. Please point me to *where* in does the draft mention periodic
unsolicited multicast RAs?

> does not have to specify this. It needs to be done in any compliant network.
> The question is whether this periodic unsolicited multicast RA needs to
> contain a PIO usable for SLAAC. For this, my answer is a NO.
>

So now I understand your answer, ie PIO-less multicast RAs are necessary.
Perhaps then the draft should state that, but before we go there perhaps you
could come to answer the following question that again is part of the
original RS timeout issue, which I understand you agree exists.

RFC4861 states:
"Once the host sends a Router Solicitation, and receives a valid
   Router Advertisement with a non-zero Router Lifetime, the host MUST
   desist from sending additional solicitations on that interface, until
   the next time one of the above events occurs.  Moreover, a host
   SHOULD send at least one solicitation in the case where an
   advertisement is received prior to having sent a solicitation."

Notice the "SHOULD", which is clearly not a "MUST" as would seem to be what
the PIO-less multicast RA sending approach would need to rely on. Thus, for
the scheme to work, you are either assuming:
1. A client IPv6 stack that follows more tightly (ie assumes MUST send an
RS) RFC4861.
OR
2. Expecting a change of RFC4861.

Which one is it?

Cheers,
Woj.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 25 Aug 2010 18:41:29 -0400

Hi Thomas,
   Thanks for going over the new version so quickly.

> nodes attached to the network can send packets directly to each

The nodes attached to different subscriber lines cannot directly send 
packets to each other. They need to talk through the edge router.

> individual customer. I assume that the Host/RG is a "customer".

Yes. Each customer will get different IPv6 prefixes. They will not share 
prefixes.

> directly to each other, or does such traffic need to go through the

All traffic needs to go through the edge router. There is no direct 
host-to-host communication allowed between different subscriber lines.

> depends on that circuit ID or that might vary from one RG to another.

Each customer needs to get a different prefix. The information that 
differs based on the Line ID is the prefix that gets inserted into the PIO.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 25 Aug 2010 18:47:45 -0400

Hi Woj,

On 10-08-25 11:56 AM, Wojciech Dec wrote:
>     I respectfully disagree. Here's why. The RS-mark mechanism describes
>     how RSs are marked and how the responding solicited-RAs are sent. It
>     has got nothing to do with other neighbor discovery messages. e.g.
>     Unsolicited multicast RAs, Redirects, DAD NS/NAs, Address resolution
>     NS/NAs etc. which are sent as defined in RFC4861/62. The draft
>     simply does not mention anything about these other messages. If you
>     can clarify why you think this is relevant to this draft, I will
>     certainly add it here.
> 
> 
> Your argument seems to be saying that the draft is not to 
> discuss/mention the overall context/intended usage of the mechanism and 
> that steam rolling a simple RS-marking mechanism is what should be 
> followed.
> I'm arguing, as are others, that the overall context and an 
> understanding of the scenario where the RS-mark mechanism is to be used 
> is required, as there appear to be issues there that are of relevance to 
> the IPv6 community. Given that you are one of the authors/proponents of 
> this draft/mechanism in both the IETF and in the BBF simultaneously, 
> it's only fair to ask you the question to explain the context & 
> assumptions, given that they are no-where to be seen publicly.

I think this is the basis of our disagreement. There are no assumptions 
that this document is making. There are usage scenarios not involving 
the mechanism proposed in this document that are relevant to this issue 
you are bringing up.

Let's say the mechanism proposed in this draft did not exist in either 
the IETF or BBF. Does the problem of the lost RSs exist? I contend that 
it does. What do you say? Unless we have a common view on this, I do not 
think we can agree on a resolution.

Thanks
Suresh

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 26 Aug 2010 10:19:25 +0200

On 26 August 2010 00:47, Suresh Krishnan <[email-masked]>wrote:

> that this document is making. There are usage scenarios not involving the
> mechanism proposed in this document that are relevant to this issue you are
> bringing up.
>

Indeed, this seems to be the base of the current misunderstanding. Based on
the available information, the intent of the rs-mark mechanism is to use the
additional line-id information at/by the edge-router to selectively assign a
*different* IP prefix to each subscriber (where subscriber = one or more
IPv6 end-devices behind a given Line-id). This has been corroborated by
statements made on the thread.
Based on all this, one can currently conclude that that such end-devices
will *only* obtain valid IP addressing info *after* they send an RS, and
then receive a response by means of a unicast RA, not at any time before
before. The latter aspect has been confirmed by the presence of periodic
PIO-less multicast RAs in the scheme.
Hence, I come to ask: Suppose an end-device time-outs in sending RSes before
getting an RA in response. How does a context relying on the rs-mark scheme
deal with this case? If the answer is "it uses PIO-less multicast RAs", then
it does not appear to be enough (based on RFC 4861 not mandating hosts to
respond to RAs). Alternatively, what assumptions are you going by (eg. a
special type of IPv6 end-device? a plan to modify rfc4861? other?)? IMO such
assumptions need to be documented

> Let's say the mechanism proposed in this draft did not exist in either the
> IETF or BBF. Does the problem of the lost RSs exist? I contend that it does.
> What do you say? Unless we have a common view on this, I do not think we can
> agree on a resolution.
>

I certainly agree with you that RS losses and/or timeout issues are not
unique to the rs-mark usage context, but unlike in the traditional case,
where periodically sent multicast RAs would contain a PIO allowing an
end-device to acquire an address, here I don't see how recovery from such
issues takes place. The result appears to be end devices having no IPv6
connectivity, which I'm sure you agree is not a good thing.
In other words, the RS lost/timeout problem appears to be particularly
severe in its consequences when used with what the RS-mark mechanism says it
is intended for.

Thanks,
Woj.

---

From: Thomas Narten <[email-masked]>
Date: Thu, 26 Aug 2010 08:37:34 -0400

I htink Woj is right and raises some fundamental issues.

The RS/RA mechanism *assumes* that routers send out periodic multicast
advertisements. Having nodes send out an RS to solicit RAs is a sort
of optimization, intended to prod routers into sending out an RA
immediately. But the sending of RSes is NOT a fundmental part of RAs.

Once a node has obtained an RA, the basic model assume that a node
need not send any additional RSs out. Periodic RAs will supply the
info it needs. This is made clear in RFC 4861, which says:

   Once the host sends a Router Solicitation, and receives a valid
   Router Advertisement with a non-zero Router Lifetime, the host MUST
   desist from sending additional solicitations on that interface, until
   the next time one of the above events occurs.

where the "above events" refers to things like the interface
restarting, attaching to a link again, etc.

In other words, once a node has received RAs, the protocols do not
require it to send additional RSs, even if it doesn't recieve RAs.

The only reason RSes are there in the first place is to handle
restarting nodes, who want to get an RA immediately instead of waiting
for the next periodic one.

This is not a flaw in ND. This was the intended design in an intended
operating environment.

What is proposed in Suresh's draft is a configuration that simply
doesn't match a normal network. Namely, a single broadcast domain, but
RAs tailored to individual clients.

I am not yet convinced that the IETF needs to (or should) support such
a configuration, as it is clear that even with the proposed option,
there are other issues with the target environment.

The Edge Router in the draft will be required to send unicast RAs to
all individual devices. It will need to maintain sufficient state to
do so, even if the Edge router restarts. Replacing the edge router
with some other router will cause problems because the new router
won't have the missing state, and there is no clear way to rebuild it.

What is the BBF solution to this problem? Has it thought this through?

A far better solution is for the AN node to have enough of an IP stack
on it so that it can source RAs and provide the right information.
Just because some "don't want to do this" (for cost or other reasons)
doesn't mean we should support it, especially if we don't think the
approach will be reliable or robust in practice. We should only bless
an approach if we think it can be made to work in practice.

Thomas

---

From: Alan Kavanagh <[email-masked]>
Date: Thu, 26 Aug 2010 08:58:47 -0400

big sigh in dealing with this absolutely silly response....oh well.

When you dont send an RS "regardless of the LIO" and the Edge Router is "configured to send an RA only when in receipt of an RS" then this case will fail even when you have a 1:1 VLAN scenario. So in the event that these hosts are SLAAC only based this is an issue and this occurs regardless of the LIO.

I agree with you this is an issue but not in the context of LIO for RS.

Alan

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wojciech Dec
Sent: August-26-10 4:19 AM
To: Suresh Krishnan
Cc: Brian Haberman; IPv6 WG Mailing List
Subject: Re: RS Lost failure scenario (Was Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt)

On 26 August 2010 00:47, Suresh Krishnan <[email-masked]<mailto:[email-masked]>> wrote:
Hi Woj,

I think this is the basis of our disagreement. There are no assumptions that this document is making. There are usage scenarios not involving the mechanism proposed in this document that are relevant to this issue you are bringing up.

Indeed, this seems to be the base of the current misunderstanding. Based on the available information, the intent of the rs-mark mechanism is to use the additional line-id information at/by the edge-router to selectively assign a *different* IP prefix to each subscriber (where subscriber = one or more IPv6 end-devices behind a given Line-id). This has been corroborated by statements made on the thread.
Based on all this, one can currently conclude that that such end-devices will *only* obtain valid IP addressing info *after* they send an RS, and then receive a response by means of a unicast RA, not at any time before before. The latter aspect has been confirmed by the presence of periodic PIO-less multicast RAs in the scheme.
Hence, I come to ask: Suppose an end-device time-outs in sending RSes before getting an RA in response. How does a context relying on the rs-mark scheme deal with this case? If the answer is "it uses PIO-less multicast RAs", then it does not appear to be enough (based on RFC 4861 not mandating hosts to respond to RAs). Alternatively, what assumptions are you going by (eg. a special type of IPv6 end-device? a plan to modify rfc4861? other?)? IMO such assumptions need to be documented

Let's say the mechanism proposed in this draft did not exist in either the IETF or BBF. Does the problem of the lost RSs exist? I contend that it does. What do you say? Unless we have a common view on this, I do not think we can agree on a resolution.

I certainly agree with you that RS losses and/or timeout issues are not unique to the rs-mark usage context, but unlike in the traditional case, where periodically sent multicast RAs would contain a PIO allowing an end-device to acquire an address, here I don't see how recovery from such issues takes place. The result appears to be end devices having no IPv6 connectivity, which I'm sure you agree is not a good thing.
In other words, the RS lost/timeout problem appears to be particularly severe in its consequences when used with what the RS-mark mechanism says it is intended for.

Thanks,
Woj.

Thanks
Suresh

---

From: Alan Kavanagh <[email-masked]>
Date: Thu, 26 Aug 2010 09:15:56 -0400

Hi Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: August-26-10 8:38 AM
To: Wojciech Dec
Cc: Brian Haberman; IPv6 WG Mailing List; Suresh Krishnan
Subject: Re: RS Lost failure scenario (Was Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt)

The RS/RA mechanism *assumes* that routers send out periodic multicast advertisements. Having nodes send out an RS to solicit RAs is a sort of optimization, intended to prod routers into sending out an RA immediately. But the sending of RSes is NOT a fundmental part of RAs.

Alan--> I don't see it as optomistation but a way to see the "First Sign of Life" which is a concept we have in BNG nodes and in BBF docs that we "trigger" an IP Subscriber Session based on some packet sent by the host, which maybe a DHCP_Solicit or a Router Solicitation. So the same sub session state mechanism applies here on the Edge Router (BNG) for RS messages, makes perfect sense.

Once a node has obtained an RA, the basic model assume that a node need not send any additional RSs out. Periodic RAs will supply the info it needs. This is made clear in RFC 4861, which says:

where the "above events" refers to things like the interface restarting, attaching to a link again, etc.

In other words, once a node has received RAs, the protocols do not require it to send additional RSs, even if it doesn't recieve RAs.
Alan--> Sure I agree. And as I noted above, we are waiting for the RS to trigger the IP Sub Session. What I really like about this is in a case where my Residential Gateway dies/acts stupid (lots of them do this ;-o ) and I call my DSL SP whom tells me to detach my RG and connect a host directly to my DSL modem. In the case of IPoE +  N:1 VLAN deployment model the host sends an RS etc....and the BNG receives this and triggers an IP Sub session. IF the BNG don't receive the RS then we have an issue somewhere on the path/host/network node etc...

The only reason RSes are there in the first place is to handle restarting nodes, who want to get an RA immediately instead of waiting for the next periodic one.

Alan--> Agree

This is not a flaw in ND. This was the intended design in an intended operating environment.

Alan--> Agree

What is proposed in Suresh's draft is a configuration that simply doesn't match a normal network. Namely, a single broadcast domain, but RAs tailored to individual clients.
Alan-->hmmm Are you suggesting that in the case of a single broadcast domain that the SP is better to advertise a single prefix to all attached hosts on the same b-cast domain? Hmm im sure we don't want to do that...and we decided in BBF from feedback from SP's that for their IPv6 Addressing model they "want a unique prefix per subscriber line". 

I am not yet convinced that the IETF needs to (or should) support such a configuration, as it is clear that even with the proposed option, there are other issues with the target environment.

Alan--> Well IETF don't advise DSL SP whats their network architecture or what features they need to support, and if we don't do this then a lot of SP's whom have an N:1 VLAN model and have a Bridged RG or bridge some IPoE session will have to spend ooodles of $$$$. I fail to see what is wrong with the LIO for RS, we do it dor DHCPv4/v6 and it makes perfect sense to mirror this to RS.

The Edge Router in the draft will be required to send unicast RAs to all individual devices. It will need to maintain sufficient state to do so, even if the Edge router restarts. Replacing the edge router with some other router will cause problems because the new router won't have the missing state, and there is no clear way to rebuild it.

Alan--> Yes have such requirements in BBF for maintaining state in the event of a reboot/node failure, so that's don't by most BNG vendors today ;-)

Alan--> as noted above.

A far better solution is for the AN node to have enough of an IP stack on it so that it can source RAs and provide the right information.
Just because some "don't want to do this" (for cost or other reasons) doesn't mean we should support it, especially if we don't think the approach will be reliable or robust in practice. We should only bless an approach if we think it can be made to work in practice.

Alan--> forcing the AN to keep state is not for the discussion here, I believe I spoke to you on this in Anaheim, it don't make $$$$ sense which means it aint going to happen no matter how hard you wish!!!!

Thomas

Alan--> In the end of the day its about having the choices so the Fixed SP can archtiect his network best suited to its needs.

---

From: Thomas Narten <[email-masked]>
Date: Thu, 26 Aug 2010 09:20:45 -0400

Suresh,

> packets to each other. They need to talk through the edge router.

How is this enforced? If I happen to know the mac address of my
neighbor's router (or host), can't I just send stuff directly?

If I happen to send bogus NAs to my neighbor, does the architecture
prevent this?

> host-to-host communication allowed between different subscriber

Will edge routers send redirects when "neighbors" are sending traffic
to each other? Or will the Edge Router become a performance bottleneck
when lots of traffic going through it is sent right back out on its
incoming interface?

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 26 Aug 2010 09:34:59 -0400

> Alan--> I don't see it as optomistation but a way to see the "First
> Sign of Life" which is a concept we have in BNG nodes and in BBF
> docs that we "trigger" an IP Subscriber Session based on some packet
> sent by the host, which maybe a DHCP_Solicit or a Router
> Solicitation. So the same sub session state mechanism applies here
> on the Edge Router (BNG) for RS messages, makes perfect sense.

It is an optimization from an IETF IPv6 architecture/protocol
perspective. It is an optimization in the sense that hosts will
operate correctly even if they *never* send out an RS. (They may not
have connectivity while waiting for an unsolicited RA, but they will
eventually get it.)

In other words, sending RSs is not *required* for correct
operation. And if your architecture requires that RSs be sent in order
to make things work, you will certainly to run into real problems.

> Alan--> Sure I agree. And as I noted above, we are waiting for the
>  RS to trigger the IP Sub Session.

And my point is you cannot assume you will always get an RS. And when
you do not, communication will fail and you will have people calling
your Help Desk.

There are scenarios that will happen in practice where you will not
get RSes when you think you will.

There is actually extensive experience with such failures on the IPv4
side with DHCP, where DHCP packets are needed to ensure that edge
routers (or whatever entitity it is) learn what subscribers are
active. They've had to extend/hack various DHCP protocols over the
years to handle all the failure cases. You would do well to learn from
their experience to be sure your approach covers all the cases they
experienced... (And from what I can, you have gaps.)

>  What I really like about this is in a case where my Residential
>  Gateway dies/acts stupid (lots of them do this ;-o ) and I call my
>  DSL SP whom tells me to detach my RG and connect a host directly to
>  my DSL modem. In the case of IPoE + N:1 VLAN deployment model the
>  host sends an RS etc....and the BNG receives this and triggers an
>  IP Sub session. IF the BNG don't receive the RS then we have an
>  issue somewhere on the path/host/network node etc...

Right. And things work again for a few weeks. Then they break
again. Then the customer goes through the same process. Multiply this
by millions of customers and ask yourself if the savings you derive
from cheap/dumb ANs makes up for your recurring Help Desk costs....

> Alan-->hmmm Are you suggesting that in the case of a single
>  broadcast domain that the SP is better to advertise a single prefix
>  to all attached hosts on the same b-cast domain?

Yes. That is what ND assumes. That is a basic assumption. 

If you have a different environment, you'd be far better off using
DHCP.

RAs are desgined/intended for environments where all nodes on the link
receive the same information. Where none of the RA options are "client
specicic" and where all RAs are periodically multicast at L2, because
all nodes get the same info. RAs work a lot less well (from a protocol
perspective) if you unicast RAs with client-specific information in
individual RAs.

DHCP is the much better choice for dealing with the type of scenario
you have architected.

> Hmm im sure we
>  don't want to do that...and we decided in BBF from feedback from
>  SP's that for their IPv6 Addressing model they "want a unique
>  prefix per subscriber line".

I have no problem with that. My problem is with how you are going
about architecting the overall solution.

> Alan--> Well IETF don't advise DSL SP whats their network
>  architecture or what features they need to support, and if we don't
>  do this then a lot of SP's whom have an N:1 VLAN model and have a
>  Bridged RG or bridge some IPoE session will have to spend ooodles
>  of $$$$. I fail to see what is wrong with the LIO for RS, we do it
>  dor DHCPv4/v6 and it makes perfect sense to mirror this to RS.

You can pay me know or you can pay me later (in help desk/operational
costs). :)

> Alan--> Yes have such requirements in BBF for maintaining state in
>  the event of a reboot/node failure, so that's don't by most BNG
>  vendors today ;-)

And the question I have (which you did not answer) is how do you
rebuild state when it is lost? And to repeat myself, you *cannot* rely
on RSes for this. I think your proposed approach has real gaps that
you have not considered (at least not from what I understand of the
overall approach).

Thomas

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 26 Aug 2010 19:20:35 -0400

Hi Thomas,

> I htink Woj is right and raises some fundamental issues.

Yes. And nobody said anything to the contrary. I problem is that the 
issue is orthogonal to the mechanism described in the RS mark draft. 
Even if draft-krishnan-6man-rs-mark was never written, this problem 
would still exist. I have tried to put the issue down in a draft so that 
we can discuss a workable solution. I would appreciate your comments on 
the draft.

http://www.ietf.org/id/draft-krishnan-6man-rs-lost-00.txt

> immediately. But the sending of RSes is NOT a fundmental part of RAs.

Right. And in this specific scenario routers DO send out periodic 
multicast advertisements as expected.

> info it needs. This is made clear in RFC 4861, which says:

I am not sure I agree with you on this one. Again, quoting from 
scripture (Section 6.3.7 of RFC4861):

"Responses to solicited advertisements may contain more information
  than unsolicited advertisements."

seems to indicate that the original ND spec anticipated the possibility 
that the periodic multicast RAs could contain less information that the 
solicited RAs.

> RAs tailored to individual clients.

I have to say that such networks are not uncommon and not limited to 
Broadband Forum access networks. e.g. A wireless lan network with 
multiple SSIDs and different vlans upstream to reach the router needs to 
act in exactly the same way in order to keep prefixes separate between 
the SSIDs.

> an approach if we think it can be made to work in practice.

This draft is a request for allocation of a destination option for 
implementing a BBF specific mechanism. It is specifically not a request 
for the IETF to bless the mechanism. The mechanism has been described in 
the draft to provide the background for the usage, as requested by the WG.

The way I see it, without this option, SLAAC-only hosts will be left 
without any way of obtaining an address in these specific deployments.

Thanks
Suresh

---

From: Ralph Droms <[email-masked]>
Date: Thu, 26 Aug 2010 20:18:40 -0400

Suresh...

On Aug 26, 2010, at 7:20 PM 8/26/10, Suresh Krishnan wrote:

> Yes. And nobody said anything to the contrary. I problem is that the issue is orthogonal to the mechanism described in the RS mark draft. Even if draft-krishnan-6man-rs-mark was never written, this problem would still exist. I have tried to put the issue down in a draft so that we can discuss a workable solution. I would appreciate your comments on the draft.
> 
> Right. And in this specific scenario routers DO send out periodic multicast advertisements as expected.

But the multicast RAs don't advertise prefixes, right, so the subscriber nodes won't be able to complete SLAAC?

> I am not sure I agree with you on this one. Again, quoting from scripture (Section 6.3.7 of RFC4861):
> 
> seems to indicate that the original ND spec anticipated the possibility that the periodic multicast RAs could contain less information that the solicited RAs.

I think the point is to use standard node stacks: Windows 7, OS X, Linux.  Do any of them send periodic RSs?

> I have to say that such networks are not uncommon and not limited to Broadband Forum access networks. e.g. A wireless lan network with multiple SSIDs and different vlans upstream to reach the router needs to act in exactly the same way in order to keep prefixes separate between the SSIDs.
> 
> This draft is a request for allocation of a destination option for implementing a BBF specific mechanism. It is specifically not a request for the IETF to bless the mechanism. The mechanism has been described in the draft to provide the background for the usage, as requested by the WG.
> 
> The way I see it, without this option, SLAAC-only hosts will be left without any way of obtaining an address in these specific deployments.

But this option isn't all that is needed for the deployment architecture, and it appears that there is a significant problem with that deployment architecture.  It makes sense to me to hold off on approving this option until the deployment architecture in which it will be used has been shown to be deployable.

> Suresh

- Ralph

---

From: Thomas Narten <[email-masked]>
Date: Thu, 26 Aug 2010 20:50:13 -0400

Let me ask some additional clarification questions.

Figure 1 contains both Hosts and RGs (residential gateways).

Is it a requirement that there be a single RG at each customer site,
and that RG then connects to the AN?

In other words, is the Edge Router sending RAs only to the RG, and is
it the RG that is sending RSes?

Or, is the RG optional, and can one (or more Hosts) connect directly
to the AN?

(I'm trying to understand who the Edge Router needs to send unicast
RAs to, and how it can keep track of who it needs to send such packets
to.  It would be considerably easier to do this if there was only one
device per customer. But if the customer may just be bridged to the AN
and Edge Router without having its own router at the edge, things
would seem more complicated, and an Edge Router would need to send
multiple unicast RAs to each customer site -- one for each device on
customer site!!!)

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Fri, 27 Aug 2010 10:28:16 -0400

Suresh - a further comment on using standard stacks.  There is a potential problem with using RA as "sign of life": if the node receives an unsolicited RS before it sends an RA, the node will accept that RS and never send an RA.  The node waits a random interval between 0 and 1 seconds before sending an RS and the default delay time between unsolicited RSs is 600 seconds (all of these details from RFC 4861).  If I have the scenario and details (choosing default values) all correct, that means the node has an average 0.00083 probability (1/1200) of receiving an RS before sending an RA.  So, roughly 1 in 1,000 nodes will fail to send an RA and trigger the unicast RAs.

Happy to hear where I'm confused...

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 27 Aug 2010 10:51:01 -0400

Josh Littlefield pointed out where I was confused - I reversed RS and RA, so my text should have read:

...a further comment on using standard stacks.  There is a potential problem with using RS as "sign of life": if the node receives an unsolicited RA before it sends an RS, the node will accept that RA and never send an RS.  The node waits a random interval between 0 and 1 seconds before sending an RA and the default delay time between unsolicited RAs is 600 seconds (all of these details from RFC 4861).  If I have the scenario and details (choosing default values) all correct, that means the node has an average 0.00083 probability (1/1200) of receiving an RA before sending an RS.  So, roughly 1 in 1,000 nodes will fail to send an RS and trigger the unicast RAs.

- Ralph

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 27 Aug 2010 14:56:55 -0400

Hi Thomas,

> it the RG that is sending RSes?

There are two scenarios.

Case 1: The RG is a router. In this case the Edge router sends RAs only 
to the RG.
Case 2: The RG is a bridge. In this case the Edge router sends the RAs 
directly to the hosts.

> Or, is the RG optional, and can one (or more Hosts) connect directly

 From a Layer 3 perspective, Case 2 above looks like the host connects 
directly to the AN.

> multiple unicast RAs to each customer site -- one for each device on

You are absolutely right. Earlier versions of this draft (without 
tunneling) allowed solicited multicast RAs to be tagged with the LIO and 
sent downstream to the AN.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 27 Aug 2010 19:33:14 -0400

Hi Ralph,
   <Snipped a whole lot of old quoting>

> But the multicast RAs don't advertise prefixes, right, so the subscriber nodes won't be able to complete SLAAC?

Correct.

> I think the point is to use standard node stacks: Windows 7, OS X, Linux.  Do any of them send periodic RSs?

No. All of them send RSs (3) on interface initialization. If no routers 
are found, there is no periodic retransmission mechanism like for DHCPv6 
Solicits. This is true of SLAAC in general (with or without RS marking).

> 
> But this option isn't all that is needed for the deployment architecture, 

Correct. But the rest is standard RFC4861/RFC4862 behavior.

> and it appears that there is a significant problem with that deployment architecture.  

I would not say it is a problem with the deployment architecture. As I 
said in mails to Thomas and Woj, the issue occurs in other deployment 
architectures that need to use different prefixes over the same shared 
L2 domain (e.g. WLAN AP with 2 SSIDs mapped into 2 VLANs on the fixed 
side connected to the edge router).

Thanks
Suresh

---

From: Thomas Narten <[email-masked]>
Date: Fri, 27 Aug 2010 19:42:25 -0400

Suresh,

> side connected to the edge router).

This is not a helpful comment.

Neighbor Discovery is simply not designed to operate cleanly in an
environment where different PIOs are advertised to different clients
over a shared LAN.

The fact is, any protocol is based on underlying assumptions (whether
stated explicitely or not). If you break those assumptions, but use
the protocol anyway, the protocol may not work so well any more. E.g.,
try running TCP across a path where 50% of the packets are lost due to
corruption.

The problem with the deployment architecture at issue is that it has
chosen to use RAs in such an environment.

The fact that the same issue would occur on other deployments that
made the same (broken) assumption, doesn't somehow mean the
architecture isn't broken.

Sheesh!

Thomas

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 27 Aug 2010 19:59:02 -0400

Hi Thomas,

> environment where different PIOs are advertised to different clients

I have realized that it *does not* operate cleanly in this scenario. I 
did not know it was *not designed to* operate cleanly in this scenario. 
This would have been very useful information to have in the ND spec.

> chosen to use RAs in such an environment.

I am really open to recommendations. What else can the network use to 
not run into problems?

> architecture isn't broken.

If the assumptions that the protocol designers made are not somehow 
communicated, people are bound to break them and find out the hard way 
(like in this case). The best insurance against this is to state the 
assumptions explicitly.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 27 Aug 2010 20:09:21 -0400

Hi Ralph,

On 10-08-27 10:51 AM, Ralph Droms wrote:
> References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <AANLkTikd=LPTNJXrcv6_Wwq8-jkHNEoCW9PsNqR=@mail.gmail.com> <[email-masked]> <AANLkTi=[email-masked]> <[email-masked]>! <[email-masked]> <[email-masked]> <[email-masked]> <5
[email-masked]> <[email-masked]>
> To: Suresh Krishnan <[email-masked]>
> X-Mailer: Apple Mail (2.1078)
> X-Brightmail-Tracker: AAAAARXElNoReturn-Path: [email-masked]
> X-OriginalArrivalTime: 27 Aug 2010 14:51:04.0609 (UTC) FILETIME=6226910:01CB45F7]
> 

There is a SHOULD level requirement on the node to send an RS even in 
this case. This is the relevant text from RFC4861 (Section 6.3.7)

"Moreover, a host
  SHOULD send at least one solicitation in the case where an
  advertisement is received prior to having sent a solicitation.
  Responses to solicited advertisements may contain more information
  than unsolicited advertisements."

Thanks
Suresh