Subject: LDP usage in MPLS based VPNs

From: Ramyanshu Datta <[email-masked]>
Date: Thu, 27 Sep 2001 04:09:29 -0700 (PDT)

hi,
 
   the present  rfc on MPLS based VPNs uses BGP for
route  distribution. Can we  use LDP in place of BGP
for the same purpose.  and has  there been any work
done in this direction. if yes then please tell me the
links where i can find information about it

Thanks in advance
Ramyanshu

__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

---

From: Jay Karthik <[email-masked]>
Date: Thu, 27 Sep 2001 09:12:38 -0400

LDP does not have a provision to carry information like VPN-IPv4 Address 
Family and can't be a substitute for BGP in implementing VPN. But the core 
routers in the provider domain, can facilitate PE to PE communication even 
without BGP being enabled.

Jay

---

From: Eric Gray <[email-masked]>
Date: Thu, 27 Sep 2001 14:59:39 -0400

Ramyanshu,

    I assume you're talking about RFC 2547.  Another RFC on
VPNs over MPLS (RFC 2917) mentions BGP only to say that
- unlike RFC 2547 - it does not require BGP.  Note that RFC
2547 is entitled simply "BGP/MPLS VPNs".

    This RFC currently enjoys an 'Informational' status, it does not
attempt to represent itself as the one and only way of doing VPNs
using MPLS and it's actually an RFC on BGP based VPNs using
MPLS.  It cannot therefor be surprising that it uses BGP for VPN
route distribution.  :-)

    Any scheme which allows provider 'edge' devices (any kind of
device - not necessarily a router) to establish a label distribution
relationship with possibly remote other provider 'edge' devices -
and ensures that intermediate systems (if any) will forward packets
between these devices without modifying the labels distributed -
can be used to support a VPN service over MPLS.

    It happens that BGP is aptly suited to this purpose in certain
applications, with only relatively minor enhancements.  It is also
the case that there are numerous concerns about the scalability
of route table sizes using this approach in other applications.

--
Eric Gray

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 27 Sep 2001 12:07:16 -0700

Ramyanshu,

> for the same purpose.

Sure you can - both LDP & BGP are protocols quite open for new
extensions. But why anyone would like to complicate it's life going up
the hill and reinventing the already pretty well rolling wheel in
ISPs/SPs environments worldwide ???? 

Have you even thought about the concequences of your request just to
name one re-invention of reflectors this time for LDP etc .... :).,

R.

> Ramyanshu Datta wrote:

---

From: Eric Gray <[email-masked]>
Date: Thu, 27 Sep 2001 15:24:28 -0400

Jay,

    The phrase/term 'VPN-IPv4 Address Family' is certainly misleading, if it
is not also an outright misnomer.  There is nothing at all special about it
and
there is no (IANA) assigned family identifier associated with it.  It is, in
fact,
special only to BGP.  Indeed, it should have been identified as an address
'format', rather than an address 'family'.

    As you know, the distinction between this address format and that of IPv4
is that it includes an 8 byte route distinguisher (RD) and a 4 byte IPv4
prefix.
Other VPN proposals uses a (proposed standard) VPN identifier (consisting
of a 3 byte OUI and a 4 byte index - or 7 bytes total), instead of a route
distinguisher.  See RFC 2685 for more about VPN Identifiers.  Note that it
would be a trivial matter to embed a VPN ID in an RD.

--
Eric Gray

---

From: Ajay Simha <[email-masked]>
Date: Thu, 27 Sep 2001 15:52:47 -0400 (Eastern Daylight Time)

> would be a trivial matter to embed a VPN ID in an RD.

Eric,

If in fact we want to use VPN ID (rfc 2685) to uniquely identify a vpn, RD and
VPN ID may not be interchangeable in all situations.  For example, for the
same VPN in a hub-and-spoke scenario, we may need to have 2 different RDs for
at the hub site (since we need to keep the routes on seperate VRFs) and thus
precluding use of vpnid in place of rd.

Thoughts?

-ajay
> > -- > Eric Gray

-- 
Ajay Simha
MPLS Deployment Engineer
IOS Technology Division
(919) 392-3141

"Study as if you were to live forever
 Live as if you were to die tomorrow"

 - Mahatma Gandhi

---

From: Eric Gray <[email-masked]>
Date: Thu, 27 Sep 2001 17:50:26 -0400

