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

From: Mark Lewis <[email-masked]>
Date: Thu, 21 Apr 2005 20:04:02 +0100

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?

     
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)?

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…’)?

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)?

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.

. 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’??

. 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??

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)??

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?

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??