[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summary of LMP implementation/deployment reports
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).
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>
> > > >>>
> > > >>>