Ajay,

    RD and VPN ID do not have to be interchangeable
in all cases, but I think they could be.  I don't see what
the problem is in the case you point out (so maybe I do
not understand the question).

    As I understand it, an RD is effectively a sub-table
identifier used at each BGP speaker to distinguish the
IPv4 routing entries for each VPN.  There is no need
for a common RD to be used for the entire VPN, nor
is there necessarily any reason not to.  Route sub-tables
would need to be consistent (using the same definition
of consistent that applies to the Internet now) across all
routers in the same VPN - no matter how they are
identified.

--
Eric Gray

---

From: Eric Rosen <[email-masked]>
Date: Fri, 28 Sep 2001 11:36:38 -0400

Distributing routes is easy enough.  The  tricky part comes when you need to
decide whether  to use  a particular route.   It's especially tricky  if you
happen  to have  received two  routes to  the same  destination.   It's even
trickier if you want to make sure  that everyone's choice of a route is made
in such a way that no routing loops are formed. 

That's why when you specify a  routing procedure, you don't just specify the
messages used to distribute the  routes, you specify a decision procedure, a
set of attributes used to compare routes, etc., etc., etc. 

That in turn is why it makes  no sense to say "let's distribute routes using
LDP".   Route   distribution  doesn't   necessarily  require  BGP,   but  it
certainly requires a routing protocol, and LDP is not a routing protocol.

---

From: Eric Gray <[email-masked]>
Date: Fri, 28 Sep 2001 12:12:01 -0400

Eric,

    I agree that LDP is not a routing protocol.  I never said it was.  Check
the thread a little more closely.  Of course, you may not have been saying
that I did say this - even though your comments below were in reply TO
me.  :-)

    However, you do not have to use BGP - and that is what I did say.  In
fact, for some types of 'virtual private' services, you do not have to use a
routing protocol at all.

    Assuming you do use a routing protocol (for the task of ditributing routes
at least), there is no reason why <your favorite> label distribution protocol
could not be used to distribute labels for those routes.  Doing so with LDP,
just for instance, would require adding a new (set of) FEC(s) that include
some sort of VPN identifier (or route discriminator) along with the prefix.
IF I were going to define such a thing, I would define a new FEC object/TLV
that includes an 8 byte field for VPN-ID (or RD) and any of the currently
defined FECs as a sub-TLV (object).  In addition, it would be necessary to
add some verbiage around how the ingress selects an LSP for forwarding,
and - it seems to me - the big part of the task is over.

--
Eric Gray

---

From: Eric Rosen <[email-masked]>
Date: Fri, 28 Sep 2001 12:38:41 -0400

In  the  "hub  and spoke"  case  that  Ajay  mentioned,  the intent  is  the
following. 

Let H be the  hub, S1 and S2 the spokes.  Let A be  the address prefix for a
subnet that attaches to S2.  What we want is:

- S1 thinks the route to A is via H. 

- H thinks the route to A is via S2. 

Thus traffic from S1 to A goes via H and then on to S2. 

To make this work, S2 must distribute a route RD1:A, and H must distribute a 
route RD2:A.   Both these  routes have to  be able  to pass through  a route
reflector, since  RD1:A must make  it to  H, and RD2:A  must make it  to S1.
This  implies that  RD1  must be  different  than RD2;  otherwise the  route
reflector could not pass on both routes. 

Given that S1,  S2, and H are in the  same VPN, this is a  case in which you
couldn't just replace the RD with a VPN-id.  There might also be other cases
in which  you want to pass around  two different routes to  the same address
prefix, using  policy to decide which  to install where  (presumably in some
manner that ensures loop-freedom).

---

From: Eric Gray <[email-masked]>
Date: Fri, 28 Sep 2001 14:08:01 -0400

Eric,

    There are a few things to say in response to this:

        o    This seems to be an artifact of an off-beat (and probably not
            well supported) use of RRs,
        o    This IS a BGP specific issue and
        o    I said there is no reason not to embed a VPN ID (which is 7
            bytes long) in an RD (which is 8) - I did not say they are
            interchangeable (though - with the exception of trying to
            support some strange corner cases - they could be).

