Re: Question on LMP.

[Zafar Ali <zali@cisco.com>]

Hi Michiel, 

Please see comments in-lined. 

Thanks

Regards… Zafar 

At 11:47 AM 4/24/2002 +0200, Michiel van Everdingen wrote:
> Hello Zafar,
>
>
> > No, I think the main source of confusion is that LMP Hellos are NOT
> the
> > only thing that is part of the control channel management. 
>
> What else ?
> Control Channel Management seems to only set up a communication
> mechanism
> (in the control plane) between two nodes that are neighbours at the
> transmission plane, i.e. that are neighbours regarding dataLinks.
> Also, if I look at the definition of the config messages, I can only
> find
> parameters that deal with this communication mechanism.
>
> I'm still confused as to why standard network layer mechanisms would
> not
> be sufficient.

I think this answer depends on how we define sufficient;-)
LMP control channel management brings some features into picture, e.g.,
when we’ve hidden control channels, how can we guarantee that the
neighbor is listening to the channel we’re sending your control messages
to? With the configuration handshake, LMP guarantees that the two ends
are ready to exchange messages on the control channel in question. 

Similarly, it provides a way by which failure on a routed control channel
(control channel is not bound to a physical interface) or a control
channel where L2 cannot detect the failure. Without LMP control channel
management, how you would suggest management and health check for such
control channels? Skipping such tests will IMO lead to a more ad hoc
procedures/ protocols. 



> > > Is there a need to distinguish
> between signalling channels and control
> > > channels ?
> > 
> > Yes, e.g., RSVP recovery procedure differentiate between the
> control
> > channel failures and the signalling channel (Nodal) failure.
>
> My understanding is that a nodal failure "relates to the case where
> a node
> losses its control state (e.g., after a restart) but does not loose its
> data
> forwarding state."
>
> A nodal failure is therefore something else than a failure in a
> communication
> mechanism. Correct ?
>
> Why do you relate nodal failure with the failure of a communication
> mechanism (the 'signalling channel') ?

Signaling channel is a term I used to specify the following:
Signaling channel is the logical channel over which signaling (say
RSVP-TE) messages are exchanged between RSVP peering entities. The
signaling channel is realized using the collection of all control
channels between the two RSVP peers. A signaling channel failure could be
the result of the concurrent failure of all control channels or the
failure of one of the peering signaling entities or one of the peering
nodes. Hence, signaling channel failure is different than failure of all
control channels. 

Using the above mentioned definition, a nodal failure always imply the
failure of the signaling channel as well as control channels. However,
failure of the last control channel does not imply a nodal failure. For
the sake of completeness, a signaling channel failure could be due to
failure of the peering RSVP process or due to the neighbor node failure.
The draft-ietf-mpls-generalized-rsvp-te-06.txt uses the term nodal
failure to cover both cases: i.e., the case where peering RSVP entity
restarts or the entire node fails. In either case, non-stop forwarding is
assumed. In short, failure of the last control channel is different from
the nodal failures. 



> > > Can't they make use of the same IP
> network ?
> > 
> > Yes, they use the same IP (Control) network, but there are
> differences in
> > the two failure cases, e.g., when a peering RSVP process fails vs.
> peering
> > LMP process fails, control channel(s) failure due to peering node
> failure
> > vs. control channel(s) failure due to an event that made neighboring
> node
> > unreachable, etc.
>
> Is there a (mandatory) need to distinguish between a failure of the
> RSVP-TE
> process and a failure of the LMP process ? I guess in a lot of cases they
> fail
> together (e.g. in case of a nodal failure).

In draft draft-ietf-mpls-generalized-rsvp-te-06.txt, RSVP
recovery procedure treats nodal failure and control channel failure
differently (please see above for how they are related to the failure of
the individual processes). 

I think what you’re proposing is that we don’t need to distinguish
between the two and we can always apply the signaling channel failure
(draft uses the term nodal failure to refer to a more general case)
mechanisms, even in the case of control channel failure? Clearly in the
absence of LMP, failure of all control channels can only be detected by
the signaling layer, hence will be treated as nodal failures. However,
with failure detection on the control channel, we can do a better job in
recovering. 


> Why are process failures related to
> communication channel failures ?
> This might indeed lead to the need for two distinct communication
> channels ('control channel' and 'signalling channel'), which seems to
> be
> a disadvantage to me.

Please see my definition of a signaling channel failure in the above. I'm
sorry that the absence of the definition in the earlier email caused some
confusion. 



