[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summary of LMP implementation/deployment reports
Dimitri -
The first part of this message pertains to section 5
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-05.txt.
As stated, section 5 requires a BeginVerify to be sent after a control
channel is set up. Consequently, it is not possible to use the Test
messages as the basis of setting up a control channel.
Since a control channel requires explicit identification of the peer
controller, there is no "discovery" going on.
An alternate approach, which is included in G.7714, is that the in-band
messages (eg. the LMP test messages) should contain the controller ID
allowing the controller to be identified, and therefore seed the control
channel setup.
I am aware of
http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-bootstrap-00.txt
doing something similar to what G.7714 states, but unfortuantely no
information has been provided on how to distinguish between the
bootstrap and test messages when transported over certain bearers (ie.
J0).
Please provide insight.
Jonathan Sadler
Dimitri.Papadimitriou@alcatel.be wrote:
>
> hi,
>
> imho i think it would be good if people discussing specific
> i-ds on this mailing list could point out to the section of
> the document providing the feature they speak about (or the
> sections that does not contain it and that should ideally
> do) but at least be more accurate about a specific item under
> discussion (now that a terminology section has been delivered
> in the last revision of the lmp i-d following this terminology
> may help in achieving progress - but also clear understanding
> of the mail discussions - by the ccamp community)
>
> but let's take an example from the below e-mail:
>
> > So basically LMP is used to verify that the datalink id mappings stored
> > in the neighboring nodes match eachother.
>
> see Section 5 of
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lmp-05.txt
>
> in brief these mappings are "discovered" (link verification is
> much more than just a consistency check mechanism)
>
> > This type of capability would make more sense to be part of the protocol
> > that provided autodiscovery (i.e., discovered the datalink id mappings).
>
> thus the response to this question becomes clear (i think) and in
> addition 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
>
> > In my opinion, it is the ability to autodiscover the id mappings that is
> > more useful than just verifying at a later time if the mappings still match.
>
> well from the structure of the BeginVerify/BeginVerifyAck Message
> as described in section 12.5 of draft-ietf-ccamp-lmp-05.txt, we
> also see that the REMOTE_LINK_ID is an optional object such that
> both features listed here above are supported
>
> the Test message sent in-band being defined as in Section 12.5.6
> consistency is also provided by this protocol
>
> > Since LMP doesn't support autodiscovery, it doesn't seem to be useful
> > for LMP to check whether the mappings match or not. This check can be
> > done via the autodiscovery protocol itself.
>
> from the above discussion i think that LMP supports what you call
> "auto-discovery" and (if the previous statement is true) we may
> ask ourself to which protocol do you refer here and what's the
> relevance of the content of this statement ?
>
> thanks,
> - dimitri.
>
> Carmine Daloia wrote:
> >
> > Nik,
> >
> > Thanks for the clarification.
> >
> > So basically LMP is used to verify that the datalink id mappings stored
> > in the neighboring nodes match eachother.
> >
> > This type of capability would make more sense to be part of the protocol
> > that provided autodiscovery (i.e., discovered the datalink id mappings).
> > After autodiscovery completes and the id mappings are stored, the
> > protocol can subsequently verify whether the mappings stored in the
> > neighboring nodes match eachother.
> >
> > In my opinion, it is the ability to autodiscover the id mappings that is
> > more useful than just verifying at a later time if the mappings still match.
> >
> > Since LMP doesn't support autodiscovery, it doesn't seem to be useful
> > for LMP to check whether the mappings match or not. This check can be
> > done via the autodiscovery protocol itself.
> >
> > Carmine
> >
> > Nik Langrind wrote:
> >
> > >Carmine,
> > >
> > >Yes, auto-configure is an ill-chosen term. Let me rephrase:
> > >
> > >As I understand it, the reason is to allow two systems to exchange
> > >identifiers of their mutual TE links and the component datalinks of those TE
> > >links.
> > >
> > >Nik
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: Carmine Daloia [mailto:daloia@lucent.com]
> > >>Sent: Tuesday, September 03, 2002 11:55 AM
> > >>To: Nik Langrind
> > >>Cc: 'Zhi-Wei Lin'; Ccamp-wg (E-mail)
> > >>Subject: Re: Summary of LMP implementation/deployment reports
> > >>
> > >>
> > >>Nik,
> > >>
> > >>What is meant by auto-configure?
> > >>
> > >>Thanks
> > >>Carmine
> > >>
> > >>Nik Langrind wrote:
> > >>
> > >>
> > >>
> > >>>Hi Zhi,
> > >>>
> > >>>I don't think that gaps in SONET/SDH fault management are
> > >>>
> > >>>
> > >>the reason for
> > >>
> > >>
> > >>>implementing LMP on SONET/SDH systems. As I understand it,
> > >>>
> > >>>
> > >>the reason is to
> > >>
> > >>
> > >>>allow two systems to auto-configure the component datalinks
> > >>>
> > >>>
> > >>of their mutual
> > >>
> > >>
> > >>>TE link.
> > >>>
> > >>>Nik
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>-----Original Message-----
> > >>>>From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> > >>>>Sent: Thursday, August 29, 2002 10:55 AM
> > >>>>To: Wijnen, Bert (Bert)
> > >>>>Cc: Ccamp-wg (E-mail)
> > >>>>Subject: Re: Summary of LMP implementation/deployment reports
> > >>>>
> > >>>>
> > >>>>Hi Bert,
> > >>>>
> > >>>>This is really illuminating. We've been discussing LMP and
> > >>>>scope of LMP,
> > >>>>and from what I gather (maybe I've misinterpreted or
> > >>>>misunderstood what
> > >>>>people say) was that LMP was supposed to be targetting pre-OTN
> > >>>>equipment, not SONET/SDH equipment since SONET/SDH already
> > >>>>has quite a
> > >>>>set of OAM capabilities that were much better (or at very least
> > >>>>comparable) to LMP (and they've been around more many many years)...
> > >>>>
> > >>>>So I guess I like to ask people who's doing LMP for SONET/SDH
> > >>>>what are
> > >>>>the gaps they see in existing SONET/SDH fault management (as
> > >>>>defined in
> > >>>>G.783) that LMP is supposed to fill?
> > >>>>
> > >>>>Thanks for any additional insights.
> > >>>>
> > >>>>Zhi
> > >>>>
> > >>>>
> > >>>>Wijnen, Bert (Bert) wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>Here is the summary of the reports I have received.
> > >>>>>
> > >>>>>The questions to be answered were:
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>Type: vendor/carrier
> > >>>>>>Company: (to weed out duplicates)
> > >>>>>>Interest level in LMP:
> > >>>>>> For vendors: opposed/yawn/interested/implementing/released
> > >>>>>> For carriers: useless/yawn/useful/testing/deploying/deployed
> > >>>>>> used with technology: ethernet/sonet/sdh/atm/fr/xx
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>Type: Equipment TestEquip or Carrier ISP
> > >>>>> Vendor SourceVendor
> > >>>>>
> > >>>>>Responses: 10 2 2 1
> > >>>>>
> > >>>>>Interest level:
> > >>>>>Released 2 2
> > >>>>>Implementing 6
> > >>>>>yawn 1 1
> > >>>>>testing 2
> > >>>>>(very)usefull 1
> > >>>>>
> > >>>>>Technologies (not split by type)
> > >>>>>SONET - SONET/SDH 10
> > >>>>>Ethernet GigE 5
> > >>>>>ATM 2
> > >>>>>MPLS 1
> > >>>>>PXC 1
> > >>>>>(D)WDM 2
> > >>>>>Fiber 1
> > >>>>>Transparent 1
> > >>>>>Sonet DCC 1
> > >>>>>POS 1
> > >>>>>OTN 1
> > >>>>>Lambda 1
> > >>>>>Port Switching 1
> > >>>>>
> > >>>>>The sourceVendor claimed to have 10 customers, 5 were named.
> > >>>>>One implementation was O-UNI version of LMP, so does not do
> > >>>>>all the things described in current LMP draft.
> > >>>>>
> > >>>>>All in all quite a set if "implementations underway".
> > >>>>>
> > >>>>>Would have been good to see some more responses from
> > >>>>>
> > >>>>>
> > >>Carriers or ISPs
> > >>
> > >>
> > >>>>>Feel free to send your continued responses and I will try to keep
> > >>>>>the list up to date.
> > >>>>>
> > >>>>>Bert
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, or an
employee or agent responsible for delivering this message to
the intended recipient, you are hereby notified that any
reproduction, dissemination or distribution of this
communication is strictly prohibited. If you have received
this communication in error, please notify us immediately by
replying to the message and deleting it from your computer.
Thank you.
Tellabs
============================================================