[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: LMP & neighbor discovery
Michiel,
Neighbor discovery, through use of appropriate control channel management (see Section 3 and 9), is supported with the current LMP draft. There is no need for any extension to the draft for this purpose.
Regards,
Martin
-----Original Message-----
From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com]
Sent: Thursday, May 30, 2002 7:31 AM
To: Kireeti Kompella
Cc: ccamp@ops.ietf.org
Subject: Re: LMP & neighbor discovery
Hello Kireeti,
Thanks for your answer.
> Reading over the threads again, it appears that "neighbor discovery"
> may be a useful function.
Agreed. Non manual, fully automatic "neighbor discovery" is an important
requirement as also stated in ITU-T G.7714.1.
Including neighbor discovery in LMP would also remove the confusion
that currently appears to exist on whether or not LMP does specify
neighbor discovery. In
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00774.html
Jonathan seems to state that LMP *does* include neighbor discovery.
However, this type of neighbor discovery is rather manual and not
in line with ITU-T G.7714.1.
> However, LMP is a *link* management protocol,
> where neighbors are configured (at least as a starting point), and
> *links* are discovered, and link properties correlated.
I guess you are here referring to TE-links as opposed to dataLinks ?
The proposed addition to LMP discovers dataLinks. I don't see it as
a problem that subsequent link property correlation groups all
dataLinks together and correlates the full TE-link in one IP message.
Compared to correlating individual dataLinks, correlating a full
TE-link has advantages performance wise.
Why do you see it as a problem that the described neighbor discovery
procedure discovers the neighbor on an individual dataLink ? For
example, the existing LMP function "Fault Management" is built on
discovering the faults on individual dataLinks.
> My suggestion (as co-chair) is that LMP proceed as is, and if folks
> think that neighbor management is a useful function, then they can
> write a draft, perhaps building on LMP, and we'll judge WG interest
> in this function.
As you might have noted, my neighbor discovery proposal does *not*
include a *single* IP message. It is simply making use of an existing
function in the transport layer: reading the access point identifier.
In my mind, it would therefore be strange to write a separate ID to
define this neighbor discovery function.
Moreover, this new ID would indeed be heavily building on LMP to provide
the subsequent link correlation.
Could you please let me know what you see as advantages of defining
neighbor discovery in a separate ID ?
> To my mind (as implementor), the notion of control channel seems simple
> enough; a control network is one instantiation of a control channel.
This statement seems to be in conflict with an earlier statement that
a "control channel" runs on top of an existing "control network" (it
is a "routed control channel").
Related to your assessment of "control channels" being simple: did you
include in that assessment the need to carefully provision the timers
related to RSVP-TE hellos, LMP control channel hellos and the "control
network" IGP hellos ?
You might want to re-read
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html
> > If this proposal is not in line with your view, I'm looking forward
> > to a continued discussion on the three indicated email threads !
>
> Excellent idea! As I said, if there is interest, the best way to proceed
> is to follow up with an ID.
In my mind there are two ways to proceed:
1. Don't accept the proposed changes in LMP.
2. Accept the proposed changes in LMP.
If option (1) is chosen, I would at least like to have within the LMP
draft:
- Clarification on "control channel" (thread "Question on LMP")
- Clarification on when the link verification procedure is
applicable (thread "applicability of LMP's verify procedure")
- Clarification on whether or not LMP includes neighbor
discovery.
Of course my preference would be option (2).
Best regards,
Michiel
Kireeti Kompella wrote:
>
> On Thu, 23 May 2002, Michiel van Everdingen wrote:
>
> > Hello Jonathan, Kireeti, Ron,
> >
> > Judging on the information in three e-mail threads (first and last email
> > indicated):
> > - Question on LMP
> > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00590.html
> > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00735.html
> > - LMP & neighbor discovery
> > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html
> > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00800.html
> > - applicability of LMP's verify procedure
> > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html
> > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html
> >
> > I would propose to make the following modifications to the LMP draft,
> > version 03:
> > - Include a section on neighbor discovery
> > Details can be found in
> > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html
>
> Reading over the threads again, it appears that "neighbor discovery"
> may be a useful function. However, LMP is a *link* management protocol,
> where neighbors are configured (at least as a starting point), and
> *links* are discovered, and link properties correlated.
>
> My suggestion (as co-chair) is that LMP proceed as is, and if folks
> think that neighbor management is a useful function, then they can
> write a draft, perhaps building on LMP, and we'll judge WG interest
> in this function.
>
> > - Remove the concept of "control channel" and accept that signalling
> > messages are carried over the "control network".
>
> To my mind (as implementor), the notion of control channel seems simple
> enough; a control network is one instantiation of a control channel.
>
> > If this proposal is not in line with your view, I'm looking forward
> > to a continued discussion on the three indicated email threads !
>
> Excellent idea! As I said, if there is interest, the best way to proceed
> is to follow up with an ID.
>
> Kireeti.
--
+------------------------------------------------------------------+
| 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 |
+------------------------------------------------------------------+