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

["Hemant Singh (shemant)" <[e-mail]>]

Suresh,

>-----Original Message-----
>From: Suresh Krishnan [mailto:[e-mail]] 
>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