Subject: Re: LDP requires break-before-make

From: Eric Gray <[email-masked]>
Date: Fri, 01 Jun 2001 10:39:30 -0400

Tomar,

    An LSR may assign any semantics it wishes to the labels it
distributes to peers.  If it assigns the 'wrong' semantics (using
some definition of 'wrong'), however, it may be required to change
(withdraw and map again) this label to conform to a new semantic
if the nature of the LSP changes.  This can have extremely bad
effects on both the packet forwarding for the LSP associated with
this label and the status of the LSP with respect to all upstream
LSRs (potentially including the entire MPLS domain).

    There are several ways to deal with this, including having a way
to make-before-break on a specific label mapping.  It would be a
good idea to have a well understood approach.  At present, the only
(even partially) understood approach is to avoid assigning semantics
to specific labels that can lead to this situation.

    As to how to do this, don't ask.  :-)

--
Eric Gray

You wrote:

> Hi!
>    I cannot understand why an LSR (downstream) will need to withdraw  a
> label mapping for a particular FEC from its upstream peer and send a new
> mapping for the same FEC this time with a different label
> (withdraw-and-map message). It can as well use the old (incoming) label
> for whatever purpose it's planning to use the new label.
> The only reason can be setting up of multiple equal-cost paths, which the
> RFC says is not supported now.
> I would like to know if there are any other implications.
>
> -- tomar
>
> On Tue, 29 May 2001, Chris Kuszmaul wrote:
>
> >
> >  Before a label can be mapped to an FEC that has already been mapped, the LSR
> > must release the old label (prompted perhaps by a withdrawal message). Thus, LDP
> > calls for a break-before-make on LSP updates.  It would seem a straightforward
> > matter for the protocol to include a withdraw-and-map message that performs this
> > sequence atomically, and so preserves a make-before-break condition.
> >
> >   Is there some reason for not providing for this kind of functionality?
> >
> >  Thanks for any comments.
> >
> > CLK
> >
> > PS: The careful reader will realize that I have mentioned this issue before in
> > the thread [Re: Receive Label Receive !!], but have not seen any reply. This is
> > an attempt to focus the question and broaden the pool of possible respondents.
> >