Subject: IP PW establishment in draft-ietf-l2vpn-arp-mediation-09.txt

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Fri, 4 Apr 2008 10:16:26 -0500

Himanshu and all,
I am sorry I am bringing this late in the game but I believe there is an
issue with the signaling procedures of the IP PW in this draft.

Specifically, Section 6.2 states the following:
"
	As defined in [RFC4447], when processing a received PW FEC, the 
     PE matches the PW ID and PW type with the locally configured PW 
     ID and PW Type. If there is a match, and if the PW Type is IP 
     Layer2 Transport the PE further checks for the presence of an 
     Address List TLV (as specified in [RFC 3036]) in the optional 
     parameter TLVs. If absent, a Label Release message is issued 
     with a Status Code meaning "IP Address of the CE is absent" 
     [note: Status Code 0x0000002D is pending IANA allocation] to 
     reject the PW establishment.
"

I do not think we can mandate that if the Address List TLV was not
present, the label must be released. I am saying this as the IP PW type
has been defined in RFC 4447 and there is no such a constraint on the
setup of this type of PW in this RFC. 

There are deployed implementations which use the IP PW with static CE
address configurations and which will just not check for the address
list TLV. Yet, these implementations are compliant to RFC 4447.

I can think of one way of addressing the backward compatibility with RFC
4447 and that is to follow what we have done for the PW Status TLV. This
TLV is included in the Label Mapping Message with the I-bit (ignore bit)
set. Only if both PEs have included the Address List TLV in the Label
Mapping message that it can be used subsequently inside a Notification
message.

This issue also exists in the IPLS draft.

Regards,
Mustapha.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 8 Apr 2008 12:00:01 -0400

Hi Mustapha,

Thanks for bringing this issue to the list as
this has implication on interoperability with
other implementations.

Here are my thoughts -
1) ARP mediation requires that both PEs exchange
   IP address of the local CEs. This enables local PE
   to do proxy for remote CE. This is one of the important
   aspect of the mediation.

2) When PE is configured for ARP mediation,
   it advertises this capability by including the address list 
   TLV in PW FEC advertisement. In turn, it depends on peer to
   reciprocate the same. 

3) when there is a capability mismatch, especially the one on which
   the receiving PE depends on peer to have, it has the right to disengage.
   I do not believe this is contrary to RFC 4447. IP PW is the conduit 
   and for the data plane. IP PW is not ARP mediation.

4) As for using static configuration, ARP mediation draft describes how
   it can be done when using ARP mediation. One could very well do static
   configuration such that both the local & remote CE's IP address is
   configured at both the PEs, in which case there is no need to exchange
   IP addresses between the PEs. For this case, ARP mediation capability
   is not configured. May be draft needs to add text to clarify this case.
   However, what is not cool is asymmetry whereby PE1 has the capability
   configured and PE2 does not but still accepts the PW label mapping
   FEC and keeps the PE1 in limbo. 

/himanshu

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> AISSAOUI Mustapha
> Sent: Friday, April 04, 2008 11:16 AM
> To: [email-masked]
> Subject: IP PW establishment in draft-ietf-l2vpn-arp-mediation-09.txt
> 
> 
> Himanshu and all,

---

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Tue, 15 Apr 2008 11:41:18 -0500

Himanshu,
I understand the importance of exchanging the CE IP address for the
purpose of ARP proxy. 

However, the static configuration of CE IP addresses is still an ARP
mediation function. This is because the ARP proxy is still using the
configured Ethernet CE address to ARP for the CE MAC address. So, you
cannot say that "ARP mediation capability" should be disabled in this
case.

What needs to be disabled is the advertising of the Address List TLV.
This can be done by configuration such that even if one PE advertised it
in the label mapping message but not the other, none of them will use it
in a subsequent notification message. However, this is a
misconfiguration and what will happen is the PW will be up but unicast
IP packets will not flow. This is the behaviour anyways if a PE has not
yet learnt the Ethernet CE IP address.

As for the backward compatibility with RFC 4447, it is related to the
fact that many applications can use a specific PW type. For example,
both Ethernet VPWS and VPLS will make use of it. Yet, none changes the
signaling procedures in RFC 4447. ARP mediation with static
configuration and with automatic CE discovery are just two applications.
IPLS is another one. There may be others in the future.

Given that we have deployments of the static ARP mediation capability, I
really think we should address the backward compatibility with RFC 4447.
What I proposed with the I-bit is just a proposal but I am open for
other ways to resolve it.

Mustapha.

> From: Shah, Himanshu [mailto:[email-masked]] 
> Sent: Tuesday, April 08, 2008 12:00 PM
> To: AISSAOUI Mustapha; [email-masked]
> Subject: RE: IP PW establishment in 
> draft-ietf-l2vpn-arp-mediation-09.txt
> 
> Hi Mustapha,
> 
> Thanks for bringing this issue to the list as this has 
> implication on interoperability with other implementations.
> 
> Here are my thoughts -
> > [mailto:[email-masked]]On Behalf Of AISSAOUI Mustapha