Subject: RE: FW: WG Last Call on ARPmediationdraft:draft-ietf-l2vpn-arp-mediation-01.txt

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 26 Apr 2005 11:47:08 -0400

Hi Mark,

Thanks for your comments.

Response in line below, marked with himanshu>

Also, I am re-writing section 4.4 CE devices using PPP
(sending this in next message).

regards,
himanshu

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Mark Lewis
> Sent: Thursday, April 21, 2005 3:04 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: FW: WG Last Call on
> ARPmediationdraft:draft-ietf-l2vpn-arp-mediation-01.txt
> 
> 
> Hi Vach,
> 
> I have added comments inline below. Please excuse any
> off-the-mark comments that I may have added in my haste to
> review it and then get back to what I should really be doing
> right now (work!).
> 
> Hope it's useful!
> 
> Mark Lewis
> 
> 
> 
> 
> 
>       
> Abstract  
>      
> In particular, the applicability of ARP mediation to ISIS is
> not addressed.
> 
> 
> ****Is it worth mentioning that ARP mediation is not relevant
> in the case of IP mode interworking simply because IS-IS PDUs
> are not sent over IP?
> 
>

himanshu> I will add it in.

>   
>      
> 
>      
> 1.0 Introduction 
>      
> In theory, L2VPNs can carry any Layer 3 protocol, but in many
> cases, the  Layer 3 protocol is IP.  
>  
> 
> *****Again, is it worth saying that L2VPNs can, in theory,
> carry any Layer 3 protocol except in the case of an L2VPN in
> which IP mode interworking is being performed (in which case,
> obviously only IP transport is supported over the pseudowire)?
> 
>      
> 
himanshu> I will add it in.

>      
> 4.1 Monitoring Local Traffic 
>      
> The PE devices may learn the IP addresses of the locally
> attached CEs from any IP traffic, such as link local multicast
> packets (e.g., destined to 224.0.0.x), and are not restricted
> to the operations below.  
> 
> *****Is it worth mentioning broadcast packets as well (ie.
> ‘..such as link local multicast packets or broadcast packets…’)?
> 
> 
himanshu> Directed broadcasts will produce MAC broadcast packet.
himanshu> however the source IP address is not necessarily local CE's 
himanshu> IP address. Hence broadcast packet is not mentioned.

>      
>  
>      
> 4.3 CE Devices Using Inverse ARP 
>      
>    
> This is a typical operation for Frame Relay and ATM attachment
> circuits. When the CE does not use Inverse ARP, PE could still
> discover the local CEs IP address as described in section 4.1
> and 4.5.  
> 
> 
> *****Worth mentioning that ARP mediation may not be necessary
> on FR/ATM attachment circuit if the CE device is configured
> with a point-to-point (sub)interface or a static mapping
> statement (no inverse-ARP)?
> 
>

himanshu> ARP mediation is necessary even in absence of CE's
himanshu> inverse ARP. Because the local CE's IP address still
himanshu> needs to be notified to remote PE so he can do proxy
himanshu> ARP. In such configurations (i.e. when CE device is 
himanshu> is configured with inverse-ARP disabled or has a 
himanshu> static mapping), we have found in lab testing with 
himanshu> some routers that CEs do respond to inverse-ARP request
himanshu> if one was sent by PE. This allows PE to learn CE's
himanshu> IP address.

> 4.4 CE Devices Using PPP 
> 
> When a PPP link becomes operational after the LCP
> negotiations, the local PE performs following actions 
> . If the local PE does not know the IP address of the local
> CE, it generates a configure-request without the configure IP
> address TLV. The response from CE is accepted as IP address of
> the local CE. 
> . If PE knows the IP address of the remote CE, it sends an
> IPCP configure-request with the IP address of the remote CE in
> the configure IP address TLV 
> 
> *****Are you referring to the IP Control Protocol [IPCP]
> IP-Address option (0x03) here? I know that it’s a TLV, but
> don’t most people refer to it as I’ve stated, rather than a
> ‘configure IP address TLV’? Also, I think most people
> capitalize the PPP message names (eg. ‘Configure-Request
> [CONFREQ]’), although I can’t remember of the top of my head
> whether they are capitalized in the relevant RFCs.
> 

himanshu> I will make the changes.

> 
> . If the local PE receives an IPCP configure-request without
> the configure IP address TLV, and if it knows the IP address
> of the remote CE, it responds with configure NAK with the
> configure IP address TLV set with remote CEs IP address.
> However, if PE does not know the remote CEs IP address yet, it
> responds with a configure NAK. 
> 
> ******‘Configure-Nak [CONFNAK]’ rather than ‘configure NAK’??
> 

himanshu> Yep.

> 
> . If the local PE does not know the IP address of the remote
> CE, it sends an IPCP configure-request with IP address as
> zero. The response from CE is recorded and used to validate
> the incoming remote CEs IP address via PW signaling. 
> 
> ******Again, don’t you think that ‘IPCP Configure-Request
> [CONFREQ] with the IP-Address option [0x03] as zero’ might be
> more appropriate than ‘IPCP configure-request with the IP
> address as zero’??
>          
> The local PE must deny configurations such as header
> compression and encryptions in the NCP packets with such options. 
> 
> ******How about the following wording- ‘The local PE device
> must deny the configuration of Network Control Protocol [NCP]
> options such as the IP-Compression Protocol [IPCP option
> 0x02],….’. Not sure what you are referring to when you say
> ‘encryptions’- are you referring to the Encryption Control
> Protocol [ECP], or something else??
> 
>

himanshu> I meant option 2. I will make the changes.
      
> 
>      
> 5.0 CE IP Address Signaling between PEs 
>      
> 
> ******How about for L2TPv3? I must admit I can’t recall an
> L2TPv3 AVP that would allow the advertisement of the local
> CE’s IP address to the remote PE, but I may well be a little
> behind the times on this! I guess that if such an AVP exists
> (or will exist), it would have to be advertised either in the
> ICRQ/ICRP/ICCN or SLI (where discovery of the CE’s IP address
> did not coincide with pseudowire establishment)??
> 
> 
>

himanshu> We have not considered other PW signaling mechanisms
himanshu> in this draft. - may be future work item
 
>      
>  
>      
> 6.3 CE Devices Using PPP 
>          
> When the PE learns the remote CE's IP address, it should
> initiate the Configure-Request using the remote CE's IP
> address or respond to pending Configure-Request from the local
> CE. As noted earlier, all other configuration options related
> to compression, encryptions, etc., should be rejected. 
> 
> *****Specify the use of the IPCP IP-Address option [0x03]
> here, too?
> 

himanshu> Yes.

>        
> 7.1 OSPF  
>          
> 
> It is strongly recommended that all OSPF protocols on CE
> devices connected to Ethernet interfaces use this
> configuration option when attached to a PE that is
> participating in an IP L2 Interworking VPN. 
> 
> ******Might it be worth stating that the manual configuration
> of OPSF network type might also be required on other CE
> interfaces types in an L2VPN interworking environment? For
> example, if a CE device has a multipoint Frame Relay
> interface, it may default to an OSPF network type of NBMA??
>      
>      
> 
> 
>

himanshu> I am not sure if multipoint frame relay interface
himanshu> works with point-to-point OSPF network type.
himanshu> Would other DLCIs be inactive?