The MPLS WG Archive

[Jonathan Lang <jplang@calient.net>]

Mani,
  Please see in-line comments.  Sorry for the delay as I've been out of
town.

Thanks,
Jonathan

> -----Original Message-----
> From: Manikantan S [mailto:manis@future.futsoft.com]
> Sent: Friday, November 03, 2000 6:06 AM
> To: Jonathan Lang
> Cc: mpls@uu.net
> Subject: "draft-ietf-mpls-lmp-00.txt" - Doubts.
> 
> 
> Hello Jonathan
> 
> I read the draft "draft-ietf-mpls-lmp-00.txt".
> 
> I have a few doubts, (forgive me if I sound stupid) can you 
> please clarify
> them. Thanks.
> 
> 1) My understanding is that
>    - LMP is for taking care of uni directional Links.
>    - The sequence of BeginVerify Message to the Test messages 
> is associated with a set of links.
correct.

> 
>    a) When indicated as unidirectional, I assume that the 
> Upstream node should initiate the
>       sequence. How does an LSR know that is an upstream for 
> a Link? (Please indicate if I am missing something).
upstream node is on the transmit side of a unidirectional link.

>    b) Will there be a possibility of both the upstream LSR and the
> downstream LSR initiate the
>       BeginVerify ... Test message sequence for a set of link 
> at the same time? i.e. will there
>       be a Race condition? If so how should this be handled?
There will not be any race conditions for the Test procedure as Test
messages go in one direction, from transmitter to receiver.  

> 
> 2) In Section 8.1, we have the FSM and the following for the
> HelloConfigNack,
> 
>                                 |  0  |  1  |  2  |
>    -----------------------------|-----|-----|-----|
>                                 |     |     |     |
>    Receive HelloConfigNack      |  -  |  0  | 2b,d|
>                                 |     |     |     |
> 
>    a) In state 1, when a HelloConfigNack is received from the 
> Neighbor,
> there can be two
>       conditions.
>       I)  The Hello parameters sent by the Neighbor in NACK message is
> acceptable locally and
>           hence a new hello message should be generated. If 
> so then the FSM
> will have value 1a
> 
>       ii) The Hello parameters sent by the Neighbor in NACK 
> message is not
> acceptable locally and
>           hence no hello message to be generated. If so then 
> the FSM will
> have value 0.
> 
>    b) In state 2, it is currently marked as 2b,d.
>       I) Can a HelloAck be generated when a NACK is received?
>          I think the conditions mentioned in above question a) will be
> applicable in this
>          state 2.
>
(a) was pointed out in a private email by someone else.  The following
modification has been made to the FSM:

Receive HelloConfigNack with |  -  | 1a  |  2d |  
  agreeable parameters       |     |     |     |     
                             |     |     |     |         
Receive HelloConfigNack with |  -  |  0  |  -  |
  unacceptable parameters    |     |     |     |    
> 
> 3) In Section 9.4.8 it has been stated that
>    "   The TestStatusFailure message is transmitted over the control
>        channel and is used to indicate that the Test message was not
>        received.  "
>    How can we know that the Test message was not received?
As part of the Test procedure (BeginVerifyAck message) there is a
VerifyDeadInterval that is used to timeout when looking for a Test message.

> 
> 4) In Section 9.6.3 Explanation as "NumChannelFail" is 
> present. This is
> absent in the
>    "ChannelFailNack" message? Is this a typo?
Correct, it's a typo.  NumChannelFail should not be present.

> 
>    Why do we need two messages "ChannelFailAck" and "ChanelFailNack"
> message?. We can provide
>    both the "clear" and "failed" channel information in a 
> single message,
> similar to the
>    LinkSummary messages.
Thanks.  We are currently looking into this.
 
> 
> Thanks in advance
> with best regards
> mani
> 
> 
>