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

["Bhargava, Nidhi" <nidhi.bhargava@netplane.com>]

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.

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?

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?

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