[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed response to the Liaison Statement on LMP Link Verifi cation
- To: John Drake <email@example.com>
- Subject: Re: Proposed response to the Liaison Statement on LMP Link Verifi cation
- From: Jonathan Sadler <firstname.lastname@example.org>
- Date: Mon, 28 Apr 2003 17:08:17 -0500
- Cc: "Brungard, Deborah A, ALABS" <email@example.com>, Stephen Trowbridge <firstname.lastname@example.org>, Jonathan.Lang@RinconNetworks.com, George Newsome <email@example.com>, Dimitri.Papadimitriou@alcatel.be, "Wijnen, Bert (Bert)" <firstname.lastname@example.org>, email@example.com, Kireeti@juniper.net, "Ron Bonica (E-mail)" <Ronald.P.Bonica@wcom.com>, firstname.lastname@example.org
- References: <H0000c0806d9644b.1051537414.mailw02@MHS>
John Drake wrote:
> Jonathan Sadler wrote:
> > John Drake wrote:
> > >> The liaison from T1X1 asked if it is necessary for two totally
> > >> independent message formats to exist for the in-band case as the
> > >> function being performed by both G.7714.1 and the Jx Test Message
> > >> Connetivity Verification approach defined in lmp-test-sonet-sdh is
> > >> the same.
> > >>
> > > JD: I don't think that is correct. The LMP Test procedure is used
> > > to exchange the GMPLS identifiers for a given data link. Since the
> > > GMPLS identifiers may not be globally unique, it is necessary to
> > > qualify them with a Verify ID, which identifies the particular Test
> > > procedure the identifiers are associated with. G.7714.1 is used to
> > > exchange the transport level identifiers for a given link.
> > G.7714.1 shows that the exchange of control plane identifiers (e.g.
> > GMPLS TE-Link IDs) is done as a part of service capability exchange
> > process which comes after the neighbor has been discovered. This was
> > separated from the neighbor discovery mechanism to allow the neighbor
> > discovery function to be used by things other than the control plane
> > (i.e. management systems).
> > It should be noted that Appendix III of G.7714.1 suggests a way to use
> > LMP's trace correlation mechanism to accomplish this, which then
> > dovetails into the rest of LMPs processes.
> JD: Your original statement, to which I responded, was: "as the function
> being performed by both G.7714.1 and the Jx Test Message Connetivity Veri-
> fication approach defined in lmp-test-sonet-sdh is the same." What you're
> now saying is that there is a neighbor discovery piece to G.7714.1 which
> has no equivalent in the LMP Test procedures, followed by the LMP Test pro-
> cedure using the trace correlation tranport mechanism.
I tend to look things from a functional decomposition perspective, and not at
the specific bits/bytes.
The goal being sought is:
- determination that a link exists
- determination that it is not miswired
- exchange of control plane names for the endpoints of that link
Two in-band methods exist that accomplish this goal for a SONET/SDH link. They
G.7714.1 (including Appendix III)
Both methods describe message formats that intrusively use the Jx strings.
While the formats are different, the function accomplished is identical.
> So, in spite of what the G.7714.1 proponents have been saying, there doesn't
> appear to be any functional overlap between the neighbor discovery piece
> of G.7714.1 and the LMP Test Procedure.
Not certain how you can say this given the above.
The fact that G.7714.1 took into account that neighbor discovery can be used in
the absence of the control plane, and therefore uses transport plane identifiers
in the Jx message format, doesn't change its functional equivalence when it is
used to support the control plane.
And if you don't want to maintain a control-plane namespace separate from the
transport-plane namespace, G.7714.1 does not proclude the namespace mapping
function being as simple as:
f(x) = x
> > >> Only the in-band issue needs to be discussed.
> > >>
> > >> Jonathan Sadler
> > >>
> > >> PS. I couldn't help but respond to Deborah's attempt to clarify:
> > >>
> > >> "Brungard, Deborah A, ALABS" wrote:
> > >> > db: Note, to clarify, G7714.1 requires all new G7714.1-aware
> > >> > transport equipment, both terminations and intermediate
> > >> equipment.
> > >>
> > >> This is untrue. The G.7714.1 formats are consistant with the
> > >> capability required in G.707, making hardware changes unnecessary.
> > >> The design of the message format was done with remoting of the
> > >> Discovery Agent in mind -- allowing for non-G.7714.1-aware
> > transport
> > >> equipment to be a part of an overall system that does indeed use
> > >> G.7714.1 formats.
> > >>
> > >
> > > JD: I saw an e-mail yesterday from Maarten Vissers yesterday sent
> > > to one of the T1X1 mailing lists indicating the exact opposite. I
> > > have asked him to re-post it here.
> > >
> > I am aware of the e-mail that you are referencing.
> > If you read the message completely, you will find that he was actually
> > challenging the statement in the liaison from T1X1.5 which says
> > equipment changes will be necessary to support G.7714.1
> > methods. He goes
> > on to state that the G.7714.1 process can attach (via an "application
> > switch") to the MI_TxTI interface (which is an Equipment Mangement
> > Function (EMF) to hardware interface) to send the G.7714.1
> > message, and
> > attach to the MI_AcTI signal to monitor for incoming G.7714.1
> > messages.
> > Of course this switch is only necessary if the TTI being monitored (by
> > the NIM) is using a non-G.7714.1 (i.e. G.831/T1.269) format message.
> > (For those interested in deciphering this alphabet soup, you can find
> > definitions in G.7710, G.798 and G.806.)
> JD: I read it differently, but I will leave it to you folks figure out
> how to try and make G.7714.1 actually work.
In the spirit of the IETF -- running code does exist. And it didn't require any
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.