The MPLS WG Archive

[Giles Heron <giles@packetexchange.net>]

But why would we bother?

draft-martini is for point-to-point circuits.   Targetted LDP is ideal 
for this because it sets up point-to-point "signalling" sessions between 
the two PEs that share the circuit.  No other PE would want to know this 
information, so using BGP and route-reflectors would seem an inefficient 
way to distribute this information (though I guess you could do some 
sort of filtering based on extended communities?)

draft-lasserre-vkompella extends draft-martini for multipoint L2VPNs 
using Ethernet.  This also fits targetted LDP well since the MAC 
learning requirement of the L2 VPN requires that a PE distribute a 
distinct VC label to each peer PE.

For an L3 VPN, however, a PE will generally want to distribute an 
identical label to each peer PE.  BGP and route reflectors would seem 
like a better way to do this than using LDP (in the absence of a "FEC 
reflector").

Giles

Arun Kumar Dheena wrote:

> Hi,
>        Thanks for your replies.
> 
> The draft-martini-l2circuit, does establish point-to-point tunnel between
> PE-LSR's. It maps the incoming L2 traffic onto the corresponding
> point-to-point tunnel.
> 
> Suppose, if we establish direct LDP session between PE-LSRs as in
> martini-drafts  but instead of  exchanging L2 information (as in L2VPNs) we
> exchange L3 VPN related information as in BGP/MPLS VPN (by defining
> RouteTarget-TLV, VPN-Label, VPN-IPv4 TLV to the LDP etc), we (might) get a
> Layer 3 VPN without using BGP.  With filtering capabilities, LDP-VPN can
> support the features as in BGP/MPLS VPNs. The PE-LSR - CE routing has to be
> explored in this approach.
> 
>  What are the flaws/disadvantages in this approach. Is this worthwhile?
> 
> As Miquel has mentioned, the PE-LSR's has to be fully-meshed but only in the
> "worst case" (because,  a PE-LSR will establish a LDP session with another
> PE-LSR only if they have a VPN-site in common). Yes, this is a limitation
> but then there is no FEC reflector(!) concept in LDP.
> 
> 
> Thanks in Advance
> 
> regards
> arun
> 
> 
> 
> 
>>>Hi,
>>>      The RFC 2547bis uses BGP to distribute the VPN routes.
>>>But, we can
>>>modify LDP itself to carry the information carried in BGP like the VPN
>>>routes, route targets and VPN labels etc (by defining, new
>>>TLVs and new LDP
>>>messages).
>>>
>>>
>>LDP distributes LABELS bindings to FECs, those being IPv4, VPNv4,
>>MAC addresses, VC's or whatever else. Imagine a situation where
>>PEs are separated by LSR routers that do not have any notion of
>>the FEC for which you are binding the label. Since they don't
>>understand the FEC, they can not give you a label binding. This
>>is why LDP directed sessions are used for anything else than
>>IPv4 (for example, Martini). Either that or you have to do all
>>the LSR in the path "aware" of the FEC. The idea of MP-BGP is
>>pretty much the same, you are using BGP sessions between all the
>>peers to exchange VPNv4 information.
>>
>>
>>
>>>The motivation for this is, firstly, the LDP-VPNs can provide the same
>>>scalability as in mentioned RFC2547, as the intermediate
>>>LSR's (P routers)
>>>need not maintain the VPN-Lables and routes. (This can be achieved by
>>>maintaining LDP sessions between the PE LSR's). Secondly, we
>>>can avoid using
>>>BGP for MPLS-VPNs.
>>>
>>Sure you can, but in this case remember you will have to maintain
>>a LDP session for each of the PEs (full mesh) I'd like to see you
>>maintaining a couple hundreds PEs with full meshing requirements,
>>without all the handy mechanisms BGP has (for example, Route Reflectors)
>>Or maybe we can add the notion of Route Reflectors to LDP...
>>
>>
>>>Will this apparach be an alternate for BGP/MPLS VPN?
>>>Or am I missing something  fundamental?
>>>I want to know whether any work has been done in this direction.
>>>
>>>
>>Ask the folks at PPVPN
>>
>>
>>
>>>Thanks in advance.
>>>regards
>>>arun
>>>
>>>Wipro-CDC
>>>
>>>
>>>
>>>
>>>
>>>
>>>
> 
> 
> ------------------------------------------------------------------------
> 
> **************************Disclaimer************************************
>       
> 
> 
> Information contained in this E-MAIL being proprietary to Wipro Limited
> is 'privileged' and 'confidential' and intended for use only by the
> individual or entity to which it is addressed. You are notified that any
> use, copying or dissemination of the information contained in the E-MAIL
> in any manner whatsoever is strictly prohibited.
> 
> 
> 
>  ********************************************************************
> 


-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================