[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summary of LMP implementation/deployment reports
Hi Dimitri,
is neighbor discovery in the scope of LMP? I
suppose that it is.
With Nbr discovery I'm referring to the scenario where a TNE is attached
to, say 4, TNEs and doesn't know to which of these TNE its TEs are attached
to.
Where is this discovery procedure described in the ID?
This seems to me one of the major advantages of LMP (for sure more
important than fault management which in the transport network is well
covered by inherent Sonet/SDH capabilities) so a specific section that
addresses neighbor discovery is needed, of course IMHO.
Some time ago I posted a mail on this topic, here is the reference:
http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00979.html
Again from my point of view a section that describes in detail this feature
is needed in the ID.
Best regards,
Diego.
Dimitri.Papadimitriou@alcatel.be@ops.ietf.org on 03/09/2002 22.06.43
Sent by: owner-ccamp@ops.ietf.org
To: Carmine Daloia <daloia@lucent.com>
cc: Kireeti Kompella <kireeti@juniper.net>, Nik Langrind
<nik@equipecom.com>, "Ccamp-wg (E-mail)" <ccamp@ops.ietf.org>
Subject: Re: Summary of LMP implementation/deployment reports
carmine,
just to be sure here we are on the same level of understanding
the bootstrap information that the receiver learn is the equivalent
of the one that you would normally provision, i refer you to the
following sentence of the Section 3 (of draft-ietf-ccamp-lmp-05.txt):
"To establish a control channel, the destination IP address on the
far end of the control channel must be known. This knowledge may be
manually configured or automatically discovered."
and then you follow the procedure as described in this i-d (in
fact the bootstrap i-d also completes the second alternative of
the above sentence).
hope this clarifies,
- dimitri.
Carmine Daloia wrote:
>
> Dimitri,
>
> Thanks for the explanation for why it is left as a separate document.
>
> I disagree with one point. You say that the bootstrap process would not
> cause anything in the lmp draft to be modified.
>
> Once the controll address of the neighbor is learned via the bootstrap
> process, I don't see the purpose for Control Channel Management
Procedure.
>
> A link summary message can be sent directly to the controll address
> learned via the bootstrap process. Therefore I would have expected the
> Control Channel Management Procedure to be removed completely or at
> least made optional.
>
> Carmine
>
> Dimitri.Papadimitriou@alcatel.be wrote:
>
> >carmine,
> >
> >1) this has been proposed in order to keep going with content
> >that has been discussed since more than two years now (and has
> >not been modified by the below mentioned document),
> >
> >2) since the result of the process (and the information it allows
> >to discover) is at the end the same than the one obtained when
> >applying the test message procedure no subsequent mechanisms
> >are modified by the bootstrap approach
> >
> >3) moreover, the bootstrap mechanisms have been identified (this
> >from the mailing list discussions) to be useful (up to now) for
> >sonet/sdh or more generally for "optical" environments only.
> >
> >thus i think this may justify the (good imho) idea to have two
> >separate documents (it results from the above points to be thus
> >also justified from an implementation viewpoint)
> >
> >thanks,
> >- dimitri.
> >
> >Carmine Daloia wrote:
> >
> >
> >>Why is the procedure described in the lmp-bootstrap draft not included
> >>in the lmp-draft? Doesn't sound like lmp is complete without this
> >>capability and therefore doesn't seem to make sense to have these in
> >>separate drafts.
> >>
> >>Carmine
> >>
> >>Dimitri.Papadimitriou@alcatel.be wrote:
> >>
> >>
> >>
> >>>Carmine,
> >>>
> >>>this is why i have previously mentioned in my response
> >>>that "a proposal has been made to bootstrap out-of-band
> >>>control channels and discover the interface_id mappings
> >>>(or associations) before establishing a control channel"
> >>>
> >>>see:
>
>>>http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
> >>>
> >>>thus the problem you've indicated in the below message is
> >>>also addressed -
> >>>
> >>>so
> >>>" So LMP can *build* the mappings (i.e., reduce
> >>>
> >>>
> >>>
> >>>
> >>>>operator provisioning) if the operator has previously provisioned the
> >>>>remote node addresses for each and every data link. "
> >>>>
> >>>>
> >>>>
> >>>>
> >>>may be now rephrased as
> >>>" LMP can *build* the mappings (i.e., reduce operator provisioning)
> >>>
> >>>
> >>>
> >>>
> >>>>without any provisioning of the remote node addresses for each
> >>>>and every data link"
> >>>>
> >>>>
> >>>>
> >>>>
> >>>thanks,
> >>>- dimitri.
> >>>
> >>>Carmine Daloia wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Kireeti, Dimitri,
> >>>>
> >>>>I realize that Section 5 in draft-ietf-ccamp-lmp-05.txt states that
the
> >>>>Link Connectivity Verification procedure (which is optional) may be
used
> >>>>to dynamically learn the id associations. Is this what you mean by
LMP
> >>>>being able to *build* the mappings? However this requires that an
> >>>>operator *PROVISION* for each and every data link the remote node
> >>>>address that the data link is terminated on. Only with this
> >>>>provisioning will the local node know the address to send the
> >>>>BeginVerify message to. So LMP can *build* the mappings (i.e.,
reduce
> >>>>operator provisioning) if the operator has previously provisioned the
> >>>>remote node addresses for each and every data link. Doesn't seem
like a
> >>>>useful capability.
> >>>>
> >>>>Carmine
> >>>>
> >>>>Kireeti Kompella wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Hi Carmine,
> >>>>>
> >>>>>On Tue, 3 Sep 2002, Carmine Daloia wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>So basically LMP is used to verify that the datalink id mappings
stored
> >>>>>>in the neighboring nodes match eachother.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>Actually, LMP is used to *build* the mappings, not verify them. If
the
> >>>>>mappings were already stored, LMP could be used to verify them --
but
> >>>>>that is a secondary function.
> >>>>>
> >>>>>Kireeti (as a WG participant).
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Alcatel - Optical NA (CTO), Fr. Wellesplein, 1
B-2018 Antwerpen, Belgium
Phone: Work: +32 3 2408491 - Home: +32 2 3434361