[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed response to the Liaison Statement on LMP Link Verification
- To: "'Brungard, Deborah A, ALABS'" <dbrungard@att.com>, Stephen Trowbridge <sjtrowbridge@lucent.com>, Jonathan.Lang@RinconNetworks.com
- Subject: RE: Proposed response to the Liaison Statement on LMP Link Verification
- From: John Drake <jdrake@calient.net>
- Date: Wed, 23 Apr 2003 08:03:40 -0700
- Cc: George Newsome <gnewsome@ieee.org>, Dimitri.Papadimitriou@alcatel.be, "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, ccamp@ops.ietf.org, Kireeti@juniper.net, "Ron Bonica (E-mail)" <Ronald.P.Bonica@wcom.com>, zinin@psg.com
Snipped ...
> - To what extent do we wish to deploy this kind of technology over
> existing SONET/SDH networks? I think that many operators
> are interested
> in deploying ASON/GMPLS technology over a portion of the capacity of
> their existing transport networks. As a result, it is useful to look
> at what is required for "peaceful coexistance" of this
> technology with
> other traffic. This is what has motivated in G.7714.1 to use the
> "distinguishing character" so that various termination and
> NIM functions
> can tell the difference between a message used for
> discovery/connectivity
> verification and a normal trace identifier. I am not convinced by
> arguments such as "you will never see these in the same network" or
> "the specific scenario is such that the wrong TT function or NIM
> function will never see this message". You can never quite tell how
> someone will connect things or use a particular feature,
> and it seems
> like a far more robust approach to choose a format where it
> is always
> possible to distinguish between the various possible uses
> of the same
> bytes.
>
> db: Note, to clarify, G7714.1 requires all new G7714.1-aware
> transport equipment, both terminations and intermediate
> equipment. And for operators, "turning-off" of legacy
> intermediate NIMs is not an option (proposed in G7714.1), as
> the investment in intermediate NIMs is not for 24/7
> entertainment of our field staff. G7714.1 does not
> "peacefully coexist". One ITU operator suggested using a
> different byte than Jx based on this concern with G7714.1.
> Whereas, LMP requires GMPLS-aware transport equipment. And
> LMP provides two options depending on support by legacy
> equipment (in-band, correlation). For either G7714.1 or GMPLS
> LMP, an operator chooses equipment configurations/options
> based on their application. New applications/new equipment
> (no free lunch;-)). No different from today's operations. And
> the two options (in-band, correlated) provided by LMP support
> two different use scenarios, including use of legacy NIMs. As
> discussed for G7714.1, Q9 needs to evaluate the equipment
> support scenarios.
> ---end of comment---
>
JD: I just wanted to second Deborah's comment. The LMP test procedure
is used to exchange GMPLS control plane identifiers for the purpose of
LSP signalling. If the trace correlation transport mechanism is used,
the existing SDH/SONET transport plane Jx bit pattern is transported in
the LMP Test procedure messages, i.e., in the GMPLS control plane. This
allows two nodes, node 1 and node 2, to build the following association:
{Node 1's GMPLS ID and Jx bit pattern for link x, Node 2's GMPLS ID and
and Jx bit pattern for link x}
This means that it is 100% compatible with existing SDH/SONET equipment,
which is not a claim that G.7714.1 can make. Note also that this is clearly
spelled out in the draft and has been mentioned in e-mail several times.
Thanks,
John