RE: Proposed response to the Liaison Statement on LMP Link Verific ation

[John Drake <jdrake@calient.net>]

> -----Original Message-----
> From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com]
> Sent: Friday, April 25, 2003 8:43 PM
> To: John Drake
> Cc: Brungard, Deborah A, ALABS; Stephen Trowbridge;
> Jonathan.Lang@RinconNetworks.com; George Newsome;
> Dimitri.Papadimitriou@alcatel.be; Wijnen, Bert (Bert);
> ccamp@ops.ietf.org; Kireeti@juniper.net; Ron Bonica (E-mail);
> zinin@psg.com
> Subject: Re: Proposed response to the Liaison Statement on LMP Link
> Verific ation
> 
> 
> 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.

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.


> 
> >> 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.


> 
> 
> ============================================================
> 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
> ============================================================
>