RE: Comments on LMP draft 3

[Jonathan Lang <jplang@calient.net>]

Fugui,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Fugui Wang [mailto:fwang@axiowave.com]
> Sent: Monday, March 18, 2002 12:55 PM
> To: Jonathan Lang
> Cc: 'ccamp@ops.ietf.org'
> Subject: Comments on LMP draft 3
> 
> 
> Hello Jonathan,
> 
> Here are some comments regarding draft-ietf-ccamp-lmp-03.txt:
> 
> 1. In page 5, section 3:
> "Rather, a node-wide unique 32-bit non-zero integer control channel
identifier
> CCId) is assigned at each end of the control channel. This identifier
comes
> from the same space as the unnumbered interface Id."
> 
> If the control channel is directly on ethernet instead of point-to-point 
> interface or IP tunnel, what should be chosen as the CCId?
> For example, in the following case, if Node A, B, C are connected by 
> ethernet. Node B should have a control channel to A and C respectively.
> What should be the CCIds for these two control channels? In this case
> interface ID is not able to uniquely identify the control channel.  
> 
>     .1                  .2                     .3    10.1.1.0/24
> ----+--------------------+----------------------+--------------
>     |                    +                      |
> +---+---+            +---+----+            +----+----+
> |ifId=2 |            | ifId=3 |            |  ifId=4 |
> |   A   |            |   B    |            |    C    |
> |       |            |        |            |         |
> +-------+            +--------+            +---------+
The CCId is a local identifier.  In the above case, Node B will assign two
separate CCIDs for the control channels to nodes A and C.


> 
> 2. In page 9, section 3.2:
> "The LMP Hello protocol is intended to be a lightweight 
>  keep-alive mechanism that will react to control channel failures 
>  rapidly so that IGP Hellos are not lost and the associated link-
>  state adjacencies are not removed unnecessarily."
> 
> I don't quite understand how LMP hello could prevent IGP hello lost.
> My understading is: as far as there is at least
> one contral channel active between the neighbor, IGP won't remove the
> link-state adjacency, even without LMP detecting the control channel
> failure.
> Is that right? 
LMP can be used to maintain active control channels between neighbors. These
control channels can be used to build a resilient adjacencies in
routing/signaling.

> 
> 3. In page 9, section 3.2.1:
> "If the fast keep-alive mechanism of LMP is not used, the 
>  HelloInterval and HelloDeadInterval parameters MUST be set to zero."
> 
> This paragraph says that the Hello could be optional. However, in the
> Control channel FSM, it seems that this case is not considered.
The intent of the Control channel FSM was to show the state changes when LMP
keep alive is used.  I'm not sure how interesting/helpful it is to discuss
the CC FSM when the keep alive is not used.

> 
> 
> 
> Thanks,
> Fugui
>