Subject: Re: Receive Label Abort Request

From: Srikrishnan Venkataraman <[email-masked]>
Date: Thu, 6 Jan 2000 18:06:49 +0530

there are 2 cases:
viz. 
1. lsr not responded to the Label Request message in which case you send 
  label Abort Notification message to the upstream.
  After this you need to check the downstream lsp state , whether it is in 
  Response_Awaited state. If so Propagate Label Abort message to the Next Hop.
  Delete the upstream lsp block.

2. If downstream lsp state = Established (Not Sure this case can happen because
   once the lsr gets Label Mapping message from the Fec Next Hop and the
   upstream Lsp state is Response_Awaited (for Ordered Control mode)
  it sends a Label Mapping message to the upstream peer and this code  shall
  execute as one single thread.............)
   assuming this scenario occurs and there are No upstream lsp (for Merge
capable)
  it will behave as if It has Received a Label Release event from the
Upstream peer
  and will propage the Label Release message to the Next Hop(if Label
Release propagation
  has been configured). But Propagating Label Release makes sense because
for that Lsp
  the concerned lsr is a Transit lsr. It would be logical to tear Down the Lsp.

Any Comments>>>>

At 04:55 PM 1/6/00 +0530, you wrote:
>Hello,
>         There is contradiction between the draft-ietf-mpls-ldp-06  and 
>   draft-ietf-mpls-ldp-state-02 .
>   According draft-ldp-06, if Downsream LSR receives Label Abort Request 
>from Upstream LSR after Downstream LSR sending  Label Mapping Message to 
>Upstream LSR, Downstream LSR should ignore the Label Abort Request Message 
>. Draft-ldp-state-02 specifies the free the upstream Label and send LDP 
>Release Message to Downstream LSR and delete the control Block.
>
> The draft-ietf-mpls-ldp-06 says
>
>      "  When an LSR receives a label abort request message from a peer, it
>     checks whether it has already responded to the label request in
>     question. If it has, it silently ignores the message. If it has
>     not, it sends the peer a Label Request Aborted Notification. In
>     addition, if it has a label request outstanding for the LSP in
>     question to a downstream peer, it sends a Label Abort Request to
>     the downstream peer to abort the LSP. "
>
> Algorithm:
>
>   LAbR.1  Does the message match a previously received label request
>           message from MsgSource? (See Note 1.)
>           If not, goto LAbR.12.
>
>   LAbR.2  Has LSR responded to the previously received label request?
>           If so, goto LAbR.12.
>
>   LAbR.12  DONE. "
>
> But draft-ietf-mpls-ldp-state-02  says as follows :
>
>State:          ESTABLISHED
>
> Event:          LDP Upstream Abort
>
> New State:      IDLE
>
> Actions:
>
>   Disconnect the upstream label from the downstream label.
>
>   Free the upstream label.
>
>   Send event "Internal Destroy" if the LSR was in the middle of
>   switching over to the better next hop.
>
>   Propagate an LDP-RELEASE message downstream and delete the
>   LSP_Control_Block.
>
>Please clarify it.
>Thanks,
>Kishore
>
>T M Kishore,
>Senior Software Engineer,
>Future Software Pvt Ltd,
>480 - 481, Anna Salai, Nandanam,
>Chennai - 600 035
>India.
>Phone : +91-44-4330550 Ext.412
>
>
>

---

From: Eric Gray <[email-masked]>
Date: Thu, 06 Jan 2000 09:15:04 -0500

Srikrishnan and Kishore,

	Thanks for pointing this out.  As Bob Thomas
said already, the LDP specification specifies correct
behavior.  The section in question in the LDP state
draft is incorrect for the reason that Srikrishnan
mentions below - i.e. the Established State means I 
have sent (or at least queued for sending) a Label
Mapping upstream.  While I do not necessarily agree
that an implementation must send the Label Mapping
message upstream necessarily on the same thread as
the one on which it received a Label Mapping from
downstream, it is valid to assume that this is done
in the simplistic state machine described in the
draft.  (Implementations that use a multi-threaded
approach in this instance, may have a more complex
state-machine which is none-the-less compatible with
that which the draft defines).

	Although the last call has closed, we will
work out a corrected wording that is consistent 
with the LDP specification for this bug in the draft.

	Thanks again,

Eric Gray