Subject: Last Call for draft-ietf-mpls-ldp-state-02

From: Adrian Farrel <[email-masked]>
Date: Thu, 25 Nov 1999 20:42:41 -0000

Hi Vijay, Eric,

I'm afraid I don't currently have the bandwidth to give this a thorough
going over, but here are some thoughts on the first state machine.  As
usual, typos are pulled out at the end.

I hope this helps,
Regards,
Adrian

1. References to CR-LDP.  
At various points there are references to CR-LDP (e.g. section 3.0 point 2).
If the draft is intended to cover LDP and CR-LDP perhaps this could be made
clearer in section 1.

2. State Transition Diagram (section 3.1.4)
I don't believe this diagram matches the text.  A better version would look
as follows.

Note that I have shown (LDP Request 1) and (LDP Request 2) as well as (LDP
Withdraw 1) and (LDP Withdraw 2) to clarify (?) the two actions that select
the state transition based on other parameters.

(I hope my mail gateway doesn't mess this up by deciding that there are
fewer than 72 characters on a line)

               +-------------------+
               |                   |<-------------------+
     +-------->|  IDLE             |                    |
     |         |                   |---->-----+         |
     |         +-------------------+          |         |(LDP Release)
     |(LDP Release)       |                   |         |(LDP Upstream
     |(LDP Upstream       |(LDP Request 1)    |         | Abort)
     | Abort)             |(Internal SetUp)   |         |(Upstream Lost)
     |(Upstream Lost)     |                   |         |
     |(Internal Destroy)  v                   |         |
     |         +-------------------+          |         |
     +----<----|                   |          |         |
               |  RESPONSE_AWAITED |          |         |
     +----<----|                   |          |         |
     |         +-------------------+          |         |
     |                   |                    |         |
     |(Downstream Lost)  |(LDP Mapping)       |         |
     |(LDP Downstream    |                    |         |
     | NAK)              |     +--------------+         |
     |                   |     | (LDP Request 2)        |
     |                   |     |                        |
     |                   v     v                        |
     |         +-------------------+ (LDP Withdraw 1)   |
     |         |                   | (Internal Destroy) |
     |         |  ESTABLISHED      |------------>-------+
     |         |                   |                    |
     |         +-------------------+                    |
     |                  |                               |
     |                  |                               |
     |                  |(LDP Withdraw 2)               |
     |                  |(Downstream Lost)              |
     |                  |                               |
     |                  v                               |
     |         +-------------------+                    |
     |         |                   |                    |
     +-------->| RELEASE_AWAITED   |------------>-------+
               |                   |
               +-------------------+

I tried to produce a diagram showing all valid input events including those
which do not result in a state transition, but this gets rather messy
because there are a number of cases where an input event may or may not
result in a state transition depending on the details of the action.

3. Transition to IDLE/ Control Block Deletion
Some events (as shown) cause transition to IDLE state and this is always
accompanied by deletion of the LSP_Control_Block.
Other events (for example, Downstream Lost in RESPONSE_AWAITED state) simply
say delete the control block.
It's quite obvious what is going on here, but it might be clearer to include
the state transition explicitly in the action.

4.  Section 3.1.5.4
Missing Event Internal New NH in state RELEASE_AWAITED.
I believe this should read...

 State:          RELEASE_AWAITED

 Event:          Internal New NH

 New State:      RELEASE_AWAITED

 Actions:

   Ignore. It is an internal implementation error.

Typos
-----

Section 1, para 2, last line.  For "downstream mode" read "downstream
unsolicited mode"

Section 1, para 3, 2nd line.  For "we not" read "We do not"

Section 3, final para.  Read "loop prevention messages"

Section 3.1, 2nd para, final word.  Read "involved"

Section 3.1.1, just before control block diagrams.  For "Next Hop Trigger
Block" read "Next Hop Trigger Control Block" 

Section 3.1.5.4
LDP Mapping in RELEASE_AWAITED  and  LDP Withdraw in RELEASE_AWAITED
For "an protocol" read " a protocol"

Section 3.1.5.4
"LDP Upstream NAK" in RELEASE_AWAITED state should read "LDP Upstream Abort"

--
Adrian Farrel  mailto:[email-masked]
ATM, MPLS and Telecoms Development Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

>-----Original Message-----
>From: Vijay Srinivasan [mailto:[email-masked]]
>Sent: Wednesday, November 24, 1999 3:02 PM
>To: [email-masked]
>Cc: George Swallow; Multi-Protocol Label Switching WG
>Subject: Re: Last Call?
>
>So, let's commence the WG last call for
>draft-ietf-mpls-ldp-state-02.txt, ending Friday, December 3.  Please
>post comments to the mailing list.