Suresh, >-----Original Message----- >From: Suresh Krishnan [mailto:[email protected]] >Sent: Friday, August 13, 2010 4:17 PM >To: Hemant Singh (shemant) >Cc: Wes Beebee (wbeebee); Brian Haberman; IPv6 WG Mailing List >Subject: Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt
>Hi Hemant, >On 10-08-13 02:19 PM, Hemant Singh (shemant) wrote: >> 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. >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. 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
