[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Summary of LMP implementation/deployment reports
Maarten,
You might also want to look at
http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt.
Thanks,
Jonathan
> -----Original Message-----
> From: Maarten Vissers [mailto:mvissers@lucent.com]
> Sent: Wednesday, September 04, 2002 2:34 AM
> 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
>