[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposed response to the Liaison Statement on LMP Link Verification

jonathan,

see in-line...

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.
let's be clear, G.7714.1 can make use of LMP for its out-of-band
response message - but this does not make G.7714.1 a control plane
application (instead of LMP the response can be transported over
TL1 for instance ;-)

also please keep in mind that this is not equivalent to the method described by john here above - you do not have a "verify id" exchange
in this process since you do not negotiate through BeginVerify/Ack the test message exchange

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.

i thought this was what G.7714.1 claimed to deliver from the rigth
beginning ? and now we see this is not the case ? in brief i think
what you say here is that G.7714.1 is not backward compatible with
G.831 ?


(For those interested in deciphering this alphabet soup, you can find
definitions in G.7710, G.798 and G.806.)
once again, this means that the method developed by the itu does
not seem to be ready since in order to avoid the hardware change a "soft-switch" has to be defined

now please keep in mind that the t1x1 liaison "proposes if possible"
and let the door open for the ietf community to select the process
this community think relevant for its control plane applications

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

--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491