Subject: Label Abort Request Message in LDP-05

From: "Prakash C. Jain" <[email-masked]>
Date: Sat, 07 Aug 1999 12:53:23 +0530

Hi Bob,

1. LDP-05 sec 3.5.9, page 71 while mentioning FEC TLV says,

FEC TLV
     Identifies the FEC for which the FEC-label mapping is being
     withdrawn.
This should be the FEC for which Label Request has been sent.

2.In section 3.5.9.1. Label Abort Request Message Procedures, it is
mentioned (page 72 of LDP-05) that,

When an LSR receives a Label Abort Request message, if it has not
   previously responded to the Label Request being aborted with a Label
   Mapping message or some other Notification message, it must
   acknowledge the abort by responding with a Label Request Aborted
   Notification message.  The Notification must include a Label Request
   Message ID TLV that carries the message ID of the aborted Label
   Request message.

But Label Request Message ID TLV is not defined to be a part of
Notification message (section 3.5.1, page 46 of ldp-05). Should this TLV
be one of the optional parameters of Notification message, or the status
TLV in the Notification should contain the message Id of aborted Label
request message and msg type as Label request. The status TLV should
contain the message Id of label abort message or that of the aborted
label request message?

3. In case when Label Map is received after sending Label Abort Request,
no Notification (Label Request Aborted) is expected. Hence processing of
Label Map (section A.1.2 on page 93 of ldp-05 draft) should include
checking of pending Label Abort Request messages, and deleting records
of pending Label Aborts and sending release for the received mapping.

4. Similarly record of pending Label Abort should be deleted in case a
notification of type No route or No Label resources, loop detected is
received (section A.1.9/page 109 and A.1.10/page 110) after sending
Label Abort message.

5.Label Abort Request message can also be used for aborting CR-LSP
creation. The format of Label Abort Request for CR-LSP has not been
defined yet. The label abort message for CRLSPs should also include LSP
ID TLV (LSP ID TLV is mandatory parameter in Notifications for CR LSPs
as per cr-ldp-01).

6. Similarly cr-ldp-01 specifications requires mandatory Returned
Message ID TLV in Label Request Message. This TLV is not a part of
ldp-05. So, cr-ldp-01 and ldp-05 are not compatible.

Thanks in advance,
Prakash

--
___________________________
Prakash C. Jain
Ficon Technology
mailto:[email-masked]
http://www.ficon-tech.com/

---

From: Eric Gray <[email-masked]>
Date: Sun, 08 Aug 1999 13:09:20 -0400

Prakash,

You wrote:
> ...

The Status TLV would include the Message ID of the Abort message
(it should have a status of 'aborted').  The Label Request message
ID is needed to indicate the message ID that the downstream LSR
stashed as a 'transaction ID' for a pending Label Mapping.  The
Label Request Message ID TLV is included as an 'optional' TLV in
the Notification message (however mandatory it is in a particular
Notification, it is optional generally).  This is required mostly
for completeness in acknowledgment since it is possible (but not
required) for the upstream LSR which sent the Label Abort Request 
message to have stored the original Label Request Message ID with
any state information it may have associated with the Label Abort
Request Message.

Note that the two message IDs may not be the same.  This is stated
pretty much explicitly in the middle of page 72.  One reason for 
this is to preclude the downstream LSR from possibly discarding an
Abort message as if it were a duplicate Label Request.

> of pending Label Aborts and sending release for the received mapping.

This is one approach.  It is NOT, however, necessary to retain 
'state' information on the Abort message.  In the Downstream
on Demand mode, an LSR will most probably release any Label
Mapping it receives for which it does not have pending Label
Request state.

Therefore, an equally viable approach is for the LSR to simply
discard the Label Request state while processing the Abort (it
may do this in any case).  Then it will automatically Release
any Label Mapping it receives.

Note that the upstream LSR can legitimately decide to use the
label provided in such a Label Mapping to satisfy some other 
outstanding Label Request for an indistinguishable FEC.  For
example, if an LSR has 3 outstanding Label requests for the
same FEC and receives a Label Mapping for one of them, just 
after it has sent an abort for that one, it may use this Label
Mapping to satisfy one of the other 2 Label Requests.  It may,
subsequently, abort one of the other outstanding Label Requests
or release one of the other Label Mappings it receives.

> received (section A.1.9/page 109 and A.1.10/page 110) after sending

There are 4 types of Notification messages currently defined:

1) fatal error (drop session),
2) LSP setup failed/aborted (drop LSP),
3) LSP setup stalled (no resources) and
4) LSP setup may continue.

I feel certain that the text on page 71 and 72 (describing 
processing of an Abort message) refers only to Notification
messages of type 2.

Type 1 Notifications clean the slate and force participants
to start from scratch.  Thus prior states with respect to 
who sent Aborts, Notifications, Mappings, Releases, etc. is
irrelevant once such a Notification has been either sent or
received.

