Re: Question on LMP.

[Michiel van Everdingen <MvanEverdingen@lucent.com>]

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


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 ?
Can't they make use of the same IP network ?


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


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

Zafar Ali wrote:
> 
> Hi Michiel,
> 
> Please see some comments in-lined.
> 
> Thanks
> 
> Regards... Zafar
> 
> At 08:32 AM 4/22/2002 +0200, Michiel van Everdingen wrote:
> 
> > Hello Manoj, Ravi, Jonathan, Zafar,
> >
> > I'm somewhat confused on the state of this thread. As far as I
> > can see, the following questions are still open:
> > - why is control channel management needed at all ?
> 
> The control channel failure detection mechanism is required if lower-level mechanisms are NOT available to detect control channel failures. E.g., when control channel is (IP) routed and not bound with a particular interface. Furthermore, a control channel failure is an event on which applications
> are interested in from various prospective. E.g., we would like to distinguish between signalling channel failure and control channel failure during RSVP-TE recovery process, etc.
> 
> > - why does control channel management need to be fast ?
> 
> A note on the frequency of LMP Hellos: Please note that we need to distinguish between a signaling channel failure and the control channel failure. 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.
> 
> > - is control channel management fast ?
> 
> I think the LMP Hello frequency need to follow the above mentioned criteria. By fast, do you mean O(milliseconds)? If yes, I don't think LMP Hellos need to be "fast".
> 
> > 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?
> 
> > One of the advantages of using a general purpose IP network is
> > that there is no need for a point-to-point direct communication
> > channel between sender and destination. point-to-point direct
> > communication can become a problem, e.g. when the dataLink is a
> > VC-12 or a VT-1.5.
> >
> > Moreover, control channel management seems to give unnecessary
> > overhead in case there is only one interface between two
> > neighbouring switches.
> 
> IMO when control channels are interface bound (i.e., failure of the interface means failure in the control channel) and L2 mechanism are available to for failure detection, we can run LMP Hellos at a lower frequency and rely on L2 control channel failure detection. But please note that this is not
> always the case that your control channel are bound to a particular interface (e.g., IP routed control channels), hence the need for failure detection within the scope of LMP.
> 
> > Just for my curiosity: has MultiLink-PPP (RFC1990) been considered
> > as alternative for "control channel management" ? This seems to
> > logically extend the current stack used for IP over DCN. From
> > ITU-T G.7712: "When carrying only IP over the DCC, PPPinHDLC
> > framing shall be used as the data-link layer protocol."
> >
> >
> > Regards,
> >
> > Michiel
> >
> > ...<snip>...