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

[Jonathan Lang <jplang@calient.net>]

Nidhi,
  Sorry for the delay in responding.  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Bhargava, Nidhi [mailto:nidhi.bhargava@netplane.com]
> Sent: Thursday, September 20, 2001 6:45 AM
> To: Jonathan Lang; 'Fugui Wang'; John Drake; 'kireeti@juniper.net';
> 'yakov@juniper.net'; 'lberger@movaz.com'; 'dsaha@tellium.com';
> 'dbasak@accelight.com'; 'hsandick@nortelnetworks.com';
> 'braja@tellium.com'
> Cc: 'ccamp@ops.ietf.org'
> Subject: RE: Questions regarding draft-ietf-ccamp-lmp-00.txt (LMP)
> 
> 
> Jonathan,
> With reference to answer to question (2), do we wait for the other side 
> so set the control channel down bit in the hello messages before going to 
> DOWN state or do we immediately go to DOWN state without caring about the
> neighbour.
I will add the following to the next rev of the draft:
"The node may stop sending Hello messages after HelloDeadInterval seconds
have passed, or if it receives an LMP message over the same control channel
with the ControlChannelDown flag set." 
> 
> Also I have a question regarding the reconfig event. When the reconfig 
> event is generated, do we always send the config message regardless of 
> neighbours node id. Or we will only send config is our node if is greater
> than neighbours. Do we need to stop the hello protocol before doing the
> renegotiation?
Yes, you can send the config message (regardless of neighbor's node ID) if
you want to reconfig.  You can continue sending the Hello protocol.

> 
> Lastly when the control channel reboots, we are expected to come back to
> the UP state and resume Hello protocol. Shouldn't we be doing a config
> procedure again. Does the node reboot bit in the common header represents
the 
> node reboot or the control channel reboot?
You should do a config procedure again.  The node reboot bit has been
renamed to LMP Restart to indicate that the LMP module has restarted.

> 
> Thanks
> Nidhi
> -------------------------------
> Nidhi Bhargava
> NetPlane Systems Inc.
> A Mindspeed Technologies Company
> Tel:   + 1.781.329.3200 x5353
> Web:   http://www.netplane.com
> 
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Jonathan Lang [mailto:jplang@calient.net]
> > Sent: Wednesday, September 19, 2001 6:40 PM
> > To: 'Fugui Wang'; John Drake; 'kireeti@juniper.net';
> > 'yakov@juniper.net'; 'lberger@movaz.com'; 'dsaha@tellium.com';
> > 'dbasak@accelight.com'; 'hsandick@nortelnetworks.com';
> > 'braja@tellium.com'
> > Cc: 'ccamp@ops.ietf.org'
> > Subject: RE: Questions regarding draft-ietf-ccamp-lmp-00.txt (LMP)
> > 
> > 
> > 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.
> > 
>