[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Summary of LMP implementation/deployment reports
I was specifically referring to the stuff that Maarten was
listing, which (I guess) all seem to be sonet/sdh things?
Thanks,
Bert
> -----Original Message-----
> From: Diego Caviglia [mailto:Diego.Caviglia@marconi.com]
> Sent: woensdag 4 september 2002 14:01
> To: bwijnen@lucent.com
> Cc: Maarten Vissers <mvissers; ccamp@ops.ietf.org
> Subject: RE: Summary of LMP implementation/deployment reports
>
>
>
> Hi Bert,
> could you please point out where in my
> e-mail there was a
> technology specific reference (apart from the sentence in brackets)?
>
> Best regards,
>
> Diego
>
>
>
>
>
> "Wijnen, Bert (Bert)" <bwijnen@lucent.com> on 04/09/2002 13.43.21
>
> To: Maarten Vissers <mvissers@lucent.com>, Diego Caviglia
> <Diego.Caviglia@marconi.com>
> cc: "Dimitri.Papadimitriou"
> <Dimitri.Papadimitriou@alcatel.be>, "Carmine
> Daloia <daloia" <daloia@lucent.com>, "Kireeti Kompella <kireeti"
> <kireeti@juniper.net>, "Nik Langrind <nik"
> <nik@equipecom.com>, "
> Ccamp-wg (E-mail) <ccamp" <ccamp@ops.ietf.org>
>
> Subject: RE: Summary of LMP implementation/deployment reports
>
>
> Guys... I have already strongly suggested that any technology specific
> stuff goes in a separate doc. Still need to check if and how this
> has been teken care of in the new revision.
>
> But if any of the technology specific stuff listed below were to be
> accepted by the WG, I think it should be in a separate technology
> specific document, and NOT in the COMMON CONTROL LMP document.
>
> And if this is optical technology specific, does it then belong in
> in CCAMP, or even in IETF or is it something to be done in another
> WG or in another organisation?
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Maarten Vissers [mailto:mvissers@lucent.com]
> > Sent: woensdag 4 september 2002 11:34
> > To: Diego Caviglia
> > Cc: Dimitri.Papadimitriou; Carmine Daloia <daloia; Kireeti Kompella
> > <kireeti; Nik Langrind <nik; Ccamp-wg (E-mail) <ccamp
> > Subject: Re: Summary of LMP implementation/deployment reports
> >
> >
> > 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-bo
> > otstrap-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
> >
>
>
>
>