[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summary of LMP implementation/deployment reports
Dimitri,
Following what you said, are you also proposing we should take technology
specific stuff from the current LMP draft? Then I agree with you.
Thanks,
Yangguang
Dimitri.Papadimitriou@alcatel.be wrote:
>
> maarten, diego,
>
> the question of diego is "... a section that describes in
> detail this feature (dixit neighbor discovery) is needed
> in the ID." and the response is such description should
> be imho in an applicability statement i-d (describing the
> use of the lmp features), neighbor discovery as proposed
> in your response is focusing on "sdh/sonet" environments
> while as discussed many times lmp targeted more and the
> community implements more - this is also clear from the
> results of the implementation/deployment reports - i refer
> you to the e-mail of kireeti (for more on hourglass):
>
> http://psg.com/lists/ccamp/ccamp.2002/msg01005.html
>
> further a dedicated i-d will address the specifics of
> "sdh/sonet" environments that's from a practical viewpoint
> the best way to proceed in order to keep a consistent/
> modular approach while for the bootstrap i-d the valuable
> comments as received since so far will also be addressed
> - thus since so far all this should address the main
> concerns of our community -
>
> note also that in general such applicability i-d starts
> when most of the protocol details are known.
>
> your last point is also interesting - ditto:
> "> PS. as there seems to be no willingness to address Michiel/Greg's
> proposal in
> > ccamp (is this a correct conclusion of the email correspondence so far), it
> > seems waste of time for all to continue this discussion over here. Let's
> > concentrate this work in Q.14/15 and include it in G.7714."
>
> first our community does not stricto sensu address proposals
> (or i-ds) but consented items and corresponding solutions/
> mechanisms in several levels of documents - the document is
> a way to achieve interoperable running code not the ultimate
> final goal in itself.
>
> but then:
> > The market then must decide between LMP and G.7714."
>
> the response is imho related to last question in the greg's
> e-mail (http://psg.com/lists/ccamp/ccamp.2002/msg01092.html):
>
> "> (c) Of the implementations that Bert listed, how many were being used
> just
> > for OIF UNI 1.0 discovery (SONET/SDH) interoperability rather than general
> > LMP?"
>
> well the response is indicated in the bert's report:
>
> "One implementation was O-UNI version of LMP, so does not do
> all the things described in current LMP draft."
>
> but i also think that it means more, it means that the ccamp
> community majority is implementing the complete protocol and
> not only its set of functions for sonet/sdh in a oif uni
> context -> therefore may we not expect here the same kind of
> response in the ason context (debate is open) what are the
> rationale for a vendor to implement a version of lmp per
> environment ? what will happen when this protocol will be
> used in multi-service devices ? imho a practical view on
> this problem gives many responses and insight for the future
> but in any case i am not sure that some parts of you post-
> scriptum are really in-line with the way of thinking of our
> community (which i don't think targets any competition)
>
> thanks
> - dimitri.
>
> Maarten Vissers wrote:
> >
> > Diego,
> >
> > Michiel and Greg proposed text for such section on neighbor discovery in his lmp
> > update draft
> > http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp-update-00.txt
> > Refer to section 3 in this contribution.
> >
> > This proposal allows neighbor discovery at the
> > - STM-N level,
> > - STS/HOVC level,
> > - VT/LOVC level.
> >
> > I.e it can be used to discover:
> > - STM-N TTP - TTP neighbors (e.g. two SDH eq connected via DWDM system)
> > - STM-N CTP - TTP neighbors
> > - STM-N CTP - CTP neighbors
> > Note - STM-N CTP is located in a pre-OTN transparent optical cross
> > connect (do they still exist these days? :-( ), and in an
> > OTN ODUk equipment's STM-N trib port interface.
> >
> > - STS/HOVC TTP - TTP neighbors (e.g. two routers with STM-N interfaces
> > connected via non-ASON/GMPLS SDH/SONET network)
> > - STS/HOVC CTP - TTP neighbors (e.g. router with STM-N interface and SDH ADM)
> > - STS/HOVC CTP - CTP neighbors (e.g. two SDH HO ADMs/DXCs)
> >
> > - VT/LOVC TTP - TTP neighbors
> > - VT/LOVC CTP - TTP neighbors
> > - VT/LOVC CTP - CTP neighbors (e.g. two SDH LO ADMs/DXCs)
> >
> > It can be used for neighbor discovery in
> > - (simple) link (G.805: link connection) cases and
> > - serial-compound link (G.805: link connection) cases.
> >
> > This particularly important for the roll out of ASON/GMPLS networks. In this
> > phase there will be many non-ASON/GMPLS SDH/SONET networks which will
> > interconnect ASON/GMPLS subnetworks. If a set of STS/HOVC [VT/LOVC] connections
> > is set up through such non-ASON/GMPLS SDH/SONET network as a (serial-compound)
> > link bundle (G.805: (serial-compound) link), then the ASON/GMPLS neighbors are
> > the last network element in the first ASON/GMPLS subnetwork and the first
> > network element in the second ASON/GMPLS subnetwork. The non-ASON/GMPLS
> > SDH/SONET network is now simply a part of the "data link" between these two
> > network elements.
> >
> > The ASON/GMPLS SDH/SONET network elements are also "transparent devices" (in the
> > sense of LMP section 5, par. 4) that do not "modify or examine data in normal
> > operation". As such, the the last sentence in the text in par. 5 of section 5 is
> > not correct.
> >
> > LMP, v0.5, section 5, par. 5: "Furthermore, for the link
> > verification procedure it is assumed that the nodal
> > architecture is designed so that messages can be sent and
> > received over any data link. Note that this requirement is
> > trivial for opaque devices since each data link is electrically
> > terminated and processed before being forwarded to the next
> > opaque device, but that in transparent devices this is an
> > additional requirement."
> >
> > A SDH/SONET cross connect or ADM seems to be such "opaque device", but doesn't
> > terminate the STS/HOVC or VT/LOVC "data link" that exists between the two
> > ASON/GMPLS neighbors.
> >
> > Michiel and Greg's proposal support automatic discovery between two neighbor
> > nodes that are either at the end of the same fiber, or at the end of different
> > fibers (and have one or more "transparent devices" between these fibers).
> >
> > Regards,
> >
> > Maarten
> > PS. as there seems to be no willingness to address Michiel/Greg's proposal in
> > ccamp (is this a correct conclusion of the email correspondence so far), it
> > seems waste of time for all to continue this discussion over here. Let's
> > concentrate this work in Q.14/15 and include it in G.7714. The market then must
> > decide between LMP and G.7714.
> >
> > Diego Caviglia wrote:
> > >
> > > 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).
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>
> > > > >>>
> > > > >>>