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

[Stephen Trowbridge <sjtrowbridge@lucent.com>]

Jonathan,
I think that the following are true:
- Both the lmp-test draft and G.7714.1 perform connectivity discovery and
  verification.
- Both the lmp-test draft and G.7714.1 have chosen scenarios where they will
  use the Jx bytes for this purpose, although they have chosen different
  points in the life cycle where Jx byte messaging is considered appropriate.
While the procedures seem to be executed at different points in time, they
seem to be for the same purpose over the same bytes, which would suggest
that it is worthwhile looking for better alignment rather than having
everybody go their own way.

The words "Green Field" have been tossed about, and I think there are
actually two questions here:
- To what extent to we require new or redesigned equipment to implement
  this functionality? The installed base of SONET/SDH equipment is huge,
  and I think there is a great desire to deploy this kind of technology
  with the most minor possible tweaks to the existing transport equipment.
  I think this desire is behind the suggestions to try to keep the Jx
  format as close as possible to the current formats used for TTIs (e.g.,
  printable characters) and the requests not to define multiple formats
  to be used for the same or similar purposes.
- 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.

Another thing that I think I read between the lines of your response would
be worth spelling out explicitly in the lmp-test draft. The intent is for
pre-service. What I think this means is the following (assuming that this
is correct, the draft should say so):
- For VC-n/m signals, there is never an ACTUAL VC-n/m present. So when you
  use the Jx bytes for discovery/connectivity verification in this context,
  it will be included in a supervisory unequipped signal that is created
  with the Jx bytes inserted with the appropriate message. These messages
  will never be carried in anything except a supervisory unequipped signal.
- For RS-n signals, since there is no "supervisory unequipped" signal that
  is different from an in-service regenerator section, the pre-service state
  is inferred from alarm reporting - either old style "NMON" as per G.783,
  or "NALM" as per M.3100 Amendment 3 Alarm Reporting Control. (This is
  probably as good as can be done for the RS layer - personally, I am not
  very comfortable with this as operators may temporarily turn off alarming
  for all kinds of reasons. Being in an "NMON" or "NALM" state does not
  always mean that there is no customer payload of VC-n/m signals being
  carried, in contrast to a supervisory unequipped signal which will never
  carry a customer payload - in any case, I am not sure what else you can
  do to try to distinguish a "pre-service" state for RS-n signals).

Regards,
Steve

