[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Summary of LMP implementation/deployment reports
Jonathan,
<snip>
>
> I am aware of
> http://www.ietf.org/internet-drafts/draft-lang-ccamp-lmp-boots
> trap-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.
>
Thanks for pointing this out. We've updated the text to address the
Test/Bootstrap message ambiguity in the special case where normal LMP
Test/Bootstrap messages can't be used due to byte limitations.
The new text for the 0x01 J0-16 Test message reads:
"The Test message (i.e., the string inserted into the frame) is a 15-byte
message, where the 7 most significant bits (msb) of each byte are usable.
Due to the byte limitation, the LMP Header is not included.
The first usable 4 bits are reserved. These bits MUST be sent as zero and
ignored on receipt. The next usable 2 bits are used to identify the message
type. For the Test message, this value is 0. The next usable bit is used
to determine the address type of the Interface_Id. For IPv4, this value is
0. For unnumbered, this value is 1. The next usable 32 bits MUST be the
Interface_Id. The next usable 32 bits MUST be the Verify_Id that was
received in the VERIFY_ID object of the BeginVerifyAck message. The
remaining bits are reserved and should be sent as zero and ignored on
receipt.
Note that this Test Message format is only valid when the Interface_Id is
either IPv4 or unnumbered."
The Bootstrap message has also been updated and will be identified will a
value of 1.
Thanks,
Jonathan
> 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-boots
> trap-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
> ============================================================
>