Subject: RE: Use of LDP for VPNs

From: Mark Duffy <[email-masked]>
Date: Fri, 06 Apr 2001 16:20:05 -0400

Hi Bill,

Your comment raises another question which I have been wondering about.
RFC 3036 sect. 2.1 gives very specific rules for what *packets may be sent*
on a particular LSP.  But it doesn't say anything about what higher-level
*LSPs may be stacked* on the LSP. 

Presumably one stacks higher level LSPs whose next hop matches a FEC
element associated with the outer LSP.  If one applied the rules of section
2.1 to the stacking, it would (for example) require that an outer LSP with
a Host Address FEC be chosen in preference to any LSP with an Address
Prefix FEC.

Was it the intent of the authors that the same rules for assigning packets
to an LSP also be used for assigning higher level LSPs into the LSP?

If the same rules apply then I would agree with you; it appears that the
Host Address FEC LSP should not be used to stack any higher level LSPs,
except for other Host Address FEC LSPs with the same Host Address!  This
would be consistent with what I see in the mailing list archive (LDP: need
to eliminate useless FEC type, Aug 98) which seems to conclude that LSPs
bound to a Host Address FEC should only be used for control traffic
addressed to the LSR itself.

If the rules of sect. 2.1 do not apply, then I see no reason why this would
necessarily be disallowed.

All the same, I'm getting the distinct impression that the Host Address FEC
type is probably not widely used.

-Thanks, Mark

At 03:33 PM 4/6/01 -0400, Herbst, Bill wrote:
>Mark,
>
>It seems to me that in section 2.1 of RFC 3036 such use of a Host FEC
>element
>is explicitly prohibited -
>
>     -  A packet which does not match a particular Host Address FEC
>         element may not be sent on the corresponding LSP, even if the
>         Host Address FEC element identifies the packet's egress router.
>
>You could use a /32 Prefix FEC element of the BGP next hop for that VPN-IP
>address.
>
>Bill
>
>
>> -----Original Message-----
>> From: Mark Duffy [mailto:[email-masked]]
>> Sent: Friday, April 06, 2001 1:46 PM
>> To: [email-masked]
>> Subject: Use of LDP for VPNs
>> 
>> 
>> Hi,
>> 
>> BGP-MPLS VPNs require outer LSPs to provide MPLS connectivity 
>> between PE
>> routers.  Rfc2547bis calls for supporting the establishment 
>> of these LSPs
>> using LDP, and optionally by other means (e.g. by RSVP-TE).  
>> The rationale,
>> I believe, is that LDP can automatically create and maintain the
>> (potentially large) mesh of LSPs needed.  This also makes 
>> sense for other
>> VPN approaches, such as virtual routers, using MPLS as a 
>> tunneling mechanism.
>> 
>> My question:  When using LDP for setting up the outer LSPs, 
>> which type of
>> labels should the originating PE request, those associated 
>> with an Address
>> Prefix FEC element or those associated with a Host Address 
>> FEC element?
>> Both seem to have different drawbacks.
>> 
>> In the case of Host Address FEC type, it is required to have the
>> appropriate /32 route in every intervening LSR, in order for 
>> the LSPs to
>> get established.  How undesirable is it considered to be, to 
>> distribute
>> host routes for all the PE routers throughout the network?
>> 
>> In the case of Address Prefix FEC type, I suppose one would 
>> select an LSP
>> with an address prefix FEC element that is the longest match for the
>> address of the remote PE router.  But one cannot be certain 
>> that this LSP
>> reaches all the way to that remote PE, that there are not 
>> non-MPLS links or
>> nodes intervening!  I suppose one could try to ensure that by 
>> the design of
>> the network but that doesn't seem such a robust solution.
>> 
>> Also if using Address Prefix FEC type, it seems highly 
>> wasteful to "turn
>> on" LDP and request labels for every FEC in the forwarding 
>> table, if the
>> only LSPs needed are those to interconnect PE routers for VPN support.
>> Since it is essentially a local decision by an LSR what 
>> labels to request,
>> would there be any problem for PE routers to request labels 
>> for only those
>> FECs needed to reach the other PE routers they need to reach?
>> 
>> Thanks, Mark
>> 
>

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 08 Apr 2001 22:51:06 -0400

> a Host Address FEC be chosen in preference to any LSP with an Address

For most usage of MPLS, the notion of FEC is a broken one.  In
RSVP/TE, there is no FEC signalled which is a good thing.  For a
hierarchical tunnel, you can carry any traffic that needs to pass that
way.  A specific case would be a BGP VPN tunnel directly inside a TE
tunnel (which elsewhere could go directly inside another TE tunnel).

