Subject: some question about ldp-state-machine

From: [email-masked]
Date: Fri, 28 Jan 2000 09:52:08 +0800

Hi,
 I have still some questions about ldp-state-machine,that is:

1. in the section 3.2.2.8, in the downstream-lsp-control-block's
state machine,

State:          ESTABLISHED
Event:          LDP Downstream NAK
New State:      ESTABLISHED
Actions   It is a protocol error from the downstream LDP peer.

2. in the section 3.2.2.8, in the downstream-lsp-control-block's
state machine,  status ESTABLISHED, there is no actions to DOWNSTREAM LOST
event.

Why?
I think in the environment like the following, will meet the event
DOWNSTREAM LOST
in the downstream-lsp-control-block, status ESTABLISHED:

          A -----------------------> B
LSR A and LSR B  have already had an operational session, the LSP between A
and B is established.
Now we disconnect the link of A and B, so      LSR A's
downstream-lsp-control-block will
receive UPSTREAM LOST,and LSR B's  upstream-lsp-control-block will receive
DOWNSTREAM LOST.
So how to process it?

Can I process it like the actions of event LDP Downstream NAK in status
RESPONSE-AWAITED?
And in the status ESTABLISHED there will also meet the event LDP Downstream
NAK ,
How to process it?

Perhaps my point is not right, if I miss something, please let me know.

Thanks a lot!

Lijianping.

---

From: Eric Gray <[email-masked]>
Date: Fri, 28 Jan 2000 00:42:08 -0500

Lijianping,

	Where do you find a section 3.2.2.8?  The currently
posted version is numbered such that 3.2.2 is followed by
3.2.3 as the very next numbered sub-section.  Also, please 
see comments embedded below.

> Actions   It is a protocol error from the downstream LDP peer.

This is correct.  We have already received a Label Mapping
for this LSP, hence the LSP is ESTABLISHED.  If we now get
a Notify for this same LSP, the downstream LSR has goofed.

More over, the only way that I can associate an LSP with a
Notify message is by the Label Request message ID - which
I no longer have if I have received a Label Mapping (thus
completing the request/response transaction).  So I might
have no choice but to ignore the "event".

(note: not all implementations will get rid of the Label
Request Message ID - even though it is not useful; hence
it is not an internal error to get to this point - even
if it might be silly)

> state machine,  status ESTABLISHED, there is no actions to DOWNSTREAM LOST

Assuming you are actually referring to section 3.2.3.8.3,
it appears to have been left out.  Oops!

> Can I process it like the actions of event LDP Downstream NAK in status

No.  That would produce the protocol error addressed above.
You don't send Notify messages to peers when you have sent
a Label Mapping for the associated LSPs already.

> And in the status ESTABLISHED there will also meet the event LDP Downstream

No.  Getting a Notify message from the downstream peer that
has already sent a Label Mapping should not have any effect
(see above).  In many implementations, it CANNOT have any
effect.

> How to process it?

The correct way to process a downstream lost event is exactly 
the same as a LDP Withdraw (see toward the bottom of page 52).  

My suggested fix at this point is to copy the action for
LDP Withdraw while changing the event to Dowstream Lost.

To better understand how this works, you have to realize
that the LDP Session Control state machine would pass a
"Downstream Lost" event to every Downstream LSP control
block associated with a lost LDP peer.  This is on the
harry edge of LDP specification "turf" since the session
control state machine is defined there.

Out of curiosity, where were you during last call? :-)

--
Eric Gray