The MPLS WG Archive

[Giles Heron <giles@packetexchange.net>]

On Thu, 2002-07-25 at 08:15, Bisewski, Radoslaw wrote:
> But CR-LDP is an extension to the LDP protocol. While RSVP-TE has nothing in
> common with LDP. After "eliminating" CR-LDP you will still have two MPLS
> signalling protocols MPLS LDP and RSVP-TE.

Agreed - however this doesn't negate my point that LDP != CR-LDP (i.e.
moving CR-LDP to informational or historic would in no way impact LDP).

In a perfect world we would probably only have LDP (for merging LSPs and
for L2 FEC advertisement) and CR-LDP (for TE).

However it is rather too late to shut this particular stable door. 
Neither LDP or RSVP-TE is about to disappear - however annoying it might
be that certain vendors appeared to foist RSVP-TE onto us (I wasn't
there at the time so I can't comment on this).  Having CR-LDP as well
(even if it is based on LDP) seems to me to increase complexity, rather
than reduce it...

Giles

> 
> Radek
> 
> > -----Original Message-----
> > From: Giles Heron [mailto:giles@packetexchange.net]
> > Sent: Wednesday, July 24, 2002 9:49 PM
> > To: Jothilingam, Vasudevan ""(Vasu)
> > Cc: IETF MPLS List
> > Subject: RE: initiating a discussion on mpls singaling protocols
> > 
> > 
> > On Wed, 2002-07-24 at 18:22, Jothilingam, Vasudevan (Vasu) wrote:
> > [snip]
> > > I would like to say, yeah RSVP-TE is the way adn CR-LDP could be
> > > informational RFC.
> > > Being said that, there is lots of work going of L2 
> > Transportation over MPLS,
> > > using LDP.
> > 
> > LDP != CR-LSP
> > 
> > Giles
> > 
> > > Well, even though I am not for that approach of using 
> > RSVP-TE and LDP ( two
> > > big protocols ??)
> > > for L2 transport, we need to see where that goes..
> > > 
> > > Thanks
> > > Vasu
> > > 
> > > 
> > > 
> > > 
> > > Vasu Jothilingam
> > > Lucent Technologies
> > > 1 Robbins Rd
> > > Westford, MA-01886
> > > PH:   (978)-952-7533
> > > FAX: (978)-952-7977
> > > 
> > > 
> > > -----Original Message-----
> > > From: Ong, Lyndon [mailto:LyOng@ciena.com]
> > > Sent: Wednesday, July 24, 2002 2:00 PM
> > > To: 'David Charlap'; IETF MPLS List
> > > Subject: RE: initiating a discussion on mpls singaling protocols
> > > 
> > > 
> > > Hi David,
> > > 
> > > Actually, SCTP is an alternative that supports message
> > > passing and boundary preservation, plus other features
> > > for reliability and detection of signaling path failure.
> > > It was intended to relieve the application from having to
> > > do continual verification of the signaling path and support
> > > of a backup path.  However, it was being defined at about
> > > the same time as MPLS, so it was never considered as an
> > > alternative for transport of MPLS signaling.  
> > > 
> > > A reliable UDP was one of the alternatives considered when doing
> > > SCTP, but it still leaves the application to do testing
> > > of the signaling path and message rerouting if that fails, 
> > > and does not have congestion control built in.
> > > 
> > > Cheers,
> > > 
> > > Lyndon
> > > 
> > > -----Original Message-----
> > > From: David Charlap [mailto:david.charlap@marconi.com]
> > > Sent: Wednesday, July 24, 2002 7:45 AM
> > > To: IETF MPLS List
> > > Subject: Re: initiating a discussion on mpls singaling protocols
> > > 
> > > As for the rest, TCP is not an appropriate transport for signaling 
> > > protocols in the first place.  RSVP-TE, LDP and CR-LDP all use a 
> > > message-passing mechanism.  They are not designed around 
> > streaming data. 
> > >   Use of a streaming protocol means that the protocol has 
> > to deal with 
> > > the issue of detecting message boundaries and half-received 
> > messages.
> > > 
> > > Unfortunately, there is no standard for anything resembling 
> > reliable UDP 
> > > - that would be ideal.
> > > 
> > -- 
> > =================================================================
> > Giles Heron    Principal Network Architect    PacketExchange Ltd.
> > ph: +44 7880 506185              "if you build it they will yawn"
> > =================================================================
> > 
> 
-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================