Re: Question on LMP.

[Zafar Ali <zali@cisco.com>]

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

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