Re: LMP & neighbor discovery

[Kireeti Kompella <kireeti@juniper.net>]

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.