[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question on LMP.
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.
> > 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') ?
> > 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).
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.
> 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 |
+------------------------------------------------------------------+