The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

Manohar,

    Please see embedded comments below...

You wrote:

> I think one commercial MPLS stack vendor has support
> for one side of LSP setup using LDP(CR) and the other
> using RSVP. I am not sure about the extent of support.
> For instance Explicit and crankback semantics and how
> they can be translated between the two sides.

Whenever there are a number of elements cooperating to
communicate (in series, as it were), the limitations of
the things they might be able to communicate is likely to
be the intersection of their communication capabilities.

What you say above would be just as true if the same
protocol were in use but some of these features were
not supported at every node.

>
> However I can imagine, instead of horizontal participation
> of the two signaling protocols, a vertical participation
> where a tunnel might be setup using RSVP-TE and inside
> the tunnel number of LSPs to be setup using CR-LDP for
> instance.

This makes sense.  I believe you might find the opposite
could make sense in some scenarios as well.  It is even
conceivable that you could have alternating layers.

>
> Again probably it is best avoided using multiple signaling
> protocols over a single provider network. 2547 does
> mention use of LDP to setup PE-PE tunnles. I remember
> a discussion on removing explicit reference to one
> particular signaling protocol from 2547. If 2547 does require
> LDP then probably the underlying physical connectivity
> between PE routers can be setup using RSVP-TE and
> VPNs provisioned or PE-PE (per VPN specific) inner
> LSPs setup using LDP. Some one can comment whether
> this makes sense.

Certainly. :-)

For BGP-MPLS, it is necessary to have some protocol in
use to establish LSPs between non-adjacent BGP speakers
since - otherwise - the labels exchanged between such
speakers are not meaningful.  It also makes sense that the
protocol used should be in-tune with the IGP used to route
packets between these non-adjacent BGP speakers.  Hence,
LDP makes sense - although another protocol could be used.

I believe this is something like what the current state of affairs
with BGP-MPLS says.

>
> -Manohar
>
> ----- Original Message -----
> From: "David Charlap" <david.charlap@marconi.com>
> To: <mpls@UU.NET>
> Sent: Monday, February 19, 2001 9:31 AM
> Subject: Re: CR-LDP and RSVP implementation
>
> > djiang1@lucent.com wrote:
> > >
> > > I have a question regarding CR-LDP and RSVP implementation.
> > >
> > > I guess it is possible that both CR-LDP and RSVP implementations will
> > > be supported on one LSR.
> >
> > Definitely possible.  And quite probable in the future.
> >
> > > However, is there any chance that both the implementations will be
> > > called for one LSP setup?  Say, at the incoming interface, CR-LDP will
> > > take the PATH message and pass it to some other MPLS processes.  At
> > > the out going interface, RSVP will get some message from other MPLS
> > > processes and does something in the middle and sends out another PATH
> > > message to its neighbor node.
> >
> > I don't think so.
> >
> > The only way I can picture such a setup would require a transit router's
> > ability to terminate one LSP, then initiate setup of another, and
> > connect them internally.  Theoretically possible, but difficult to
> > automate and of questionable utility.
> >
> > I think you may find MPLS networks where RSVP-TE, LDP and CR-LDP are all
> > used for LSP setup at once.  And this may well result in multiple
> > redundant LSPs between edge nodes.  But each individual LSP will almost
> > certainly be set up through exactly one protocol.
> >
> > -- David
> >