RE: Question on LMP.

[Jonathan Lang <jplang@calient.net>]

Michiel,

<snip>
> 
> If "control channels" are nothing more than the standard "ping" mechanism,
> why not use this standard "ping" mechanism ?
> If "control channels" does provide more than standard "ping", could you
> please let me know what that would be (and why that would be mandatorily
> needed) ?
standard "ping" only tells you reachability. It does not tell you if the LMP
component is functioning or not. This is similar to why Hellos are used in
other protocols (e.g., RSVP Hello).

Thanks,
Jonathan


> 
> I think I first need clarity on the relation between "control 
> network" and
> "control channel" before being able to comment on your other points.
> 
> 
> Thanks !
> 
> Michiel
> 
> 
> 
> 
> Zafar Ali wrote:
> > 
> > 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
> > >
> 
> <...snip...>
>