Subject: RE: LDP requires break-before-make

From: "AMK Networking Technologies Inc." <[email-masked]>
Date: Fri, 1 Jun 2001 00:24:59 -0400

Hi Chris,

I don't see the requirement for this functionality as LDP offers the
following:

1) Two distribution methods ( DoD and DU)
2) Two control methods (ordered and Independent)
3) Two retention methods (liberal and conservative)

These can be combined to achieve varying results *some not so desirable*,
like break-and-make and make-and-no-break.
If the scenario you describe is like this....a label mapping is received by
a LSR for a FEC which has bound a label, I am assuming that this mapping is
received by that LSR on a different interface. That would also mean that the
network is configured for DU at the very least. The LSR would not
necessarily inform the upstream LSR but rather use the new label and release
the existing label...in that case it is not a break-make situation.

If the scenario you describe is like this....The MPLS domain is configured
for Liberal Label Retention and a new next hop is discovered by a particular
LSR for a particular FEC (the next hop is a different interface...logical or
physical) then the existing label is released and the label stored in the
LIB for that next hop interface is used...again this is not a Break-Make.

If a connection or downstream router fails then that is again a different
set of procedures depending on the configuration of the LSRs in the MPLS
domain. In that case DoD with conservative retention mode does cause a
break-make...life is full of trade offs.

Please feel free to comment...If I misunderstood you, I apologize, please
restate your question.

regards,

Micheal
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Chris
Kuszmaul
Sent: Tuesday, May 29, 2001 6:45 PM
To: David Charlap; [email-masked]
Subject: LDP requires break-before-make

 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.

---

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

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
> 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.

---

From: Chris Kuszmaul <[email-masked]>
Date: Fri, 01 Jun 2001 09:59:24 -0700

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

---

From: Chris Kuszmaul <[email-masked]>
Date: Mon, 04 Jun 2001 11:05:18 -0700

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
> >

---

From: "Patricia A. Holden" <[email-masked]>
Date: Mon, 04 Jun 2001 13:56:53 -0400

Thanks,
Pat

---

From: "Andrew Bartholomew" <[email-masked]>
Date: Wed, 6 Jun 2001 14:04:53 +0100

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: [email-masked]

> Sent: 01 June 2001 17:59
> To: Eric Gray
> Cc: MPLS Mailing List
> Subject: Re: LDP requires break-before-make
>
>
> Hi Eric
>

---

From: Chris Kuszmaul <[email-masked]>
Date: Thu, 07 Jun 2001 10:27:59 -0700

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