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 adopting:draft-krishnan-6man-rs-mark-06.txt 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 protected] [mailto:[email protected]] 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 On 8/10/10 2:08 PM, "Brian Haberman" <[email protected]> wrote: > 6MAN WG, > This is a consensus call on adopting: > > Title : Line identification in IPv6 Router Solicitation > messages > Author(s) : S. Krishnan, et al. > Filename : draft-krishnan-6man-rs-mark-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 > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
