Re: Question on LMP.

[Zafar Ali <zali@cisco.com>]

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.



> Best regards,
>
> Michiel
<snip>
===============
Zafar Ali
Cisco Systems
(734) 276-2459
100 S Main St. #200
Ann Arbor, MI 48104.
email: zali@cisco.com