The MPLS WG Archive

["Sukanta Ganguly" <sganguly@opulentsystems.com>]

Arun,
   I am not sure what you mean by NHLFE for VPN. What would the LDP-VPN accomplish. For VPN to work the two ends of the VPN need to know each other. The intermediaries don't need to know where the VPN originated and where it will be termeniated. Are you trying to establish multiple smaller VPN's (i.e. tunnels) within the same VPN path? Why is that deemed necessary?
   With LDP you create a route awareness within the choosen LSR. If you use LDP for your VPN extension then it seems like you are trying to expand the routing/switching knowledgebase. It that the intent?


SG


*********** REPLY SEPARATOR  ***********

On 2/22/2002 at 8:27 PM Arun Kumar Dheena wrote:

>Rafal,
>
>> Yes, You miss few things.
>>
>> LDP is NOT routing protocol, so LDP cant populete VRF tables!
>>
>
>The basic idea of LDP-VPN is to form VPNs as in (similar to) BGP/MPLS VPN
>without using BGP. The LDP needs to be extended with additional TLV's and
>messages for this.  Please correct me if I am wrong with this approach.
>
>In LDP-VPN we create per-site-NHLFE (VPN) and NOT  VRF's. The LDP is used
>to
>populate the per-site-NHLFE (VPN) at the PE-LSR's.  This is done by
>LDP-VPN.
>This is just an idea. We don't need routing to create VPN's.
>
>> LDP run behind of IGP, but there are no IGP which may carry information
>about overlaping IP addresses (like BGP do by VPN-IPv4 NLRI). To use LDP
>you
>must develop IGP protocol. for OSPF it mean work from skrech. For IS-IS it
>is a little bit easier (IS-IS have also TLVs) Theoretically, it is possible
>to create something like VPN-IP v4 addrss family under IGP, but why do this
>when we have provent protocol - BGP.
>>
>
>By adding new TVL's (for eg., VPN-IPv4-TLV) in LDP, the LDP carries the
>VPN-IPv4 address. Thus it is possible to have over-lapping address space.
>Similarly,  we should add Community TLVs.   The routing between the PE-LSR
>and CE router needs to be explored.
>
>> When We use BGP we have ext. community to limit connectivity in VPM and
>for for example HUB-and-SPOK topology, Central Services Topology. Generally
>You cant provide overlaping VPN. Theoretically, it is possible to create
>something like community under LDP, but why do this when we have provent
>protocol - BGP.
>>
>> Additionally, BGP gives possibility to create Interprovidr VPN. LDP
>domain
>is limited to one ISP because LDP must run in connection with IGP.
>>
>
>True. It may not be possible.
>
>> Furthermore BGP is designed for realy large scale (in mean of number of
>routes) - other protocols not.
>>
>>
>> I suggest you to read RFC2547bis but also
>draft-martini-l2circut-trans-mpls (this use LDP for L2 VPN information
>propagation), and draft-kompella-ppvpn-l2vpn (this use BGP similiar to
>rfc2547bis)
>>
>>
>> Rafal Jan Szarecki
>> Senior System Engineer
>> ATM/IP Backbone Network
>> Ericsson Poland
>> Product and Solution Department (EPO/S)
>> *rafal.szarecki@epo.Ericsson.se
>> *rafal.szarecki@Ericsson.pl
>> *+48 602 418971
>> '+48 22 6916635
>>
>>
>> > -----Original Message-----
>> > From: Arun Kumar Dheena [mailto:arunkumar.dheena@wipro.com]
>> > Sent: Friday, February 22, 2002 1:08 PM
>> > To: mpls@UU.NET
>> > Subject: LDP - VPN
>> >
>> >
>> > 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).
>> >
>> > 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.
>> >
>> > 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.
>> >
>> > Thanks in advance.
>> > regards
>> > arun
>> >
>> > Wipro-CDC
>> >
>> >
>> >
>> >
>> >
>> >