Subject: RE: Use of LDP for VPNs

From: "Herbst, Bill" <[email-masked]>
Date: Fri, 6 Apr 2001 15:33:15 -0400

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: [email-masked]
Date: Tue, 10 Apr 2001 08:06:49 +0100

I'd like to see the discussion, since I hold similar views to Mark that
there are some disadvantages with vanilla LDP (as compared to ER LSPs) as
the server LSPs for VPNs....so if you go off list then please copy me.

thanks, neil

> From: Eric Gray [mailto:[email-masked]]
> Sent: 10 April 2001 00:37
> To: Mark Duffy
> Cc: [email-masked]
> Subject: Re: Use of LDP for VPNs
> 
> 
> Mark,
> 
>     Why don't we handle this off-line?
> 
> --
> Eric Gray
> 
> You wrote:
> 
> > Hi Eric,
> > A few more questions below, thanks.
> > -Mark
> >
> > At 11:23 AM 4/9/01 -0400, Eric Gray wrote:
> > >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.
> >
> > 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.
> >
> > >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
> >
> > 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.
> >
> > >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.
> >
> > 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.
> >
> > >
> > >--
> > >Eric Gray
> > >
> > >You wrote:
> > >
> > >> 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: [email-masked]
Date: Wed, 11 Apr 2001 10:56:19 +0100

Mark Duffy [mailto:[email-masked]] wrote 11 April 2001 02:19
<snipped>
> >ER=>Of all  the ways in which  connectivity might be broken,  
> forgetting to turn
> >MPLS on is pretty low on the list.
> 
> MD=>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.
NH=> In our MPLS OAM draft we defined the CV (Connectivity Verification) OAM
packet.  This is like a 1s keepalive that goes from LSP source to LSP sink
and passes all peer-level LSRs and all server-layer LSPs transparently.  It
goes in the data-plane and does not rely on the control-plane.  Since the CV
pkt contains a unique source identifier it will detect all forms of
connectivity failure, ie besides below/within MPLS fabric breaks, it will
also detect misrouted/leaking traffic (across CV LSP population).  So this
would provide a tool to verify that your connectivity was indeed OK.  We
also provided algorithms for determining availability of both near-end and
far-end directions....the latter for the case of wanting to measure the
availability of both directions (assuming bi-directional LSPs) from a single
end (useful in inter-domain/international case).  Simple availability
measurements are possible with this tool since (i) the CV rate is
deterministic and consistent and (ii) the availability entry/exit criteria
is based on a harmonised set of underpinning defect entry/exit criteria.

---

From: "Metz, Eduard" <[email-masked]>
Date: Wed, 11 Apr 2001 12:32:54 +0200

This assumes you know where the LSP is supposed to end, where do you get
this knowledge?

cheers,
	Eduard

> From: [email-masked] [mailto:[email-masked]]
> Sent: 11 April 2001 11:56
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Use of LDP for VPNs 
> 
>

---

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

>is based on a harmonised set of underpinning defect entry/exit criteria.

MD=> Neil, My concern is that with topology-driven LSPs set up by LDP, the
LSP (i.e. MPLS connectivity) may or may not extend all the way from the
sender to the device that distributed the next higher layer label.  The LSP
corresponds to a FEC, not to a particular egress point.  This is just
normal operation of LDP.  Although I'm not familiar with your OAM draft, I
wouldn't expect it to detect this type of condition which after all is not
an "error" from the point of view of LDP and the outer layer LSP.
(However, it is a serious problem for any inner (client) LSPs.)

-Mark

---

From: [email-masked]
Date: Wed, 11 Apr 2001 16:03:56 +0100

Mark Duffy [mailto:[email-masked]] commented on 11 April 2001 14:56
> To: [email-masked]; [email-masked]; [email-masked]
NH=> (And also as response to Eduard Metz who asked 'how does one know where
the LSP sink is?').  Sorry if I was not clear on this....in our work we are
*not* considering any form of LSP other than ER pt-pt LSPs (eg RSVP-TE or
CR-LDP set-up LSPs....though in principle I guess it could (should?) apply
to BGP4 set-up LSPs).  So, by definition, the signalling knows where the
sink point of the LSP is supposed to be when setting the LSP up.  There are
3 ways that the sink point could be told the value of the TTSI (Trail
Termination Source Identifier = router IP address + tunnel ID) it should be
expected to see;
-	by manual config
-	by 'self-learning' of what it sees in the user-plane directly after
set-up as the 1st CV flow it sees (though this has some obvious slight risk
with it)
-	by being told of this during LSP set-up by the signalling protocol.
The latter one would be the ideal way IMO.

One can have a CV on any pt-pt LSP.  And when LSPs are nested, and
especially if the higher LSP straddles several lower LSPs (eg a transit LSP
service over several domains say), then this might be deemed as quite
important.  This way each of the domains could verify/measure their own
connectivity/availability, and so could the larger higher level LSP span.
Further, under failure the FDI pkts (which would be originally sourced at
the lowest LSP level affected) would (i) stop all higher level alarms and
(ii) allow higher level LSPs affected to know where the failure was from (at
least to domain....there is no intention of providing any detailed nodal
location information).

---

From: Nhat Thanh Hoang <[email-masked]>
Date: Thu, 12 Apr 2001 15:05:57 +0200

Hej, Hansen

I'm quite sure that most of the BGP/MPLS VPNs that are deployed in
operators' networks todays, have implemeted topology-driven PE-to-PE LSPs,
at least in Europe. 

/Nhat Thanh

Telia Reserach AB

-----Original Message-----
From: HANSEN CHAN [mailto:[email-masked]]
Sent: den 12 april 2001 14:07
To: [email-masked]
Subject: Re: Use of LDP for VPNs

Dave,

> 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.

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

---

From: "Metz, Eduard" <[email-masked]>
Date: Thu, 12 Apr 2001 15:10:02 +0200

Yes, in most cases there is no need for contraint routed paths. 

In these cases I do not see the point of (potentially manually) creating LSP
through RSVP/TE or CR-LDP between PEs, when LDP does this automatically.
Contraint routed LSPs only add to operational complexity here (maintaining
LSPs, adding PEs), with no further added value ...

cheers,
	Eduard

> Sent: 12 April 2001 14:07
> To: [email-masked]