[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
>