The MPLS WG Archive

[Chris Kuszmaul <fyodor@pluris.com>]

Hi Eric

  I think you are right.  Consider LSRs A and B.

A sends to B the label mapping: <label1, FEC>

There is nothing I am aware of in the spec that prevents A from sending another
mapping, such as:
<label2, FEC>, prior to receiving a label release (of label1) from B.

 What I was saying was that B had to release label1 (transmit a label release to A)
before B could accept the mapping of label2. Your solution, of combining a label
withdrawal (of label1) with the label mapping of label2, in a PDU, seems to basically
make sense.

  The semantics of ordering is necessary, but not sufficient to prevent a break before
make. I think there needs to be a sense of atomicity as well: Both the label
withdrawal and the label mapping need to be done, or neither should be done. In
particular, the label release message transmitted by B MUST be contemporaneous with
the completion of the label mapping.  The LDP spec does not *preclude* just such a
behavior, and so a PDU containing a label withdrawal and a label mapping can be
treated as a label-mapping-overwrite, without violating the spec, and thus preventing
a break before make.

CLK


Eric Gray wrote:

> Chris,
>
>     I understand your concern.  A few years ago (early '98) I had
> proposed a semantic interpretation for LDP that  directly related
> to this.  The response was to explicitly prohibit the behavior
> which would have had this semantic.
>
>     I had suggested that (in DU mode) an LSR that advertised a
> new label for exactly the same FEC as it had previously advertised
> a different label meant for the upstream LSR to replace the previous
> label with the new one.  Over time, I came to undestand why this
> may have been a little too simplistic.  Also, it may be needed when
> DoD label advertisement is being used as well.
>
>     I think your basic idea of using a new message type will work.
> I had thought of that and talked with a couple of people on the LDP
> design team about it - and they were not too receptive to the idea
> as part of the base LDP specification (adds complexity not really
> required for basic functionality).  Also - at the time - I thought it
> possible to achieve a very similar result by simply including both
> the label withdraw and the new label mapping in the same PDU (an
> LDP PDU can contain multiple LDP messages).
>
>     Of course, this latter approach depends on a few things:
>
>         o    that you are not correct in your assertion that a downstream
>                 LSR is required to wait for a label release message prior
>                 to sending a new label mapping (*),
>
>         o    that an upstream LSR actually looks for a 'replacement'
>                 label mapping message in a PDU that contains a label
>                 withdraw message,
>
>         o    that this upstream LSR processes multiple messages in a
>                 single PDU in the order in which they appear in the PDU
>
>                 and
>
>         o    that the dowbstream LSR put them in the PDU in the order
>                 in which it expected them to be processed (+).
>
> *    I think that the requirement is that the downstream LSR MUST
>         not re-use the same label until it receives a label release for a
>         label it has withdrawn.  I do not think there is any statement in
>         the specification that prohibits sending a new label mapping
>         prior to receiving a label release for the previous mapping for
>         the same FEC.  Please let me know if there is text in the spec
>         to the contrary.
>
> +    Given that I am right in my interpretation of the current spec wrt
>         issuing a new label mapping after a label withdraw, the last two
>         bullets naturally fall out since the current restriction on sending
>         a new label mapping (with a different label) prior to withdrawing
>         a prior label mapping imposes an ordering resptriction on adding
>         messages to a PDU and processing them on receipt.  This ordering
>         is not hard to achieve.
>
>     Essentially, a downstream LSR can try this approach and hope that
> the upstream LSR was built to be robust and resilient (either using the
> approach above, or some other approach).
>
> --
> Eric Gray
>
> You 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.