[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Summary of LMP implementation/deployment reports
Maarten...I think the URL you gave is wrong....I believe it should be this:
http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp-update-00.txt
regards, Neil
> -----Original Message-----
> From: Maarten Vissers [mailto:mvissers@lucent.com]
> Sent: 04 September 2002 14:05
> To: Wijnen, Bert
> Cc: ccamp
> Subject: Re: Summary of LMP implementation/deployment reports
>
>
> Bert,
>
> The technology specific part of the proposed neighbor
> discovery is the bandwidth
> selected to transport the neighbor discovery message defined
> in section 3 of
> http://www.ietf.org/internet-drafts/draft-everdingen-ccamp-lmp
> -00.txt.
> I.e. the proposal suggests to use as bandwidth the SDH
> overhead bytes J0 (STM-N
> link), J1 (STS/HOVC link), J2 (VT/LOVC link).
>
> The discovery method and message itself are generic and can
> be applied to
> multiple technologies.
> E.g. for an OTN ODUk link one could use as bandwidth the
> bytes 32-63 in the ODUk
> TTI overhead.
>
> Regards,
>
> Maarten
>
>
> Wijnen, Bert (Bert)" wrote:
> >
> > 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
> > >
>