As I understand it, the 'real' configuration is something like this (watch
me pull a rabbit out of my hat):

                                   A
                                  /
        R1---.              .---R3
       /      \            /      \
      |        \          /        |
      |         \        /         |
      |          \      /          |
       \     S1   |    |   S2     /
        \         |    |         /
         \        |    |        /
          \       |____|       /
           \     /      \     /
            `--R2        R4--'
           /                  \
          |        (RR1)       |
           \                  /
            `-_      H     _-'
               `---____---'

Presumably,  S1, S2 and H are Autonomous Systems, right?  In this case,
how do S1 and H share a route reflector with S2?  Also, it is important to
note that S1, S2 and H do not think about routes, R1 through R4 do.  In
the above case, R3 and R4 might share an RR, as might R2 and R4 and R1 and
R2.  But it seems a bad idea to have them all sharing the same RR.

Assume for a minute, however, that this configuration of ASs is all under
the same administrative domain and someone decides to use a single RR
(Can they even do this?  How would advertisements from R3 get refelected
to R1, for instance, without going through R4 and R2?).  Logically, this
RR would have to look like this:

                                   A
                                  /
        R1---.              .---R3
       /      \            /      \
      |        \          /        |
      |         \        /         |
      |          \      /          |
       \     S1   |    |   S2     /
        \RR1-a    |    |    RR1-c/
         \        |    |        /
          \       |____|       /
           \     /      \     /
            `--R2        R4--'
           /                  \
          |        RR1-b       |
           \                  /
            `-_      H     _-'
               `---____---'

The route reflector itself needs to be logically partitioned so that the same
RR (physical device) can reflect a route for A from R3 to R4, from R4 to R2
and from R2 to R1.  Having the RR reflect the route advertised by R3 directly
to R1 sure seems seriously broken.  It would not work in normal BGP, so why
would anyone expect it to work in BGP-VPNs?  The RR simply has to know
what sets of routers it can share advertisements among for each AS, or it
should not be shared across multiple ASs.

Practically, however, I can see that trying to support many ASs without using
a cheat like this might mean having to either have very many RRs, or put a lot
of smarts into each RR.  Let me guess, we don't sell smart RRs, do we? :-)

None of this has anything to do with the response I made to Jay, however.  The
fact that MPLS/BGP VPNs defines an address format suited to solving this
BGP specific problem has nothing to do with why another label distribution
approach might not be useful in support of VPNs based on something other than
BGP.

Nor does this problem seem to prevent anyone from embedding a VPN ID in their
RD until they get to the point where they need more than 255 distinct RDs for
a single VPN.  By that time, they may have other problems anyway...

--
Eric Gray

---

From: Eric Rosen <[email-masked]>
Date: Fri, 28 Sep 2001 14:26:01 -0400

Gee,  all Ajay and  I did  was to  describe a  case where  one needs  to use
multiple RDs for  the routes of a  single VPN.  So in that  case, one cannot
simply use the VPN-id as the RD.  No broader claims are implied.

In your rabbit picture, what you call R2 and R4 are what I called S1 and S2,
I think;  I meant  for S1,  S2, and  H to be  three PE  routers on  the same
service provider network, hence in the same AS. 

For a description  of how to embed a VPN-id in  an RD, see draft-ietf-ppvpn-
bgpvpn-auto-00.txt.

---

From: Ajay Simha <[email-masked]>
Date: Fri, 28 Sep 2001 14:23:04 -0400 (Eastern Daylight Time)

> me pull a rabbit out of my hat):

I assume S1 to be Site1, S2 to be Site 2 and H to be Hub-site of the *same*
AS.

> RR would have to look like this:

I would like to take this discussion outside the realm of RRs since I think
with or without RRs the situation is the same as far as embedding vpnid in RD
is concerned.

You may be able to embed vpnid in the RD as long as for
hub-and-spoke (and may be other applications) we can have RDs which are
distinct from each other in spite of embedding the vpnid in them.  Although if
you do this I'm not sure what embedding the vpnid would do for you.

If we had a good way of encoding the vpnid into the RD and decoding it, then
it may be useful to be able to simply look at the RD and go - "oh this belongs to
this VPN".

Also hub-and-spoke is not so uncommon since people like to run enterprise
centric applications and firewalling at the hub site.

BTW great ascii rabbit :-)

-ajay

 > > -- >
Eric Gray

-- 
Ajay Simha
MPLS Deployment Engineer
IOS Technology Division
(919) 392-3141

 - Mahatma Gandhi