At any point where an Abort message and a type 2 Notification, 
or an Abort message and Label Mapping (and subsequent Release) 
cross each other in transit, 'state' at the upstream/downstream
LSRs ends up being correct.  There is a slight possibility
that a Notification message may be propagated one additional
hop upstream because of retained state in the LSR that is 
processing it.  This Notification message SHOULD NOT be sent,
however it also SHOULD NOT produce a fatal error upstream if
it is.

The No Label Resources Notification is a type 3 Notification: 
since the downstream LSR in this case may have retained state 
on a Label Request (it must be prepared to send a subsequent 
Label Resources Available Notification), it would delete this 
state and send an Aborted Notification.  If it did not retain 
state (for example, it may simply have set a flag indicating 
that it needs to send a Label Resources Available Notification
at least to this upstream peer), then it should simply return 
an Aborted Notification.  In this case, it would be unable to 
include a Label Request Message ID TLV.

> ID TLV (LSP ID TLV is mandatory parameter in Notifications for CR LSPs

CR-LDP uses LDP messages and procedures as a starting point
and does not re-define messages and TLVs defined in LDP except
as might be necessary to specify inclusion of additional TLVs
required for correct CR-LDP operation.

> ldp-05. So, cr-ldp-01 and ldp-05 are not compatible.

Bilel Jamoussi indicated at the last IETF meeting that he is
re-spinning CR-LDP to include changes in the latest versions
of LDP.

The Return Message ID TLV was eliminated in recent versions
of LDP and will be removed from CR-LDP.  Part of the reason
why the TLV was eliminated in LDP is because of the reasons
why it was mandatory in CR-LDP.  Something needs to be used 
for a transaction ID in the event that there are multiple,
indistinguishable, Label Requests outstanding at one time.
This would be likely to happen in vanilla LDP if an upstream 
LSR is not merge capable and needs to support multiple LSPs 
from its own upstream neighbors for indistinguishable FECs.

Other changes (to include the fact that LDP defines an Abort
message) are required to bring CR-LDP into alignment with the
current version of LDP as well.

I understand that a new version of CR-LDP will be available
in very short order (possibly a few days).

---

From: "Prakash C. Jain" <[email-masked]>
Date: Mon, 09 Aug 1999 20:11:04 +0530

Hi Eric,
Thanks a lot for your response. Please see my comments in mail below just to
verify if I understood correctly,

> any state information it may have associated with the Label Abort

That means ldp-05 should include Label Request Message ID TLV in the list
ofoptional parameters of Notification message (section 3.5.1, page 45).

> Mapping it receives for which it does not have pending Label

I agree, but draft ldp-05 mentions,(section A.1.3, LAbR.10, page 99)   LAbR.10
Record that a label abort request for FEC is pending.
which suggests to maintain state on Label Abort (probably to avoid possible reuse
of request message ID). So, it should be cleared when response comes.

> include a Label Request Message ID TLV.

I think, presently ldp-05 suggests not to send any Aborted Notification in this
case (section A.1.3, LAbr.2, page 98) as LSR has already replied to Label Request
with No Label Notification.

>   ------------------------------------------------------------------------
>
>   Eric W Gray <[email-masked]>
>   Bell Laboratories, Lucent Technologies, Inc.
>   PacketStar IP Switch Development
>
>   Eric W Gray
>   Bell Laboratories, Lucent Technologies, Inc.     <[email-masked]>
>   PacketStar IP Switch Development
>   PO Box 0710 ;Durham;New Hampshire;03824-0710;US  Work: 603 659 3386
>                                                    Netscape Conference Address
>   Additional Information:
>   Last Name     Gray
>   First Name    Eric W
>   Version       2.1

---

From: Bob Thomas <[email-masked]>
Date: Mon, 09 Aug 1999 14:09:17 -0400

Prakash,

Sorry to be so slow in responding to your questions.

> This should be the FEC for which Label Request has been sent.

Thanks for pointing out this copy/paste error.

> contain the message Id of label abort message or that of the aborted

The Status TLV should contain the Message ID of the Label Abort message.
The Notification that carries the Status TLV should also include a Label
Request ID TLV that carries the Message ID of the aborted Label Request
message (i.e., the Label Request ID TLV carried by the Label Abort Request
message).

Please note the following text from Section 3.5.1 "Notification Message":

     Other Optional Parameters, specific to the particular event being
     signaled by the Notification Messages may appear.  These are
     described elsewhere.

> of pending Label Aborts and sending release for the received mapping.

I agree that any record of the pending abort should be cleared upon
receipt of the Label Mapping message since the abort is no longer
pending.  While an LSR is free to release a label whenever it chooses,
I disagree that the label must be released in this situation.

> received (section A.1.9/page 109 and A.1.10/page 110) after sending

Since these notifications terminate the pending abort I agree that any
record of the pending abort should be cleared in these cases.

> ldp-05. So, cr-ldp-01 and ldp-05 are not compatible.

Since draft-ietf-mpls-ldp-05.txt deals with LDP and not CR-LDP, these
comments are out of scope for ldp-05.  They should probably be redirected
to the CR-LDP authors.

Regards,
Bob