RE: Questions regarding draft-ietf-ccamp-lmp-00.txt (LMP)

[Jonathan Lang <jplang@calient.net>]

Fugui,
  See inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Fugui Wang [mailto:fwang@axiowave.com]
> Sent: Wednesday, September 19, 2001 8:42 AM
> To: Jonathan Lang; Krishna Palla; John Drake; 'kireeti@juniper.net';
> 'yakov@juniper.net'; 'lberger@movaz.com'; 'dsaha@tellium.com';
> 'dbasak@accelight.com'; 'hsandick@nortelnetworks.com';
> 'azinin@cisco.com'; 'braja@tellium.com'
> Cc: 'ccamp@ops.ietf.org'
> Subject: Questions regarding draft-ietf-ccamp-lmp-00.txt (LMP)
> 
> 
> Hi,
> 
> During the implementation of the LMP protocol, I have got several
> questions regarding the LMP draft. Could you please clarify any of
> them?
> 
> Thanks,
> Fugui
> 
> 1. Control Channel FSM:
> 
> (1) There are two events which could bring up the control channel,
evBringUp_1a,
> evBringUp_1b.  Does that mean that in the MIB we need to have  something
like
> activeUp and pasvUp in the AdminStatus of control channel table?
I don't think this is necessary.

> 
> (2) In this version, the GoingDn state is removed. When a control channel
> gets evAdminDown event, it will go to Down state immediately. 
> Should it send a Hello or other messages with ControlChannelDown bit set
to the 
> neighbor before it goes down? Since the Hello message is sent
periodically. If we 
> don't send an additional Hello with ControlChannelDown bit set, most
probably, the 
> control channel would never have a chance to send such a message. Then the
remote 
> node will get Hello time out instead of get the event evNbrGoesDn.
We will add text to the evAdminDown event indicating that Hello messages
sent before going down should have the ControlChannelDown bit set.

> 
> (3) When receiving a ConfigNack, if the Hello Config TLV is nonegotiable
or
> it is negotiable but we could not find the values acceptable for 
> both side, should we still keep sending Config message? According to the 
> Control Channel FSM, when getting the evConfErr, the control channel
should keep in 
> ConfSnd state.
If the configuration parameters are negotiable, and the proposed values are
acceptable, a new Config message should be transmitted with these values.
If the Nack'd values are non-negotiable, or if the proposed values are
unacceptable, you can go into the down state (event 2) or keep trying with
your values (hoping that configuration is changed at the far end).

> 
> 2. TE link FSM:
In the next version of LMP we are simplifying the TE link FSM.  The TE Link
can really only be in the UP, DOWN, and DEGRADED states.  Link Verification
can occur in either the UP or DOWN states, and could be represented using
sub-states.

> 
> (1) After verification is done (evVerDone), the FSM goes from VrfProc to
> Summary state. However, if all of the Data Bearing links failed in the 
> verification, should the TE link still enter the Summary state and send a
> LinkSummary message with no TLV? Or should it go from VrfProc to Down
state
> directly without sending such a meaningless LinkSummary message? (This
could
> happen if the Data Bearing links and TE links have not been configured in
> the remote side yet and the local side has already configured and start to
> verify.)
> 
> (2) In the Summary state, the node keep sending LinkSummary message to
remote
> until it receives LinkSummaryAck or LinkSummaryNack. Should we have an
other
> events such as evSummaryTimeout so that we won't keep trying infinetely if
> we couldn't get any response from the remote?
> 
> (3) There is no event in the FSM indicating what will happen if the node 
> receives BeginVerify, LinkSummary. My understanding is that the receiver
> side is stateless. Is that correct?
> 
> (4) How to handle BeginVerifyNack? There is no event in the FSM
> corresponding to this.
> 
> 3. BeginVerify Message:
> 
> The BeginVerify message brings a field VerifyInterval. But my
understanding
> is that the receiver side should care more about the Verify Dead 
> Interval than the Verify Interval since it needs to use the Verify Dead 
> Interval to determine when to send TestStatusFailure back. (Note that the
> reciever side may not be able to get the Verify Dead Interval from the
local TE link 
> configuration If the sender side don't know the remote TE link ID and want
to learn
> it through verification.)
The VerifyDeadInterval is determined at the receive side and must take into
account the VerifyInterval at which the Test messages are sent.