[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question on LMP
hi michiel, all,
i will respond to this one because i think some clarification
would be useful:
---
2. Is there a mandatory need to distinguish between a failure of
the RSVP-TE process and a failure of the LMP process ?
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00670.html
You wrote:
> 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).
I'm not sure why we need *both* RSVP-TE Hellos as well as LMP hellos.
See also question 2 above.
---
Yes, we need to maintain both for the following reasons
you can run rsvp-te w/o lmp, lmp w/o rsvp or both (lmp
and rsvp), in the latter case there is a need to have a
clear distinction between a lmp controller failure or
signalling controller failure; as such you can see the
global picture as follows:
- LMP maintains control plane adjacencies by sending LMP
Hello's on Control Channels implemented on top of a
given control network topology
- RSVP-TE maintains signalling plane adjacencies by
sending RSVP Hello's on signalling channels that can
be the same as the above Control Channels
but also
- OSPF maintain routing adjcencies by sending OSPF Hello's
on routing channels that can be the same as the above
Control Channels
The important point is when these Control Channels have a
common usage, the LMP Hello's can be seen as enabling a
dynamic setup and maintenance of the control plane channels
through which all the other LMP modules (link property
correlation, for instance) as well as the routing and
signalling protocols can exchange information. However,
these lmp hello's do not maintain the liveness of the
peering ospf and rsvp-te instances.
Some comments in-line...
hope this clarifies,
- dimitri.
Michiel van Everdingen wrote:
>
> Hello Jonathan,
>
> Could you please make clear in the LMP draft that
> 1. "control channels" are established *over* a "control network".
> 2. Not all signaling messages (example: the RSVP-TE notify
> message) are sent over "control channels".
i let this editorial task to jonathan (just a hint a standard
indicates what it does and not what it doesn't)
> If this could be added in the LMP draft, I would not have become
> confused on the relation between "control channels" and
> "control network".
>
> Examples of text in the LMP draft that caused my confusion:
>
> - Chapter 1: "To enable communication between nodes for routing,
> signaling, and link management, control channels must be
> established between the node pair ..."
> Why the "must" in this sentence ? I would think that
> communication is perfectly well possible over the "control
> network", not using "control channels" ?
it is clear (at least from my point of view) if one except
out of band ip control networks (in such a case one can for
instance consider ip tunnels implementing these control
channels), nothing tells in this sentence that these channels
must be the same; however it is rather obvious that having a
"common" control channel topology brings high benefits.
> - Chapter 2: "One or more active control channels may be grouped
> into a logical control channel for signaling, routing, and
> link property correlation purposes."
> This sentence seems to go in the direction of a kind of multi-
> link PPP protocol (L2). At least it made me believe that the
> control network is built on top of control channels - a thought
> that apparently is wrong.
i would see it as "control channel on top of a control network"
> - Chapter 2: "... the control channel MUST terminate on the same
> two nodes that the TE link spans"
> I could only understand this sentence assuming "control channels"
> are a kind of L2 technique. What does "terminate" in this
> sentence imply ? Is something more happening than the standard
> TCP/UDP termination to packets that are sent over control channels?
it simply says you send the TE Link information using the control
channel between nodes defining this TE Link
> - Chapter 3: "The LMP Hello protocol is intended to be a lightweight
> keep-alive mechanism that will react to control channel failures
> rapidly so that IGP Hellos are not lost and the associated link-
> state adjacencies are not removed unnecessarily."
see above.
> Again, I could only understand this sentence assuming "control
> channels" are a kind of L2 technique. Is it possible to be more
> precise on what "IGP" is meant here (see also
> http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00657.html).
>
> Could you please also indicate that "control channel management" does
> *not* need to be fast (O(mseconds)) ?
> See http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00700.html.
it would be contradicory with the usage defined here above.
> Looking back through this thread, I think at least the following
> two questions are still open:
>
> 1. What does the control channel management achieve?
> a. IP reachability confirmation.
i don't understand what you mean here, please clarify
> b. Negotiation of Hello and Dead intervals.
this negotiation is part of the control channel
configuration so ... seems clear.
> http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00653.html
>
> 2. Is there a mandatory need to distinguish between a failure of
> the RSVP-TE process and a failure of the LMP process ?
> http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00670.html
see above.
> You wrote:
> > 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).
>
> I'm not sure why we need *both* RSVP-TE Hellos as well as LMP hellos. See
> also question 2 above.
>
> Thanks,
>
> Michiel
>
> Jonathan Lang wrote:
> >
> > 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
>
> <snip>
>
> --
> +------------------------------------------------------------------+
> | 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 |
> +------------------------------------------------------------------+
--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
Address: Alcatel - Optical NA, Fr. Wellesplein, 1
B-2018 Antwerpen, Belgium
Phone: Work: +32 3 2408491 - Home: +32 2 3434361