Re: Question on LMP.

[Zafar Ali <zali@cisco.com>]

Hi Michiel, 

Thanks for the summary; please see comments in-lined. 

Thanks

Regards... Zafar 

At 12:10 PM 4/26/2002 +0200, Michiel van Everdingen wrote:
> Hello Zafar,
>
> Please allow me to summarize my understanding of our discussion 
> thus
> far.
>
> LMP's "control channel management"
>
> - Is an extra, new protocol on top of an existing IP
> network.

Agreed! 

>   That is what I understand when Jonathan
> writes "You could certainly
>   create an LMP control channel through a DCN network. In fact,
> this
>   is probably the preferred configuration."
>  
> http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00588.html
>
> - Needs careful setting of hello frequency.
>   This is based on your comment: "LMP Hellos should be faster
> than RSVP
>   Hellos or the mechanism used to detect signalling 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."
>  
> http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00655.html

Agreed! 


> - Provide a fast recovering transport
> mechanism for "signalling channels"
>  
> http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00670.html

I would like to reword this as, LMP provides a mean for detecting control
channel failures between LMP neighbors. These control channels are used
by signaling and other control entities. 

> Furthermore, there is a need to route packets
> through a network consisting
> of "signalling channels": 

I would it to be simply referred as the control network, instead of
network consisting of "signaling channels". 

> the RSVP-TE "notify
> message" is sent between
> non-adjacent (at transmission plane) nodes in case it is
> "encapsulated
> in a new IP header whose destination is equal to the target IP
> address."
> [RSVP-TE, section 4.3]

The notify message with the above mentioned option is also sent over the
control network, like other signaling messages.  I did not see the
relationship here. Can you please elaborate a bit further why you are
mentioning this here? 



> So in other words, the proposal
> is to create an extra "network layer"
> (OSI terminology) consisting of "signalling channels". These
> "signalling
> channels" make use of underlying "control channels" which
> again can make
> use of any generic network layer (e.g. DCN). Correct
> ?

No, I don't think so. Just because we've a peer to peer protocol for
detecting health of the control channels, IMO, does not mean that we've
introduced an extra "network layer". Control network is still
managed like any other (IP) network.  


> I agree with you that we need to
> carefully look at the "hello" frequencies
> of these network layers. Probably some consideration is also needed
> for
> hello-timers on datalink layer and hold-off timers at transport
> layer.

I did not understand which hold off timers you're referring to here?, and
what is the relationship of some timers at the "transport
layer" with the operation of control network? 


> All together, my feeling is that
> this is getting quite complex.
>
> Are we sure we want to go in this direction ? Can't we simply 
> remove
> the whole "control channel management" mechanism and define
> "control
> channel" as follows:
>   control channel = a facility that interconnects two switching
> neighbours
>   at the transmission plane for the purpose of exchanging control
> messages.
>   This facility can be in-band or out-of-band; point-to-point or
> multi-point.
> If we would accept this definition, a DCN network (or better: SCN
> network)
> can be an implementation to have control channels between all
> neighbouring
> nodes at the transmission plane.

I am not is a position to comment on this. However, I would like to
reiterate a couple of points. First, I thought that much of the LMP draft
is already agreed upon and is close to become an RFC, so I am not sure
the value of this discussion at this stage. Secondly, I don't think there
were convincing enough arguments to go in that direction. 


> If we have to go on discussing
> "control channel management", I think we
> still have the following open questions:
> - why does control channel management need to be
> fast

No, I don't think that control channel management need to be
fast (O(mseconds)). I think this will be a comment to the authors of the
draft to clarify this point in the draft and remove the related text from
it. 

> - is control channel management
> fast.

No, IMO, it only need to satisfy that requirements that I pointed out
earlier in,
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00655.html



> On your email:
>
> > I don't see if we can cover all cases of control channel failure
> detection
> > after removing this functionality from LMP (e.g., the case of routed
> control
> > channels or control channels where L2 failure detection is not
> feasible).
>
> Hopefully someone on this mailing list can show us a case in which a
> standard
> IP network is not sufficient for the control plane...
>
>
> > LMP will be using UDP, as indicated in an earlier email from
> Jonathan.
>
> Sorry, I was not aware of this. I just joined the list 3 weeks ago to ask
> if
> we could add neighbour discovery in LMP and to get clarity on the use
> of
> "control channel management". Guess I was somewhat naive to
> think that that
> could easily be settled....
>
>
> > > Indeed. In some cases L2 detects the failure, in other cases L3
> detects
> > > the failure. Still confused as to why we can't stick to
> standard L3
> > > mechanisms to detect the failure...
> > 
> > Can you please elaborate on what "other" L3 mechanisms
> you're referring to
> > here? How would you cover the case of an IP routed control
> channel?
>
> I did not speak about "other" L3 mechanisms. Just standard L3
> mechanisms.

