RE: Proposed response to the Liaison Statement on LMP Link Verifi cation

-----Original Message-----
From: Razdan, Rajender [mailto:RRazdan@ciena.com]
Sent: Thursday, April 24, 2003 7:44 AM
To: John Drake; 'George Newsome'; Brungard, Deborah A, ALABS
Cc: Stephen Trowbridge; Jonathan.Lang@RinconNetworks.com; 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 Verifi cation

I don't think anyone out here is stipulating that deployment of
GMPLS is gated by the deployment of G.7714.1. Your suggestion below
amounts to saying that we will use the LMP discovery trace byte
pattern for discovery purposes in GMPLS and change to G.7714.1
pattern when dealing with systems where G.7714.1 is deployed. But
that is precisely what I'm arguing against the need for doing. As
I said in one of my earlier emails, it would seem common-sense to
avoid having to support two different message formats, especially
if it can be avoided.

So let me re-paraphrase my original question, which I have yet to
see anyone answer: Is there anything about the G.7714.1 discovery
trace message that makes it unsuitable for your discovery protocol
within LMP? If not, I don't see what problem there is in changing
the LMP trace message format to match that of G.7714.1. It seems
to me that an earnest attempt to match these formats has already
been undertaken in the LMP bootstrap draft document. So what then
is the problem with doing the same for the LMP trace draft document?

-----Original Message-----
From: John Drake [mailto:jdrake@calient.net]
Sent: Thursday, April 24, 2003 9:50 AM
To: 'George Newsome'; Brungard, Deborah A, ALABS
Cc: Stephen Trowbridge; Jonathan.Lang@RinconNetworks.com;
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
Verifi cation

The LMP test procedure is used to exchange GMPLS control plane identifiers
in support of
subsequent RSVP-TE signalling and it will be needed in networks that don't
support G.7714.1,
such as legacy SDH/SONET networks. I.e., I don't think one can stipulate
that deployment
of GMPLS is gated by the deployment of G.7714.1.

It should also be noted that if the trace correlation transport mechanism is
used in a
network in which G.7714.1 is deployed, then G.7714.1 will be supported
transparently; i.e.,
the G.7714.1 bit pattern will be used as the correlating bit pattern.

> -----Original Message-----
> From: George Newsome [mailto:gnewsome@ieee.org]
> Sent: Wednesday, April 23, 2003 9:24 AM
> To: Brungard, Deborah A, ALABS
> Cc: Stephen Trowbridge; Jonathan.Lang@RinconNetworks.com;
> 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
> Verification
>
>
> Deborah,
>
> I've snipped the earlier stuff to reduce the length of this thread.
>
> Brungard, Deborah A, ALABS wrote:
>
> > I support the liaison response as proposed by Jonathan. It may be
> > helpful to add further clarification on the lmp-test format choice.
> > - suggest instead of saying "not restricted to printable characters"
> > which implies a choice of character/format, say "LMP needs
> to support
> > use of various types of control plane identifiers and control plane
> > information, this information is not restricted to the use
> of printable
> > characters. In addition, the LMP message structures can not
> be supported
>
>
> Had you forgotten that G.7714.1 also supports various
> identifiers, and
> those identifiers are also not restricted to the printable set. Its
> coding that creates the printable set. LMP messages can also
> be passed
> as printable chars after coding.
>
> It would help if you were clear about which messages and why. What I
> read is just another statement that says that LMP is different.
>
>
> > by the G7714.1 format". And on the use of a format distinguishing
> > character, "LMP uses a prior negotiation before use, the
> in-band is not
> > used in parallel with other Jx applications. The
> correlation procedure
> > will be used."
> >
>
> This is not a reason that LMP must be different - just a
> statement that
> it is.
>
>
> > There seems to be three discussion threads (all related to
> lmp-test):
> > - confusion on lmp-test and G7714.1 as providing procedures for the
> > "same purpose"
>
>
> Its really hard for me to see how the purpose of the inband
> message is
> different, even if the whole application is subtly different.
>
>
> > We discussed this both in T1X1 and ITU-T Q14. Both the T1X1 liaison
> > and the ITU-T Q14 liaison clearly identify the two procedures as
> > different applications. And the ITU-T Q14 liaison states
> "The control
> > plane protocol specific format is outside of the scope of
> G.7714.1. We
> > invite IETF to propose the message format suitable to exchange these
> > information elements." I don't view this thread of discussion as
>
>
> You will recall that this was NOT about the Jx inband messages, but
> about the out of band exchanges that take place after the inband
> exchanges. This has nothing to do with our current discussion
> about the
> Jx bytes and the use of a single format for those few messages.
>
>
> > impacting the liaison. Suggest continuing this discussion
> on transport
> > plane discovery vs. control plane discovery on the ITU exploders as
> > Q12/Q14 have already identified a related work item.
> > - confusion on why the G7714.1 format can not be used for lmp-test
>
>
>
> > See my above suggestion. And note, many of today's management
> > interfaces (Corba) are not constrained by TL1/printability.
> Performance,
> > etc need to be considered.
>
>
> It is very unfortuanate that you didn't bring this up at the
> proper time
> in Q14. The fact is that all the information needed is able
> to be passed
> in the printable set, and you agreed to it together with the
> rest of us.
>
>
> > - equipment functionality/configurations/impact on legacy
> > Again, this was identified in the T1X1 liaison. It doesn't impact
> > lmp-test (if we model the scope of lmp-test as similar to
> G7714.1, which
> > also does not address these topics). Suggest moving this
> discussion to
> > the ITU exploders (discussion on G7714.1 equipment impacts
> just kicked
> > off this morning).
> >
> > And I could not resist some comments (refer to db below), though I
> > will move on to the ITU exploder to continue ;-)
>
>
> Regards
>
> George
>
>
>
>