[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LMP & neighbor discovery
as said before OIF UNI and LMP per draft do not fundamentally
differ from this "discovery" perspective - i invite you to re-
read section 8.5.8 and 8.5.9 of this specification both are
related to the Config/Ack/Nack message exchange - while link
verification (per definition) relies on these (or this)
previous exchange(s) except if ipcc is already available.
if the corresponding "mechanism" (we speak then upon link
discovery) was possible without the Config message exchange
then the requirement of G.7714 would have been achieved (i.e.
independence of the "control channel" signalling transport
mechanism and (neighbor) link discovery) that G.7714 has
implicitly translated to a dependence (i should say a glue)
between the "transport" and "discovery", this is the reason
why some people on this mailing list come always with the
terminology of itu-t functional specifications; thus the only
thing to allude from this perspective, is to define the "glue"
in LMP between the discovery function and the transmission
technology to which it applies; therefore i suggest rather
to clarify the glue for each of these technologies in other
specific as we did for signalling for instance.
- dimitri.
"Bernstein, Greg" wrote:
>
> 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 |
> +------------------------------------------------------------------+
--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
Address: Alcatel - Optical NA, Fr. Wellesplein, 1
B-2018 Antwerpen, Belgium
Phone: Work: +32 3 2408491 - Home: +32 2 3434361