Subject: RE: Some questions on Link Management Protocol (LMP) Draft-lang-m pls- lmp-01.txt

From: Jonathan Lang <[email-masked]>
Date: Fri, 6 Oct 2000 08:14:30 -0700

Gangxiang,
  Thanks for the comments.  Please see responses inline.  Also, please note
that the current published version of the draft is
draft-ietf-mpls-lmp-00.txt.

-Jonathan

> -----Original Message-----
> From: Shen Gangxiang [mailto:[email-masked]]
> Sent: Thursday, October 05, 2000 9:31 PM
> To: [email-masked]'
> Cc: Jonathan Lang
> Subject: Some questions on Link Management Protocol (LMP)
> Draft-lang-mpls- lmp-01.txt
> 
> 
> Hi, folks,
> 
> I have some questions on the draft: Some questions on Link Management
> Protocol (LMP) Draft-lang-mpls-lmp-01.txt
> 
> (Note that if I have missed some information which has been discussed
> before, please kindly point out.) 
> 
> 1. In the Section 4.2.1. Parameter Negotiation
> Let's consider the situation that both the local node and the remote node
> send the HelloConfig messages at the same time. If so some rules (e.g. the
> one according to the value of CCId) are needed to decide which HelloConfig
> message will be effective. 
You are correct.  A rule (based on nodeId) is being added to the next
version of the draft.

> 
> 2. In the Section 4.2.3 Control channel switchover
> As pointed out, "Control channels may need to be switched as a result of a
> control channel failure or for administration purposes (e.g., routine
fiber
> maintenance, reverting back to a primary control channel, etc.)...." and
"To
> ensure that both nodes switch to the backup control channel successfully,
> both the local and remote nodes MUST transmit messages over both the
primary
> and backup control channels until the switchover is successful. Messages
on
> the primary control channel MUST have the ControlChannelSwitchover flag
set
> to 1 and MUST not increment the TxSeqNum (even upon the receipt of a Hello
> message with the current TxSeqNum reflected in the RcvSeqNum field)...". 
> I guess that this "control channel switchover" mechanism may not be
suitable
> for the situation of "control channel failure", because if the primary
> control channel fails (e.g. terminated), it may not be able to transmit
the
> information of  "ControlChannelSwitchover flag". 
yes.  If a control channel has failed, a node may not be able to transmit a
Hello message with the Switchover flag.  However, there are many failure
cases where such a procedure is beneficial.  For example, if a node is not
receiving Hello messages from his neighbor but his neighbor is able to
receive messages from him, the above mechanism will expedite the switchover
process.  The above mechanism is also useful for switching over a control
channel administratively.

> 4. In Section 4.2.4. Taking a link down administratively
> I guess that some more details are required to be looked into if something
> wrong happens to the control channel when two nodes are exchanging the
LinkDown=1 message.
If the control channel fails before the LinkDown procedure is completed, the
control channel failure procedure will be initiated.  Once a failover is
complete, the LinkDown procedure can be completed.

> 3. In Page 10, "When the Test message is detected at a node, 
> .......and EndVerifyAck message MUST be sent."
> As proposed, the component channels are tested one by one. I 
> wonder why we don't test them at the same time. By doing this, at least we

> can save the time consumed by the tests.
The protocol does not limit the testing of the component links to be
one-by-one.  They can certainly be tested in parallel.

> Many thanks for comments!
> Gangxiang  
> 
> 
> 
>  
>