Subject: Re: WG Last Call on ARPmediation draft:draft-ietf-l2vpn-arp-mediation-01.txt

From: Luca Martini <[email-masked]>
Date: Thu, 05 May 2005 23:49:48 -0600

Himanshu,

more comments in line.
Thanks.
Luca

Shah, Himanshu wrote:

> Hi Luca, Thanks for your comments. Responses in line marked with 
> "himanshu>"   regards, himanshu
>
>     -----Original Message-----
>     *From:* [email-masked] [mailto:[email-masked]]*On
>     Behalf Of *Luca Martini
>     *Sent:* Monday, April 25, 2005 9:21 PM
>     *To:* [email-masked]
>     *Cc:* [email-masked]
>     *Subject:* Re: WG Last Call on ARPmediation
>     draft:draft-ietf-l2vpn-arp-mediation-01.txt
>
>     Vach,
>
>     I finally had made the time to read this draft. Here are some
>     comments:
>
>     - I'll say it first ( I'm sure the IESG would say the same ) :
>     there seem to be a bit too many authors. I think this list needs
>     to be trimmed to people you can attribute some text in the
>     document to. I believe 5 authors is the maximum, without having to
>     really justify it.
>     [himanshu>] Noted. 
>     - The introduction section needs to make it clear that A PW of
>     type IP is used. It should reference PWE3-CONTROL.
>     [himanshu>] Noted. 
>     - Please fix all the non-ASCII characters in the document , Lot's
>     of "CE0x??E" and others. you need to turn off MS-word automatic
>     character substitution, or better still use emacs ;-)
>     [himanshu>] Noted 
>     - Please change all the PWE3-IANA to PWE3-CONTROL. The IANA
>     document only specifies a PW type number , nothing more.
>     [himanshu>] Noted.  
>     - Section 3.0: PWs are bi-directional by definition , so remove
>     the text "bi-directional"
>     [himanshu>] Noted 
>     - Section 4.2 with  the topology restriction to only one CE ,
>     promiscuous ARP can be used to really simplify things. The
>     explanation should be added here.
>     [himanshu>] I am not sure what exact method you have in mind. Can
>     you elaborate??
>
yes. If you restrict the ethernet broadcast domain to include only one 
host  ( i.e. only one host is on the vlan , or attached to the ethernet 
port ) then it is possible to do promiscuous ARP on behalf of the remote 
link ip address. This means that any arp requests will be answered by 
the PE. I designed a prototype , and actually built PE with this 
capability. it worked quite well. This was presented in an mplscon 
conference about 3 years ago. I will send you the slides in a separate 
e-mail.

>     - Page 5 has some nordic region O characters in it ... not English.
>     [himanshu>] noted. 
>     - section 5.2 and page 8. Define the IP Address interface
>     parameter , I believe it has been allocated in IANA so put the
>     number in here.
>     [himanshu>] I checked in the latest IANA draft, there is no
>     interface parameter for IP address. Besides, IP address in not
>     intended to be part of the interface parameter because that would
>     make it a static PW attribute. It is intentionally passed in the
>     optional parameter field of the Label Mapping message as the IP
>     address may not available when the PW FEC is exchanged. That is, 
>     IP L2 Transport PW must be allowed to be established before the IP
>     address of the local CE is known. This way, multicast packets can
>     flow (such as OSPF hello) between the CEs, which in turn causes
>     ETH-CE to ARP for his peer. If ETH-attached PE is strictly
>     learning CE's IP address from ARP packets, this enables PE to
>     learn CE's IP address and can now send an update in LDP
>     NOTIFICATION message.
>      
>
Sorry my mistake . I remember the conversation a couple of years ago , 
yes it cannot be an interface parameter.

>     This section needs some major additions. There is no clear
>     description on how to work with the IP interface parameter. What
>     LDP notification message ? I do not recall defining anything other
>     then PW status messages. There is no way to change an interface
>     parameter once the PW is established. ( This is not an auxiliary
>     control channel ... it's static , can only be used once )
>     [himanshu>]  That is right. And hence there is no IP interface
>     parameter. Me and Hamid had written a
>     draft-shah-pwe3-control-protocol-extension-00.txt back in 2003.
>     This draft described how PEs can exchange capabilities and PW
>     attributes thereafter via LDP NOTIFICATION. About 4 cases were
>     sited in that draft, PW status, PW QOS, CE's IP address and CE's
>     IP and MAC address (used for IPLS). Out of which, you included the
>     PW status in the base PWE3-control draft but not others. Well, we
>     need the rest. Since that draft has expired, I have included the
>     text describing how exchange of CE's IP address can be conducted
>     as part of optional TLV of the LABEL MAPPING msg and LABEL
>     NOTIFICATION msg in this draft.
>
ok. Still you need a little more explanation how the IP address TLV is 
sent. what LDP message is it part of ? If is is part of a new ldp status 
message ?

Luca

>       Spacing is wrong at the section 6.0 heading
>     [himanshu>] Noted 
>     -PWE3 Control draft must be made normative. ( The procedures
>     described here are not implementable without pwe3-control )
>     [himanshu>] Noted 
>
>     Thanks.
>     Luca
>
>
>     Vach Kompella wrote:
>
>>Two weeks are almost up, and there have been no comments on this draft.
>>Either everyone is comfortable with the draft, or no one cares.  In
>>either case, we would like to hear comments.
>>
>>-Vach 
>>
>>  
>>
>>>-----Original Message-----
>>>From: [email-masked] [mailto:[email-masked]] 
>>>On Behalf Of Vach Kompella
>>>Sent: Wednesday, April 06, 2005 1:08 PM
>>>To: [email-masked]
>>>Subject: WG Last Call on ARP mediation 
>>>draft:draft-ietf-l2vpn-arp-mediation-01.txt
>>>
>>>
>>>Folks,
>>>
>>>We are starting a 2 week working group Last Call on the ARP 
>>>mediation draft.  Please read and send comments to the list.
>>>
>>>Thanks.
>>>
>>>Vach Kompella
>>>IP Division, Alcatel
>>>[email-masked]
>>>+1 650 623-2556
>>>
>>>
>>>    
>>>
>>
>>  
>>
>