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

Hi Hamid,

Thanks for the feedback. Please see inline:

On Thu, 10 Jul 2003, Hamid Ould-Brahim wrote:

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

True.

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

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.

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

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.

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

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.

> 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").
>

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.

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

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

> Hamid.
>