The MPLS WG Archive

[Chris Kuszmaul <fyodor@pluris.com>]

Andrew:

 Please elaborate on the scenario you are thinking of --- is it like the
following?

B
|
A-C
|
D

  C and D each advertise mappings to A as <labelC, FEC> and <labelD, FEC>. Since
A is non-label-merge-capable, it advertises <labelA1, FEC> and <labelA2, FEC> to
B, and sets up label switching as

labelC -> labelA1(forward to B)
labelD-> labelA2 (forward to B)

 Well, this is how it might be if the spec did not say that the second mapping
received would be ignored and released.

 CLK


Andrew Bartholomew wrote:

> Chris,
>
> If you consider the case that B is non-label-merge capable then A will
> sometimes need to bind new labels to the FEC without withdrawing the
> previous one.  Such cases could make the update process much more
> complicated (consider updating one of the labels bound to a FEC but not the
> others).
>
> It seems to me as though there is a requirement for a transaction concept
> similar to MEGACO H.248, where a single transaction contains a number of
> separate actions, each comprising a set of commands that are executed
> sequentially.  Actions may be performed in any order but if a command within
> an action fails, the action is aborted and the next action begun.
>
> regards,
> Andrew
>
> --
> Andrew Bartholomew
>
> Layer 8 Consultancy            Observa et sapiens cresces
> Services Limited
>
> Tel: +44 1202 558409
> Fax: +44 1202 556748
> Email: Andrewb@layer8.co.uk
>
> > -----Original Message-----
> > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Chris
> > Kuszmaul
> > Sent: 01 June 2001 17:59
> > To: Eric Gray
> > Cc: MPLS Mailing List
> > Subject: Re: LDP requires break-before-make
> >
> >
> > 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.
> >
> >
> >