[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: LMP & neighbor discovery
Martin, I thought the latest LMP draft is very clear concerning LMP
functionality.
Link verification is included. This assumes a control channel has already
been established between the nodes. The definition of "discovery" that
we've been working with (and also in G.7714) has the equipment automatically
discovering its neighbor without any control channel configuration.
We added/modified to LMP in the OIF UNI to give it discovery functionality
in the SONET/SDH case. LMP per the draft does not include this
functionality.
The main problem I still see with LMP is that it claims to be applicable to
a wide variety of technologies when in fact it is aimed at PXCs. For
example, its fault management capabilities are much slower and less reliable
than those in either SDH/SONET or G.709 which use extremely fast dedicated
mechanisms such as AIS and RDI signals for fault isolation and use other
measures of signal degradation rather than just "loss of light" (LOL).
Most routers with optical interfaces should be able to support the basic
SONET/SDH Section or line layer AIS/RDI signals and fault detection
capabilities (such as section layer LOF). It seems the need for most of LMP
really comes from the lack of capabilities of the current crop of PXCs.
Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Technology Director, Ciena Corporation
-----Original Message-----
From: Martin Dubuc [mailto:Martin.Dubuc@meriton.com]
Sent: Thursday, May 30, 2002 6:41 AM
To: Michiel van Everdingen; Kireeti Kompella
Cc: ccamp@ops.ietf.org
Subject: 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 |
+------------------------------------------------------------------+