Such mechanism runs on physical links in the control network. However,
when we've a routed control channel, these mechanisms do not help us.



> > I think the WG has already
> agreed upon the control channel management
> > procedure within the scope of LMP. I am not sure what is the value
> of
> > this discussion at this point. I'll let some one else comment on
> it.
>
> Personally, I found our discussion very useful. Thanks for the
> to-the-point
> answers !

Likewise, it has been a pleasure exchanging ideas with you :-) 

Thanks... 

Regards.... Zafar 



> Best regards,
>
> Michiel
>
>
> Zafar Ali wrote:
> > 
> > Hi Michiel:
> > 
> > Please see comments in-lined.
> > 
> > Thanks
> > 
> > Regards... Zafar
> > 
> > At 02:56 PM 4/25/2002 +0200, Michiel van Everdingen wrote:
> > 
> > > Hello Zafar,
> > >
> > >
> > > > > 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;-)
> > >
> > > As control channel management is a mandatory part of LMP, I
> would define
> > > "sufficient" as "minimally needed to run
> LMP" or maybe "minimally needed
> > > to run GMPLS".
> > 
> > I don't see if we can cover all cases of control channel failure
> detection after removing this functionality from LMP (e.g., the case of
> routed control channels or control channels where L2 failure detection is
> not feasible). Please note that control channel failure detection is
> currently a
> > requirement for the GMPLS framework, which is already agreed upon,
> AFAIK.
> > 
> > > > 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.
> > >
> > > I guess control messages will use either TCP, UDP or IP.
> Correct ?
> > 
> > LMP will be using UDP, as indicated in an earlier email from
> Jonathan.
> > 
> > > In case of TCP, I'm assuming TCP's connection establishment
> phase takes
> > > care that the neighbour is listening.
> > >
> > > In case the control messages are sent using UDP or IP, I agree
> that the
> > > application has to make sure that the neighbour is listening.
> For the
> > > LMP control messages this seems no problem as they are
> acknowledged
> > > anyway by LMP (e.g. linkSummaryAck for the linkSummary
> message). The
> > > application can then simply resent the message until it
> receives a
> > > '(N)Ack'.
> > 
> > Yes, also this is because LMP does not assume a reliable transport
> for the control traffic (over the control channel).
> > 
> > > > 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.
> > >
> > > Indeed. In some cases L2 detects the failure, in other cases L3
> detects
> > > the failure. Still confused as to why we can't stick to
> standard L3
> > > mechanisms to detect the failure...
> > 
> > Can you please elaborate on what "other" L3 mechanisms
> you're referring to here? How would you cover the case of an IP routed
> control channel?
> > 
> > > > 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.
> > >
> > > See above.
> > > For inter operability reasons, we could specify which mechanism
> has
> > > to be used as a minimum (e.g. I-ISIS ?). Additional
> mechanisms
> > > (like MPLS protection, ML-PPP, ...) are then optional.
> > >
> > >
> > > > 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.
> > >
> > > Thanks for the definitions !
> > >
> > > Just to check: a signalling channel failure is different from a
> nodal
> > > failure. A nodal failure implies a signalling channel failure,
> but not
> > > the other way around. Correct ?
> > 
> > Yes, failure of a peering signaling process also leads to signaling
> channel failure.
> > But, the actions taken in the restart procedure are the same, for
> the obvious reasons.
> > 
> > > In these definitions, how would an RSVP-TE "notify
> message" be sent
> > > between non-adjacent (at transmission plane) nodes in case it
> is
> > > "encapsulated in a new IP header whose destination is
> equal to
> > > the target IP address." [RSVP-TE, section 4.3] ? Is it
> routed
> > > over a series of signalling channels ? By which routing
> protocol ?
> > >
> > >
> > > > 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?
> > >
> > > My proposal would be to use non-GMPLS specific mechanisms to
> route
> > > control packets to the intended destination.
> > >
> > >
> > > > 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.
> > >
> > > Could we agree that the whole "control channel
> management" mechanism
> > > is only for faster recovery of the control plane ? The idea
> would be
> > > that failure of one control channel does not change the
> topology of
> > > the control plane as the associated signalling channel does not
> get
> > > affected.
> > >
> > > If we could agree on this understanding, I would still opt for
> non-
> > > GMPLS specific mechanisms.
> > 
> > I think the WG has already agreed upon the control channel
> management procedure within the scope of LMP. I am not sure what is the
> value of this discussion at this point. I'll let some one else comment on
> it.
> > 
> > <snip>
> > ===============
> > Zafar Ali
> > Cisco Systems
> > (734) 276-2459
> > 100 S Main St. #200
> > Ann Arbor, MI 48104.
> > email: zali@cisco.com
>
> -- 
> +------------------------------------------------------------------+
> | 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.
email: zali@cisco.com