[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LMP & neighbor discovery
Hello Jonathan,
> LMP provides discovery of the physical layer. For in-band signaling, LMP
> provides both control plane and physical layer discovery. Working Group has
> already accepted this.
Thanks for the explanation.
Could you then please elaborate a bit more on the following part of your email
in http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00606.html
----
> How do you start this link Verification procedure ? The 'beginVerify' message
> seems to assume that the neighbor is already known.
Sending the BeginVerify assumes you know where to send control messages.
This is separate from discovering the data interfaces. This is why using the
term Neighbor Discovery can often be confusing. You actually have discovery
at various levels. G.7714 talks about this in a little more detail.
>
> Please note that I'm discussing initial discovery. I don't question the use
> of subsequent test messages verifying the connectivity.
Noted.
----
You seem to want to use the verification procedure for initial neighbor discovery.
However, it is still unclear to me how you can start this verification procedure.
Moreover, in my mind, the verification procedure is not applicable to all dataLink
types. See http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html
Best regards,
Michiel
Jonathan Lang wrote:
>
> Michiel,
>
> > -----Original Message-----
> > From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com]
> > Sent: Sunday, April 21, 2002 11:00 PM
> > To: Jonathan Lang
> > Cc: 'ccamp@ops.ietf.org'
> > Subject: Re: LMP & neighbor discovery
> >
> >
> > Hello Jonathan, all,
> >
> > Does "<snip>" imply that you are not interested in specifying initial
> > neighbor discovery ? Is this accepted by this working group ?
> LMP provides discovery of the physical layer. For in-band signaling, LMP
> provides both control plane and physical layer discovery. Working Group has
> already accepted this.
>
> <snip> was used to get to what I thought were your main issues.
>
> Thanks,
> Jonathan
>
> >
> > Somehow I think that would be a pity. My impression is that it would
> > have been quite easy to copy the text from
> > http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html
> > in an additional section in the LMP draft.
> >
> > Please let me know if you think I left a question on this text
> > unanswered.
> >
> >
> > Thanks,
> >
> > Michiel
> >
> > P.S. Jonathan: I will try to answer your question on the
> > control channel
> > in the thread "Question on LMP".
> >
> > Jonathan Lang wrote:
> > >
> > > Michiel,
> > >
> > > <snip>
> > > >
> > > > Repeating my earlier questions:
> > > > - Why is 'control channel management' mandatory ?
> > > > - Why are normal (i.e. not LMP specific) network layer
> > mechanisms not
> > > > sufficient ?
> > > Why do you think they are sufficient?
> > >
> > > Thanks,
> > > Jonathan
> > >
> > > <...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 |
> > +------------------------------------------------------------------+
> >