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

["Brungard, Deborah A, ALABS" <dbrungard@att.com>]

Hi Jonathan,

You missed most of the discussion, one can not take vacations from the ccamp exploder;-)

I had recommended focusing on the liaison response, and re-focusing the other discussion to other threads. Example, most of the email exchange is focused on understanding G7714.1 and LMP. There's a ccamp draft on this: draft-aboulmagd-ccamp-transort-lmp. As the draft has not generated any comments on the list, it's surprising the amount of discussion.

The liaison from T1X1 asked:
2. Determination of whether it would be possible to use the identical message formats in the subject draft as in G.7714.1 for the connectivity verification function.  
3. Determination of whether it would be possible to use the same overall structure (distinguishing character, 4 bit message type, 80 bit message body) if a different message format or information content is required.

The answer from the LMP authors:
As the LMP message content is control information, use of printable characters is not an appropriate requirement and it is an inappropriate constraint. And the LMP messages can not use the G7714.1 structure. This answer is not simply a statement, it is a rationale for the choices. We do not require Corba to use printable messages, is that considered a "statement" or a choice? Ask your Corba developers.

To support a liaison response in a timely manner, let's focus on specific wording changes. I still have not seen any suggested wording changes on the liaison response as proposed.

And discussion on the equipment implementation should be on the Q9 exploder.

Deborah (t1x15 hatless)

-----Original Message-----
From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com]
Sent: Friday, April 25, 2003 11: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.

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


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