Subject: draft-raggarwa-ppvpn-tunnel-encap-sig-01.txt...

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Thu, 10 Jul 2003 09:30:03 -0400

Rahul,

> 
> Noticed one minor detail in the agenda.
> draft-raggarwa-ppvpn-tunnel-encap-sig-01.txt should be in 
> common and not
> L3 as its applicable to both L2 and L3.
> 

Interesting and useful draft. Some comments on the draft
as well.

a) In fact, the proposal applies as well to MPLS-based pseudowires
   (not just VPNs) as specified in PWE3 that are using LDP
   for signaling. And it applies as well for l3vpn that uses
   VRs with BGP as the discovery mechanism.

b) If fact it is not required that on a given PE, 
   each VPN solution or signaling/discovery type protocol 
   advertises its encaps capabilities. If in a given PE only one of 
   the VPN service signals encaps capabilities, then potentially
   that encaps info can apply as well to the other VPNs
   without requiring the other VPNs to signal that info.
   This can be useful if one type of VPN has implemented the
   proposed extensions and the others didn't.

   This applies to cases where:

   - a PE is implementing l2vpn and Pseudowires
     (encaps cap infor received for pseudowire can apply to
     l2vpn as well for that particular PE).
   - a PE implementing l3vpn and l2vpn. 
   - a PE implementing l3vpn, l2vpn, and pseudo-wire
   - a PE is implementing a BGP signaling and LDP signaling
     (for example kompella-l2vpn and Martini pseudowires).

Advertising the capabilities for one VPN type can apply 
as well to the other even when the two solution types have noting 
in common (besides sharing the same tunnel). 

The only problem is when LDP is used, the set of
encaps capabilities are limited to MPLS-in-x where in BGP
case the set is much bigger. Maybe this is not a major problem
since most of network-based l2/3vpns are mostly MPLS/l2tpv3 based.

c) The draft assumes that traffic will always traverse
   the "control" PE. There is actually a case where the l2vpn 
   traffic may traverse a different node other than the "control" 
   intermediate PE. For example when splicing pseudowires, the 
   intermediate node may signal to the upstream PE the true endpoint 
   (and PW label) of the downstream PE. In that case it may be desirable for
   the capabilities of the downstream PE to be known
   to the upstream PE not just to the tandem PW node.
 
d) A suggestion is to indicate that when LDP signaling 
   is used but the encapsulation capabilities are only carried 
   within BGP discovery then only "MPLS-in-x" type encaps can 
   be applicable (even if the set of encaps supported on the PE
   includes not just "MPLS-in-x").   

f) Section 6.2 mentions that it is possible that for the same PE
   different encaps can be used for some VPN routes. I assume it 
   is as well possible to indicate to the remote PE the preferred 
   encaps for a set of VPNs. For example, by including the
   set of communities with the encaps attribute advertised.

Hamid.

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 10 Jul 2003 14:54:03 -0700 (PDT)

Hi Hamid,

Thanks for the feedback. Please see inline:

>    VRs with BGP as the discovery mechanism.

True.

>    proposed extensions and the others didn't.

If BGP is used for auto-discovery, encapsulation capabilities will be
advertised per next-hop. All L2 or L3 VPNs using that next-hop as the
remote peer's address can then use these encapsuation capabilities.

> since most of network-based l2/3vpns are mostly MPLS/l2tpv3 based.

If BGP is being used for auto-discovery in L2 VPNs, the applicability of
signaling the encap capabilities in LDP is not very clear. We decided to
leave it in the draft at this point. And as you said LDP will be used only
for MPLS-in-X capabilities.

>    to the upstream PE not just to the tandem PW node.

This is a good point. If BGP is used for auto-discovery, this is
not an issue. If not, we need to take care of this case. The encapsulation
capabilities of the downstream PE will have to be relayed to the upstream
PE by the tandem node.

>    includes not just "MPLS-in-x").

This is probably not an issue. Only MPLS-in-x encaps will be used while
tunneling MPLS traffic. Hence LDP signaled PWs will use only that. Other
VPns/Services can still use the non MPLS-in-x encaps.

>    set of communities with the encaps attribute advertised.

If there is a requirement, it is possible to indicate this
preference, by either enhancing the TLVs in the attribute or by using
communities.

Thanks,
rahul