If an outer tunnel will only accept inner tunnels with a specific
L3PID, then we set that L3PID on the outer tunnel.  If it is allowed
to carry any L3PID, then the MPLS L3PID is used.  If the MPLS L3PID is
used, this also indicates that there must be another label underneath
since there is no way to determine how to interpret the payload.

Curtis

---

From: Eric Gray <[email-masked]>
Date: Mon, 09 Apr 2001 11:10:21 -0400

Mark,

    The rule that applies to stacking labels is the same, in
one very important aspect, as the rules for using labels in
any case: the label must be issued by the entity that is
responsible for interpreting them (with one slightly broken
exception).

    Because of this, the limitations you describe exist only
in the simplest cases and are not especially relevant since
- even in those cases - the labels must (almost always)
be issued by the (next hop) receiving entity.

    Of course, the slighty broken case is the case in which
a sender decides to use an explicit NULL label.  This one
case has the potential to complicate things and should have
been explicitly forbidden.

--
Eric Gray

---

From: Mark Duffy <[email-masked]>
Date: Mon, 09 Apr 2001 18:51:17 -0400

Hi Curtis,

>tunnel (which elsewhere could go directly inside another TE tunnel).

I don't disagree with your statement, however I don't believe it addresses
my question.  The question related to the use of LDP for topology driven
hop by hop LSP set up and the FEC elements that are assigned to LSPs when
they are set up in this manner.  RFC 3036 sect. 2.1 gives rules for what
packets may be sent on these LSPs, depending what FEC elements are
associated with the LSPs.  These rules have to do with making the whole use
of topology (routing) -driven LSPs "work" as a replacement for traditional
hop-by-hop IP forwarding.

So the question is, when stacking LSPs set up by other means into
topology-driven-LDP-created-ones, what is one to make of those rules?  May
they be freely ignored?

(I supposed you will tell me that the whole use of LDP for topology driven
set up should be freely ignored :-)   and I would not necessarily disagree
with you.)

---

From: Eric Rosen <[email-masked]>
Date: Tue, 10 Apr 2001 08:25:49 -0400

Mark> RFC 3036 sect.  2.1 gives rules for what packets may  be sent on these
Mark> LSPs, depending what FEC elements are associated with the LSPs.

If you  don't bother to  implement the Host  Address FEC, you don't  have to
worry about the  precise interpretation of these rules.   There is no reason
why anybody should implement the Host Address FEC.

Mark> (I supposed  you [Curtis] will tell me  that the whole use  of LDP for
Mark> topology driven  set up should be  freely ignored :-) and  I would not
Mark> necessarily disagree with you.)

Just don't  expect to  interoperate with others,  unless you are  using MPLS
only for traffic engineering. 

Mark> If MPLS  is not ubiquitous between  the LSRs that are  adjacent at the
Mark> higher level, then the higher level LSP is broken. 

Of all  the ways in which  connectivity might be broken,  forgetting to turn
MPLS on is pretty low on the list.

---

From: David Charlap <[email-masked]>
Date: Tue, 10 Apr 2001 12:40:48 -0400

Curtis Villamizar wrote:
> RSVP/TE, there is no FEC signalled which is a good thing.

Or you can think of RSVP/TE as supporting a restricted subset of LDP's
definition of a FEC.  Specifically, only accepting a single /32 prefix. 
Which is used as the tunnel endpoint address in the SESSION object.

Just like an LDP-signaled /32 FEC, an RSVP-TE-signaled LSP may carry all
traffic that passes through the endpoint address.

-- David

---

From: Mark Duffy <[email-masked]>
Date: Tue, 10 Apr 2001 21:19:27 -0400

>worry about the  precise interpretation of these rules.   There is no reason

Good point, agreed.

>only for traffic engineering. 

Interoperability is certainly an important goal for me.  2547bis specifies
LDP as a common point of interoperability, however I have heard some
dissenting voices on this list speaking in favor of using TE tunnels.
Outside of 2547, I'm also interested in the use of hierarchical LSPs to
interconnect virtual routers, where pretty much the same considerations
apply.  For all these reasons therefore I'm trying to probe the sentiment
of this list.

>MPLS on is pretty low on the list.

Yet there could be other reasons, besides not turning MPLS on, that the
outer (set up by LDP) LSPs might not provide the needed MPLS connectivity
from PE-PE.  Although the same could also be said for explicitly
provisioned TE tunnels used in this role, so I suppose this is not really a
persuasive argument against the use of LDP in this case.

But then again if using explicitly provisioned TE tunnels, it would be more
obvious if the connectivity were not there, and we would therefore be less
likely to be sending VPN packets off into the void when there is not
connectivity to the remote PE.