> > When we lose the last
> control channel with a given neighbor, we lose LMP
> > adjacency with that neighbor. This is an event that IMO requires
> proper
> > treatment from GMPLS control plane.
>
> I'm only arguing that standard network layer mechanisms can handle
> loosing some links in the control plane. We don't need - in my mind
> -
> something specific for LMP.
>
>
> Thanks,
>
> Michiel
>
>
> Zafar Ali wrote:
> > 
> > Dear Michiel,
> > 
> > Please see comments in-lined. Jonathan, et all please correct me if
> I am wrong.
> > 
> > Thanks
> > 
> > Regards… Zafar
> > 
> > At 11:14 AM 4/23/2002 +0200, Michiel van Everdingen wrote:
> > 
> > > Hello Zafar,
> > >
> > > Thanks for your answers.
> > >
> > > You start by stating
> > >   "The control channel failure detection
> mechanism is required if ...<snip>..."
> > > Does this imply that the "control channel management"
> procedure is not *always*
> > > required ?
> > 
> > No, I think the main source of confusion is that LMP Hellos are NOT
> the only thing that is part of the control channel management. I read the
> following in the draft as a way by which LMP Hellos on a given control
> channel can be disabled,
> > “If the fast keep-alive mechanism of LMP is not used, the
> HelloInterval and HelloDeadInterval parameters MUST be set to 
> zero.”
> > Or one can choose a very high value for the HelloInterval and
> HelloDeadInterval.
> > 
> > Nonetheless, the configuration parameters for the control channels
> need to be exchanged using the using Config, ConfigAck, and ConfigNack
> messages: the mandatory part.
> > 
> > > I understood from the draft and from Jonathan's answers that
> "control
> > > channel management" is mandatory.
> > >  
> http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00588.html
> > >  
> http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00606.html
> > >
> > > I can imagine there are cases in which "control channel
> management" is not
> > > providing benefit:
> > > - In case there is only one DCC channel with the neighboring
> node.
> > > - In case lower level mechanisms (e.g. MPLS protection or
> ML-PPP) are available.
> > > Control channel Management seems to give only unnecessary
> overhead and
> > > complexity in these cases.
> > >
> > > Is it possible to make "control channel management"
> an optional procedure ?
> > 
> > Does your comment applies only to LMP Hellos (for which solutions
> exist) or to the entire Control Channel State machinery?
> > 
> > > Please find further reactions on your email below:
> > >
> > >
> > > > E.g., we would like to distinguish between signalling
> channel failure and
> > > > control channel failure during RSVP-TE recovery process,
> etc.
> > >
> > > Is there a need to distinguish between signalling channels and
> control channels ?
> > 
> > Yes, e.g., RSVP recovery procedure differentiate between the control
> channel failures and the signalling channel (Nodal) failure.
> > 
> > > Can't they make use of the same IP network ?
> > 
> > Yes, they use the same IP (Control) network, but there are
> differences in the two failure cases, e.g., when a peering RSVP process
> fails vs. peering LMP process fails, control channel(s) failure due to
> peering node failure vs. control channel(s) failure due to an event that
> made neighboring node
> > unreachable, etc.
> > 
> > > > Hence, LMP Hellos should be faster than RSVP Hellos or the
> mechanism used to
> > > > detect signaling channel failure. Similarly, LMP Hello
> frequency should
> > > > be greater than IGP hello frequency, so that the optical
> network can make
> > > > "conscious" decision on the control channel
> failure, before having an adverse
> > > > affect on the IGP adjacencies at L3.
> > >
> > > Indeed. This added complexity makes me questioning if we really
> need "control
> > > channel management".
> > 
> > When we lose the last control channel with a given neighbor, we lose
> LMP adjacency with that neighbor. This is an event that IMO requires
> proper treatment from GMPLS control plane.
> > 
> > > > > As stated in section 13 of the LMP draft, all LMP
> messages are
> > > > > IP encoded. So a standard general purpose IP network
> should
> > > > > perfectly well be capable to transport such IP
> encoded LMP
> > > > > messages to the intended destination. Am I missing
> something
> > > > > here ?
> > > >
> > > > I am sorry but I did not understand what you meant
> here?
> > >
> > > This is in reaction to Jonathans question in another
> thread:
> > >  
> http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00636.html
> > > My feeling is that standard network layer mechanisms are
> sufficient.
> > >
> > >
> > > Regards,
> > >
> > > Michiel
> > >
> > > <...snip...>
>
> -- 
> +------------------------------------------------------------------+
> | Michiel van
> Everdingen                                          
> |
> | Systems
> Engineer                                                
> |
> | Lucent Technologies - Optical Networking
> Group                  
> |
> | Botterstraat 45, 1271 XL       Phone :
> +31 35 687
> 4883           |
> | P.O. Box 18, 1270
> AA          
> Fax   : +31 35 687
> 5976           |
> | Huizen, The Netherlands       
> mailto:MvanEverdingen@lucent.com
>  |
> +------------------------------------------------------------------+

===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.