Jonathan Lang wrote:
> 
> George,
>   Please see inline.
> 
> Thanks,
> Jonathan
> 
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org
> > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of George Newsome
> > Sent: Monday, April 21, 2003 12:27 PM
> > To: Dimitri.Papadimitriou@alcatel.be; Jonathan.Lang@RinconNetworks.com
> > Cc: Wijnen, Bert (Bert); ccamp@ops.ietf.org; Deborah Brungard
> > (E-mail); Steve Trowbridge (E-mail); Kireeti@juniper.net;
> > 'Ron Bonica (E-mail)'; zinin@psg.com
> > Subject: Re: Proposed response to the Liaison Statement on
> > LMP Link Verification
> >
> >
> > All,
> >
> > I have a few comments on the proposed response to the Liaison
> > Statement
> > from T1-X1 on LMP Link Verification.
> >
> > It seems to me that the response agrees that the application is the
> > same, verifying the transport connectivity between two
> > points. However
> > no mention is made as to why it is neither possible nor
> > desirable to use
> > the same message format, thereby reducing the amount of
> > variation in the
> > world.
> As I said in my response to Rajender, the intention was to agree the
> "application space" and "scenario of use" are different from what is
> described in the t1x1 liaison.  Where in response did we acknowledge the
> context is the same for g7714.1 and lmp?
> 
> >
> > One unwanted consequence of three Jx formats is equipment burden. Why
> > should equipment be burdened with three variations, when two are quite
> > sufficient? Part of this burden is unnecessary behaviour for equipment
> > to sort out which format is being used, provisioning of the choice, or
> > simply being non interoperable.
> >
> > A single format, which is useful in non green field applications,makes
> > a lot of sense.
> For legacy equipment, the Jx-trace mechanism (defined in LMP) would be
> the easiest to provide the required functionality.  It doesn't modify
> any of the Jx formats from existing deployments.
> 
> >
> > I also have a few specific comments inline.
> >
> > Regards
> >
> >      George Newsome
> >
> >
> > Wijnen, Bert (Bert) wrote:
> >
> > > Thnaks for the proposed response.
> > >
> > > It would be good if people could tell us if they agree or disagree
> > > and if they disagree, then pls explain why.
> > >
> > > If the response is acceptable, then it sounds to me that at least
> > > there would be no impact on the draft-ietf-ccamp-lmp-08.txt
> > > document, which is currently in IETF Last Call. Since we had split
> > > the SONET/SDH material off into a separate document, my initial
> > > evaluation made me think that the draft-ietf-ccamp-lmp-08.txt
> > > would not have any ITU-T/T1X1 issues/concerns. The liason statement
> > > did refer to it a few times and so I started to worry, but from
> > > the (proposed) response it seems there is no isseu.
> > >
> > > Would be good to get at least confimration of that by the end
> > > of the Last Call, and that is April 24th.
> > >
> > > Thanks,
> > > Bert
> > >
> > >
> > >>-----Original Message-----
> > >>From: Jonathan Lang [mailto:Jonathan.Lang@RinconNetworks.com]
> > >>Sent: vrijdag 18 april 2003 22:25
> > >>To: ccamp@ops.ietf.org
> > >>Cc: Kireeti@juniper.net; 'Ron Bonica (E-mail)'; zinin@psg.com;
> > >>bwijnen@lucent.com; Dimitri.Papadimitriou@alcatel.be
> > >>Subject: FW: Proposed response to the Liaison Statement on
> > >>ASON Routing
> > >>
> > >>
> > >>All,
> > >>
> > >>Here's a proposed response to the Liaison Statement from
> > T1-X1 on LMP
> > >>Link Verification, posted April 11, 2003.
> > >>
> > >>Thanks,
> > >>Jonathan & Dimitri
> > >>--------------------------------------------------------------------
> > >>Dear Mr. Biholar,
> > >>
> > >>
> > >>
> > >>>Context of Application Space
> > >>>
> > >><snip>
> > >>
> > >>>It is currently our understanding that the use case
> > >>>scenario for which this procedure is applied encompasses
> > >>>both transport plane connectivity verification as well as
> > >>>correlation of these entities with the control plane.
> > >>>ITU-T G.7714.1 is focused on discovering the transport
> > >>>plane link connection end point relationships and
> > >>>verifying their connectivity.
> > >>>This Recommendation defines two procedures for performing
> > >>>the connectivity verification function, one of which
> > >>>utilizes either the Jx or the DCC bytes of the server
> > >>>signal (termed "in-service"). The other approach in
> > >>>G.7714.1, termed as "out of service", corresponds to
> > >>>inserting a test signal in the payload of the server
> > >>>signal. Based on an analysis of the data link state
> > >>>definitions in draft-ietf-ccamp-lmp-08.txt, we understand
> > >>>that the approach defined in the LMP test for physical
> > >>>connectivity occurs in the context of the "out of service"
> > >>>state (as described in G.7714.1).
> > >>>
> > >>>Please confirm this.
> > >>>
> > >>Yes, this is correct
> > >>
> > >>
> > >>>Usage of Jx Bytes
> > >>>
> > >>>In defining the Jx bytes within G.7714.1, the following
> > >>>was taken into account:
> > >>>1. One consideration involved the case where the Discovery
> > >>>Agent is located in an external system, and an external
> > >>>interface is used by the Network Element to provision and
> > >>>receive the Trail Trace message. As an existing text-
> > >>>oriented Man-Machine Language, such as TL1, may be reused
> > >>>to provide this interface, it was decided that the
> > >>>discovery message be limited to printable characters.
> > >>>Specifically, the TTI characters should be limited to
> > >>>printable characters as per T.50 with trailing NULLs or
> > >>>SPACEs. Use of arbitrary bit patterns in the lower 7 bits
> > >>>of each byte could prematurely terminate the pattern or
> > >>>trigger fault notification for certain hardware or
> > >>>software implementations. The strategy chosen in G.7714.1
> > >>>avoids the danger by limiting the information content of
> > >>>each byte to 6 bits (84 bits total) and uses a base 64
> > >>>coding according to RFC2045 to place the information in
> > >>>the available bits.
> > >>>
> > >> We understand that a general transport plane discovery agent
> application
> > >> such as G.7714.1 may want to limit the format to printable
> > >> characters. However, LMP is a subset of the GMPLS control plane
> > >> where no such constraint exists.  As such, we don't think LMP
> > >> link  verification needs to be constrained to be printable
> > >> characters.
> > >>
> >
> > This does not give any reason as to why LMP could not or should not
> use
> > this limitation. When GMPLS is retrofitted onto todays networks, the
> > same limitation will be there for the same reasons G.7714.1 took
> account
> > of it. LMP may be pre-service, but this is not the same as a green
> field
> > application.
> I see no reason why LMP should have this limitation.  I don't understand
> your comment about "not the same as green field application".  The
> J0-trace mechanism doesn't require any modification to the Jx bytes.
> 
> >
> >
> > >>
> > >>>2. Another consideration involved providing a means for
> > >>>distinguishing this use of the Jx bytes from the
> > >>>traditional use for Trail Trace identifiers in new
> > >>>equipments. As a result, G.7714.1 includes a
> > >>>distinguishing character ("+") as the first non-CRC byte
> > >>>that will never appear as the first character of a TTI.
> > >>>This requires modification of the trail termination
> > >>>functions to prevent the raising of TTI mismatch
> > >>>alarms during the connectivity verification process.
> > >>>
> > >> We understand the need for this distinguishing character for the
> > >> G7714.1 in-service application; however, LMP link
> > verification is designed
> > >> to be used before a link is put in service. It is our understanding
> > >> per G.806 section 6.1, when a TTP is not in service, it is in
> > >> the NMON state (not monitored)."
> > >>
> >
> >
> > Many network elements take the availability of an input signal as a
> > trigger to switch into monitoring mode. However, even for those which
> do
> > not, there does not seem to be a good reason for not using a
> > common format.
> I can think of a couple.  The application space and usage are different.
> 
> >
> >
> > >>
> > >>>While the context for testing the transport plane
> > >>>connectivity is different between the two documents, they
> > >>>both use the Jx bytes of the server signal, and we invite
> > >>>the IETF to determine the appropriateness of the above
> > >>>aspects in their test signal definitions.
> > >>>
> > >>We agree the context is different.  We evaluated the above
> > aspects and
> > >>we don't feel they are appropriate for LMP (see comments above).
> > >>
> >
> >
> > I'm still looking for the rationale that led you to this
> > conclusion.  I only see a statement.
> Please see above.
> 
> >
> > >>
> > >>>Even if these considerations are not relevant to this
> > >>>context, it will be necessary to augment G.783 equipment
> > >>>functions to recognize this new usage of Jx messages.
> > >>>
> > >>We would be happy to provide assistance to T1X1/ITU-T in augmenting
> > >>G.783 equipment functions to recognize the additional capability for
> > >>GMPLS networking elements.
> > >>
> > >>
> > >>>Required Updates to SDH Equipment Specifications
> > >>>
> > >>>SDH equipment specifications as they currently exist reflect
> > >>>the usage of the Jx bytes prior to the development of
> > >>>G.7714.1. ITU-T Study Group 15 has as a work item to
> > >>>revise these equipment functions to include support for
> > >>>these new functions. Specifically, this will involve
> > >>>updates to trail termination functions to generate and
> > >>>receive the new messages and to avoid unnecessary alarms in
> > >>>the case where the new messages are received. In addition,
> > >>>non-intrusive monitoring functions will need to be revised
> > >>>so that unnecessary alarms are not raised when the
> > >>>messages are observed en-route. Whether or not there is
> > >>>further alignment between the message formats used in
> > >>>G.7714.1 and the subject draft, the new functions to
> > >>>support the subject draft will also need to be reflected
> > >>>in the atomic functions in G.783. The sending and
> > >>>receiving of these messages can be reflected in the trail
> > >>>termination functions in a similar way to what we plan to
> > >>>do for support of G.7714.1 functions.
> > >>>
> > >> We understand that G7714.1 is addressing an in-service test
> > >> procedure and needs to be concerned with NIM (and non-support of
> G7714.1
> > >> by legacy NIM). The LMP test procedure is a pre-service
> > >> application. We will be happy to work with T1X1/ITU SG15 to
> > >> augment G.783 to recognize the additional capability for GMPLS
> > >> networking elements.
> >
> >
> > It seems to me that having yet another format to do the same
> > thing, and which cannot be interleaved with normal tracing, is not an
> additional
> > capability, but less capability.
> See above about doing "the same thing."  As far as normal tracing goes,
> see J0-trace mechanism in LMP Link Verification.  It's my understanding
> that G.7714.1 defines a new Jx format which will not work with existing
> hardware and normal tracing.
> 
> >
> > >>
> > >>>Terminology Differences
> > >>>
> > >><snip>
> > >>
> > >>>Based upon draft-ietf-ccamp-lmp-08.txt, Section 11.3.1,
> > >>>the "up/free (in-service)" data link state appears to
> > >>>correspond with what G.7714.1 refers to as "out-of-
> > >>>service".  This difference in terminology has resulted in
> > >>>different interpretations of the context.  Explaining the
> > >>>scenarios further in the lmp test document would be
> > >>>beneficial in establishing a translation between the
> > >>>differing uses of the same terms.  Within ITU-T, work is
> > >>>being initiated of draft Rec. G.fame, Framework for ASON
> > >>>Management, where control plane/management plane
> > >>>interactions will be addressed.
> > >>>
> > >> We agree that terminology differences between IETF and ITU wrt
> > >> GMPLS have been confusing. There is an ongoing effort within
> > >> CCAMP to work together with ITU/T1X1 on bridging the terminology
> > >> gaps. For example, there is a new Internet draft
> > (draft-aboulmagd-ccamp-transport-lmp-00.txt)
> > >> being considered in CCAMP to do this mapping for LMP.
> > >>
> > >>>Further Study Items
> > >>>
> > >>>Following are some areas where further contributions are
> > >>>requested:
> > >>>1. For SDH equipment functions in G.783, it needs to
> > >>>be understood whether the application of the lmp test
> > >>>message requires revision of NIM (non-intrusive
> > >>>monitoring) functions. The reason for this is that the
> > >>>test procedure is initiated between control entities at
> > >>>the end-points of the trail, and intermediate points are
> > >>>not necessarily aware that the test is taking place. For
> > >>>G.7714.1, it was felt important for any termination or NIM
> > >>>function to easily distinguish between the various uses of
> > >>>the Jx bytes. It may be necessary for the subject draft
> > >>>to use a similarly easily recognizable format. If no
> > >>>revision to NIM functions is required for the context of
> > >>>this draft, the architecture of the context for this
> > >>>application (demonstrating why the NIM functions are not
> > >>>required) should be reflected in G.803 and/or G.807/G.8080.
> > >>>
> > >> We understand that G7714.1 is addressing an in-service test
> > >> procedure and needs to be concerned with NIM (and non-support of
> G7714.1
> > >> by legacy NIM). The LMP test procedure is a pre-service
> > >> application. Can you clarify how "pre-service"
> > >> applications impact G.803/G.807/G.8080? If we
> > >> can provide assistance in updating these Recommendations to
> > >> reflect LMP applications, please let us know.
> > >>
> > >> G.803/G.807/G.8080? If we can provide assistance in updating
> > >> these Recommendations to reflect LMP applications, please let us
> > >> know.
> > >>
> > >>>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.
> > >>>
> > >>We have evaluated the current formats in G.7714.1 and we believe are
> > >>inappropriate for the usage of LMP.
> > >>
> >
> >
> > Some rationale for this belief would be most useful.
> See above.
> 
> >
> >
> > >>
> > >>>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.
> > >>>
> > >>As mentioned above, we believe the overall message structure and
> > >>constraints are inappropriate for LMP.
> > >>
> >
> >
> > I don't see answers to the above questions re technical feasibility,
> and
> > belief is not a reason for not using the same format in the interests
> of
> > reducing variation.
> See above.
> 
> >
> > >>
> > >>>4.Work is needed to clarify under what
> > >>>configurations/states (for example: no VC-n signals
> > >>>carrying client traffic) the lmp test message is
> > >>>applicable over J0.  If the signal can be framed and J0
> > >>>can be recovered, the Regenerator Section is considered
> > >>>as "in service" from a transport plane perspective. So
> > >>>unlike the J1/J2 case, the application of the lmp test
> > >>>message at the Regenerator Section does not occur in an
> > >>>"out of service" state (from a transport plane
> > >>>perspective).
> > >>>
> > >> Section 6.1 of G.806 refers to a "termination function part of a
> > >> trail, which is in the process of set-up" as in the NMON state.
> > >> LMP link verification is based on pre-service testing. Please let
> > >> us know if we can be of any assistance in updating the
> > >> appropriate Recommendations to support the GMPLS network element
> > >> LMP capability.
> > >>
> > >>
> > >>>5. Clarification of the usage of transport and control
> > >>>names for transport resources in the subject draft, as
> > >>>described in G.8080 Amendment
> > >>>
> > >>LMP defines a TRACE object when a separation between data
> > and control
> > >>plane name space is requested.
> > >>
> >
> >
> > I'm afraid that I don't understand this answer.
> Please look at Section 3.1 and Section 4 of
> draft-ietf-ccamp-lmp-test-sonet-sdh-02.txt.
> 
> >
> >
> > >>
> > >>>6. Consideration of the ANSI 64-byte J1.
> > >>>
> > >>This was mistakenly deleted from the latest version of the
> > draft. This
> > >>will be included in the next version.
> > >>
> >
> >
> >
> > Hopefully, this will not create yet another format.
> Nope.  Since the byte limitation isn't as severe, it will follow the
> nomal LMP Test message format without any additional formats.  See
> draft-ietf-ccamp-lmp-test-sonet-sdh-00.txt (previous version of the
> draft) for the text.