Thanks for your comments,
-Mark

---

From: Eric Rosen <[email-masked]>
Date: Wed, 11 Apr 2001 10:40:27 -0400

Mark> Interoperability  is  certainly an  important  goal  for me.   2547bis
Mark> specifies LDP  as a common  point of interoperability, however  I have
Mark> heard some dissenting  voices on this list speaking  in favor of using
Mark> TE tunnels. 

Well, what you need in order to  interoperate is a matter of what the common
implementations  do, which  is a  matter  of fact  rather than  a matter  of
opinion. 

The use of multipoint-to-point  non-explicitly-signaled LSPs is so much more
efficient than the use of TE tunnels that no one would really use TE tunnels
for this unless  they needed the explicit path setup in  order to do traffic
engineering.  (Or unless they had neglected to implement LDP ;-))

There have been some folks claiming that the specs should be altered so that
non-interoperable implementations could individually claim compliance to the
specs.  One can see the advantage of this from a vendor perspective, but I'm
not sure how this advantage could be explained to the Service Providers ;-)

Mark> Yet there  could be other reasons,  besides not turning  MPLS on, that
Mark> the  outer (set  up by  LDP) LSPs  might not  provide the  needed MPLS
Mark> connectivity from  PE-PE.  Although  the same could  also be  said for
Mark> explicitly provisioned TE tunnels used in this role, so I suppose this
Mark> is not  really a persuasive  argument against the  use of LDP  in this
Mark> case. 

Indeed.  If  you're thinking  of the  type of failure  in which  the control
plane says  everything is okay,  but the data  plane is broken, there  is no
reason  to  think that  LDP-controlled  topology-driven  LSPs  are any  more
vulnerable than TE tunnels.

Mark> But then again if using explicitly provisioned TE tunnels, it would be
Mark> more  obvious  if  the  connectivity  were not  there,  and  we  would
Mark> therefore be less  likely to be sending VPN packets  off into the void
Mark> when there is not connectivity to the remote PE.

I don't see why  this would be the case.  If you're  worried about this sort
of thing, you need some sort of edge-to-edge keepalive, the control protocol
that is used to set up the LSPs is not really germane.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 11 Apr 2001 12:32:30 -0400

> apply.  For all these reasons therefore I'm trying to probe the sentiment

Let me be clear about what I said.  Interoperability is goodness.  We
do LDP for RFC2547 and it works with both Cisco and Juniper
(interoperability testing has occurred in out lab, UNH, and GMU).  We
also allow the LDP tunnel to ride inside a RSVP/TE tunnel.  This
offers benefits (which I won't enumerate again).  If this feature is
used, we still interoperate with others running LDP and others running
RSVP/TE in the same network, although afaik we have not checked an
Avici router on one end of the TE tunnel and another router on the
other end (but we should get there).

If the TE tunnels go all the way to the edge and if this is done in a
way that scales well, then the need for LDP disappears.  My
understanding of the real reason why we are using LDP for VPN is that
it had more to do with the scalability of a particular RSVP/TE
implementation rather than an issue of protocol scalability (though
authors would never admit this).  If RSVP/TE does prove to be very
scalable, particularly with multi-area support and hierarchical
tunnels, then the need for LDP in some networks (the "in some
networks" is an important qualifier) may go away.  As long as there
are routers in a network which have a scaling problem with RSVP/TE are
in a network (older routers tend to migrate toward the edge) there
will be a need to support LDP (possibly just near the edge).

Curtis

---

From: Eric Rosen <[email-masked]>
Date: Wed, 11 Apr 2001 13:02:02 -0400

Curtis> My understanding of the real reason  why we are using LDP for VPN is
Curtis> that it had more to do  with the scalability of a particular RSVP/TE
Curtis> implementation 

If you are speculating about the reason Cisco uses LDP in support of RFC2547
VPNs, then I  can state authoritatively that this  has nothing whatsoever to
do with any characteristic of any RSVP/TE implementation.

---

From: "HANSEN CHAN" <[email-masked]>
Date: Wed, 11 Apr 2001 13:49:31 -0400

Eric,

Then mind telling us what are the reasons? I have been hearing LDP is used to
achieve maximum degree of interoperability with other vendors. However, I find
it difficult to accept as there're probably much more vendors supporting RSVP-TE
than LDP.

Cheers,
Hansen

---

From: Bora Akyol <[email-masked]>
Date: Wed, 11 Apr 2001 11:05:14 -0700 (PDT)

For MPLS based VPNs, LDP scales better than RSVP-TE and requires less
configuration as the network evolves.

What happens is that egress routers advertise /32 FECs to themselves in
Downstream-Unsolicited mode with liberal label retention. iBGP with
"advertise-self" is used to set the NH attribute to the iBGP peer instead
of the eBGP peer. This allows two things:

1) Only transit traffic gets sucked into the tunnels. This is what VPNs
are about.

2) Core routers in the network know nothing about the BGP peering and they
don't run BGP.

