The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Feb> msg00189



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

LDP - VPN

  • From: "Arun Kumar Dheena" <arunkumar.dheena@wipro.com>
  • Date: Mon, 25 Feb 2002 18:25:36 +0530
  • Cc: <ppvpn@ppvpn.francetelecom.com>
  • Organization: www.wipro.com

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.



 ********************************************************************

  • Follow-Ups:
    • LDP - VPN
      • From: Eric Rosen <erosen@cisco.com>
    • LDP - VPN
      • From: Robert Raszuk <raszuk@cisco.com>
    • LDP - VPN
      • From: Giles Heron <giles@packetexchange.net>
  • References:
    • LDP - VPN
      • From: "Miguel Angel Chana" <machana@cisco.com>