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

[Fugui Wang <fwang@axiowave.com>]

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?

(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.

(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.

2. TE link FSM:

(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.)