As an added benefit, with liberal retention, LDP is able to heal much
faster when routers in the middle of the network become unreachable.

Makes sense?

Bora
Who thinks that someone should write a BCP on MPLS based VPN usage.

---

From: Mark Duffy <[email-masked]>
Date: Wed, 11 Apr 2001 14:38:36 -0400

Hi Eric,

>engineering.  (Or unless they had neglected to implement LDP ;-))

Aside from standards and implementations of BGP-MPLS VPNs, I am interested
in the separate but technically similar issue of how 2-level LSPs should be
established for Virtual Router VPNs.  So I would like to understand a
little more about your point above.  

Do you consider the use of LDP more efficient because of the
multipoint-to-point nature, so that fewer LSPs might be required?  Or
because you believe use of LDP requires less provisioning?  (I would think
point-to-point TE tunnels could be *automatically* set up between
participating PEs, if using normal shortest path routing.)  Or for some
other reason?  Depending on what labels are being requested (or distributed
unsolicited) LDP might cause a great deal more signaling, while it
distributes labels for many FECs that might well be unnecessary to support
the VPN application.

Thanks, Mark

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 11 Apr 2001 15:07:22 -0400

> do with any characteristic of any RSVP/TE implementation.  

Rather than vendor bashing, I've taken this offline.

Any historical reason for using LDP is not important.  RSVP/TE has
advantages and if scaling is not an issue, there are some that would
prefer to have the TE advantages and if TE extends to the edges not
have an extra protocol and label with no clear purpose.

Curtis

---

From: "HANSEN CHAN" <[email-masked]>
Date: Wed, 11 Apr 2001 15:03:52 -0400

Bora,

> configuration as the network evolves.

I must have missed something here. Why is LDP requires less configuration and scale
better?

The BGP explanation below confuses me more. The way I understand is that BGP is used
to setup the inner label. It has nothing to do with the outer label negotiation by LDP
between PEs.

Cheers,
Hansen

---

From: David Charlap <[email-masked]>
Date: Wed, 11 Apr 2001 17:21:33 -0400

HANSEN CHAN wrote:
> 
> I must have missed something here. Why is LDP requires less
> configuration and scale better?

LDP doesn't need to be told what the tunnel endpoints are.  It can
simply look at the local routing table.

In Bora's scenario, every router treats its own local addresses as /32
FECs and sends out unsolicited label mappings for these.  They propagate
to the rest of the MPLS cloud.  Now, every router has a label for every
address of every MPLS router.  A full-mesh of LSPs has set itself up
with no manual intervention.

If the IGP's border matches the MPLS cloud's border, the edge routers
will take unlabeled traffic, lookup the BGP remote next-hop, (which will
be the router at the other side of the MPLS cloud), and label the packet
with whatever label corresponds to that next-hop.

The real nice thing about this is that this label distribution can
happen as the IGP is converging.  As soon as a router knows how to get
to each /32 FEC, it can program its forwarder with the label it
received.

This can also be done with TE tunnels, but it's not as clean.  With TE
tunnels, the endpoints must be identified by the ingress nodes.  This
information can be gotten from BGP (the remote next-hops), but the path
to those endpoints can't be determined until the network fully
converges.  In other words, it will take longer for everything to come
up - labels won't be distirbuted until the label requests can get from
the ingress nodes to the egress nodes, and that won't happen until the
IGP converges.

> The BGP explanation below confuses me more. The way I understand is
> that BGP is used to setup the inner label. It has nothing to do with
> the outer label negotiation by LDP between PEs.

With Bora's model, an ingress router uses BGP information to determine
what LSP to put traffic onto.

Matching a destination address against an FEC is useless, because each
FEC is the /32 address of an interface in the MPLS cloud.  Traffic not
destined for the routers will never match any of these.  Instead, BGP is
used to determine the egress router, and the FEC corresponding to that
router is used to determine the LSP.

-- David

---

From: "HANSEN CHAN" <[email-masked]>
Date: Thu, 12 Apr 2001 08:07:25 -0400

Dave,

> with no manual intervention.

Your explanation is interesting. In other word, the full-mesh of LSP is
topology-driven. I thought the idea of topology-driven is abandonned.

Is topology-driven the actual way used to establish those PE-to-PE LSPs in
real implementation or real network today?

Cheers,
Hansen