Subject: Use of LDP for VPNs

From: Mark Duffy <[email-masked]>
Date: Fri, 06 Apr 2001 13:46:27 -0400

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: Robert Raszuk <[email-masked]>
Date: Fri, 06 Apr 2001 11:03:21 -0700

Hi Mark,

> Prefix FEC element or those associated with a Host Address FEC element?

Host addresses are recommended. You have already answered why by
yourself ;), by saying 

...
> But one cannot be certain that this LSP
> reaches all the way to that remote PE,
...

Btw the below ...

> that there are not non-MPLS links or
> nodes intervening!

is a problem with both types so it is highly recommended that all of
your links in the network which a PE-PE packet may take do run MPLS.

R.

> Mark Duffy wrote:

---

From: Eric Rosen <[email-masked]>
Date: Fri, 06 Apr 2001 14:49:37 -0400

If you are  concerned about RFC2547 interoperability with  other vendors, my
suggestion would be to use the Address  Prefix FEC to get labels for the /32
addresses that correspond to the BGP  next hop values for the VPN-IP routes.
(This does imply having each PE insert a /32 for itself into the IGP.)

Another   suggestion  would   be   to  use   downstream  unsolicited   label
distribution,  which means the  issue is  not so  much requesting  labels as
deciding  for  which  of the  IGP  routes  you  need to  distribute  labels.
Distributing  labels  for all  of  the IGP  routes  seems  like a  perfectly
reasonable strategy, though distributing labels  only for the /32s of the PE
routers is fine  too.  It's probably a  good idea to make sure  that all the
routers in the network have the same policy.

---

From: Karthik Radakrishnan <[email-masked]>
Date: Fri, 06 Apr 2001 15:39:19 -0400

Wouldn't a prefix FEC element with a mask length of 32 work in this case.

-Karthik

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 06 Apr 2001 12:58:19 -0700

Yes sure. The only reason I called it host FEC was that for me host FEC
and prefix FEC of /32 are the same. (Yes I know for some reasons the rfc
does not define it that way). 

Maybe some hardware could distinguish those two cases (host FEC and
prefix FEC of /32 and make some use of this) but I don't know of any.

R.

> Karthik Radakrishnan wrote:
>

---

From: Mark Duffy <[email-masked]>
Date: Sat, 07 Apr 2001 12:34:25 -0400

Thank you for the responses several of you have sent on this question.
After reading your comments, and rereading the various RFCs and I-D's, I
have arrived at a more fundamental issue.

I had been under the mistaken impression that an LSP set up using LDP and
bound to a Host Address type FEC would fail to be established if it did not
reach all the way to the specified host (LSR).  I now understand that these
behave just like LSPs bound to an Address Prefix type FEC, which is to say
that the ingress LSR does not have knowledge of how far the LSP extends.

This type of behavior seems problematic to me when using LSPs set up by LDP
as tunnels in which to stack higher level LSPs.  Since the labels of the
higher level LSPs are meaningless except at the LSRs that distributed them,
if the outer LSPs happen not to reach to the next hop of the inner LSPs
there will not be connectivity of the inner LSP.

One could try to prevent this problem would from arising by making sure
that MPLS is deployed throughout the entire network connecting the end
points of the higher level LSPs (e.g. PE devices providing VPN services)
but that does not strike me as providing a robust and high confidence
solution.  Using TE tunnels set up by RSVP-TE or CR-LDP would avoid the
problem, but that seems to present a different problem of ensuring that all
the required PE-PE tunnels are always present (as previously discussed on
this list).

-Mark

---

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

Mark,

    The choice of using explicitly routed LSP tunnels (the term
"TE tunnels" could be misleading in this case) for LSP setup
for LSPs intended to carry other LSPs may not be as heinous
as you seem to believe.  First of all, it does address the problem.
Second, it is only needed when LSR peers (with respect to some
context in which tunneling might be needed) are not adjacent.
Thirdly, even when it is needed, it is only needed for the length
of a tunnel to that peer.  Because of peering concerns in general
(with the _dreaded_ "overlay model") this will generally not be
very many hops.  Finally, tunneling LSPs in other LSPs can only
be used when MPLS is ubiquitous at least on links between LSR
peers - in any other case, another tunneling mechanism may be
used, or packets must be sent using IP routing.

--
Eric Gray

---

From: Mark Duffy <[email-masked]>
Date: Mon, 09 Apr 2001 19:20:59 -0400

Hi Eric,
A few more questions below, thanks.
-Mark

>as you seem to believe.  First of all, it does address the problem.

Well, I actually didn't call it heinous!  I am pursuing this line of
questioning because rfc 2547bis calls for the capability of using
topology-driven LDP distribution of labels to set up the "outer" LSPs used
to tunnel the VPN-specific LSPs.  There were some emails exchanged on this
list in January in support of that; more recently I've seen some messages
opposed to the use of LDP for that.

>very many hops.  Finally, tunneling LSPs in other LSPs can only

Would you explain why the overlay model would have anything to do with the
number of hops?  I think we're talking about a VPN scenario where
VPN-specific LSPs are tunneled in other LSPs across some shared backbone; I
don't see why the diameter of that backbone should have a scalability
impact on this.  Specifically, the number of adjacencies in the overlay
network (i.e. the VPN) is constant regardless of the number of backbone LSR
hops.

>used, or packets must be sent using IP routing.

Ahh, and that was exactly what drove my original question.  If MPLS is not
ubiquitous between the LSRs that are adjacent at the higher level, then the
higher level LSP is broken.  And my question/complaint is (since 2547bis
calls for the capability to use LDP to distribute the outer label) that the
use of LDP does not provide knowledge of whether there is MPLS connectivity
between the LSRs that are to be adjacent at the higher level.

---

From: Eric Gray <[email-masked]>
Date: Mon, 09 Apr 2001 19:37:20 -0400

Mark,

    Why don't we handle this off-line?

--
Eric Gray