[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summary of LMP implementation/deployment reports
(Sorry if this is a duplicate, my response did not go to the list...)
Dimitri -
This message is in regards your previous message.
Dimitri.Papadimitriou@alcatel.be wrote:
>
> jonathan,
>
> > 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).
>
> the bootstrap message definition when transported over J0:
> " The first usable bit is used to identify the type of
> Interface Id: if set, the Interface Id is numbered (IPv4);
> if clear, the Interface Id is unnumbered. The next usable 32
> bits MUST be the Interface Id. The next usable 32 bits MUST
> be the Node Id. The next usable bit is used to identify the
> type of Control Address: if set, the Interface Id is
> numbered (IPv4); if clear, the Control Address is
> unnumbered. The next usable 32 bits MUST be the Control
> Address. The remaining bits are Reserved. "
>
> the test message definition when transported over J0:
> " The first usable 8 bits are used to determine the address
> type of the Interface_Id. For IPv4, this value is 1. For
> unnumbered, this value is 3. 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."
Thanks for quoting the text I already had read. As stated, there is no
mechanism to distinguish the two messages from each other autonomously.
> thus the second message includes a VERIFY_ID that the
> first one (the bootstrap one) does not contain - moreover
> the first one indicates the Node Id (as requested by a
> bootstrap mechanism) - note: it is also clear that if
> you have a prior BeginVerify/BeginVerifyAck negotiation
> you expect a Test message pattern to be received (thus
> one has a consistency check mechanisms: thus, first do i
> recognize the "pattern" sent and then correlation w/
> the information exchanged (if any) through the control
> plane
Actually, I didn't see any specific text that stated it is assumed that
the state machines on both endpoints of a direction of communication
were synchronized. Unfortunately, there are half duplex miswiring
situations where that will not be a safe assumption. As an example, if
you have three nodes/ports A, B, and C that are miswired with A xmit
connected B rcv, and B xmit -> C rcv, then A sending out a control
channel bootstrap will cause an A-B control channel, but the test
messages intended to go B->A will instead go to C. Since C has not
received any control channel messages stating there is a Verification in
process, it will interpret it as a Bootstrap message as there is no way
to determine from the message what type of message was sent...
> in brief you have the following cases:
> Data plane Prior exchange at Control Plane
> -----------------------------------------------------
> - Test message <-> BeginVerify exchange
> - Bootstrap message <-> nothing (having initiated the
> exchange of the Bootstrap message)
>
> i think this respond to the question you have asked (at
> least as far as i understood it) - if yes then is there
> an issue with the current way the content of the above
> mentioned i-d describes this ?
As stated above, the mechanism needs to allow the two message types to
be distinguished without presuming the state of the receiver. The text
does not provide for it.
> thanks,
> - dimitri.
>
> Jonathan Sadler wrote:
> >
> > 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
> > ============================================================
============================================================
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
============================================================