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

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.