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

Re: LMP mib and Sonet-SDH draft mis-alignment


	I don't understand your question either. :P  The LMP protocol
is defined in the LMP specification. The MIB merely reflects
a way of viewing/controlling that information. Adrian's earlier
point was that the bits in the MIB need not reflect the
precise ordering as in the LMP specification, as long as
all cases (bits) are covered.  The agent can then do the
translation back and forth.

	--tom


Adrian,

I'm not sure I understand your statement. As a bit of Verify Transport Mechanism
is used to indicate the remote node which mechanism is going to be used for test
messages, I was just wondering how can we guarantee interoperability if a common
definition is not shared among vendors.

In short, which one do you suggest vendors support, the bit definition in
draft-ietf-ccamp-lmp-mib-10.txt or draft-ietf-ccamp-lmp-test-soned-sdh-04.txt?
Is there a sort of implementation agreement in the IETF world?

Thanks,

Sidney

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Monday, November 08, 2004 2:11 PM
To: Shiba, Sidney; ccamp@ops.ietf.org
Subject: Re: LMP mib and Sonet-SDH draft mis-alignment


Sidney,

The bit flags in MIB modules are configuration indications and need not match the actual
protocol elements bit for bit.

In this particular case one might expect the implementation to map between what is
configured and what is sent on the wire in the protocol.

History dictates that LMP Test Sonet has some reserved bits on the wire, but there is no
need to reflect this in the MIB module.

OK?

Adrian

----- Original Message -----
From: "Shiba, Sidney" <sidney.shiba@fnc.fujitsu.com>
To: <ccamp@ops.ietf.org>
Sent: Monday, November 08, 2004 5:13 PM
Subject: LMP mib and Sonet-SDH draft mis-alignment


All,

Can somebody let me know if there is a mib being specified for the
draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
Currently, the draft-ietf-ccamp-lmp-mib-10.txt still have the definitions for SONET/SDH in
it.

lmpLinkVerifyTransportMechanism OBJECT-TYPE
   SYNTAX        BITS {
                     -- All encoding types:
                     payload(0),
                     -- SONET/SDH encoding type:
                     dccSectionOverheadBytes(1),
                     dccLineOverheadBytes(2),
                     j0Trace(3),
                     j1Trace(4),
                     j2Trace(5)
                 }

While, the bit definition in draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt don't match for J1
and J2.
See below:

        0x0001 : Reserved
        0x0002 DCCS: Test Message over the Section/RS DCC
        0x0004 DCCL: Test Message over the Line/MS DCC
        0x0008 J0-trace: J0 Section Trace Correlation
  -->   0x0010:  Reserved
  -->   0x0020:  Reserved
  -->   0x0040 J1-trace: J1 Path Trace Correlation
  -->   0x0080 J2-trace: J2 Section Trace Correlation

Are both documents correct and if so, how the Verify Transport Mechanism should
be interpreted for J1 and J2?

Thanks,

Sidney Shiba