Subject: Label Abort request !!

From: Manoj Dutta <[email-masked]>
Date: Wed, 13 Jun 2001 21:04:17 -0700

Hi,

In RFC 3036, section A.1.3, LAbR.5 and LAbR.6 , why do we need to
generate release message in response
to an abort request message. Also,  what label id we should use for this
event (in the case where we have
multiple mappings from next hop)

thanks in advance
manoj

---

From: Abhijit Gadgil <[email-masked]>
Date: Thu, 14 Jun 2001 19:38:53 +0530 (IST)

Manoj,

the LAbR.5 and LAbR 6. Does not generate a label release message. It
states,

Generate Event : Received Label Release Message.

which may in turn lead to generate the Label Release message.

Also the point LAbR 5. will be reached if, a label request was received
from the MessageSource to which LSR under consideration has not replied.
(perhaps explicitely - for the request). and it has no outstanding
request. So the Mapping for the FEC was received and sent or is in the
queue to be sent. (either On Demand or Unsolicitedly). In this case since
upstream guy is not willing to use label binding from the LSR under
consideration, its most appropriate to generate label release event.

About the second question - As a part of receiving Mapping/Request, LSR
implementation will use stored information in determining which label to
release..

Hope that helps..

-abhijit

---

From: Eric Gray <[email-masked]>
Date: Thu, 14 Jun 2001 11:06:34 -0400

Manoj,

    Just to amplify on what Abhijit said:

    LAbR.1 and LAbR.2 deal with cases where no Label Request state
is present - either because no request was previously received, or
because a response has already been sent.

    LAbR.3 acknowledges the Label Request Abort message.

    LAbR.4 looks at the possibility that a Label Request may have been
propagated downstream (as a result of the Label Request being aborted)
and remains outstanding.  If one has, LAbR.7, LAbR.8 and LAbR.9 make
sure that that any unneeded Label Request downstream are cleared up,
and LAbR.10 sets up state relative to any required propagation of the
Label Request Abort message.

    LAbR.5 checks to see if a label mapping exists (possibly as a result of
a downstream Label Request for which it has already received a response).
If one does, LAbR.6 and procedures for Received Label Release Message
make sure that any unneeded Label Mappings are released.  To see why
this makes sense, read Note 2 (as suggested by the existing text).

    LAbR.11 then deletes state relative to the Label Request being aborted
- if any such state remains.

--
Eric Gray