The MPLS WG Archive

[Chris Kuszmaul <fyodor@pluris.com>]

 Looks right to me.

CLK

"Patricia A. Holden" wrote:

> So what you are saying is that A sends a label-withdraw(of label1) followed by a
> label-mapping(of label2) message to B and B sends back a label-release(of label1) to A
> after completing the label-mapping message(of label2).  Is my understanding correct?
>
> Thanks,
> Pat
>
> Chris Kuszmaul wrote:
>
> > 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.