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

"Shiba, Sidney" <sidney.shiba@fnc.fujitsu.com> Mon, 08 November 2004 20:34 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27059 for <ccamp-archive@ietf.org>; Mon, 8 Nov 2004 15:34:22 -0500 (EST)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRGE6-0004ke-Cy for ccamp-archive@ietf.org; Mon, 08 Nov 2004 15:35:03 -0500
Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRG5D-000CIp-3N for ccamp-data@psg.com; Mon, 08 Nov 2004 20:25:47 +0000
Received: from [168.127.0.57] (helo=fncnmp04.fnc.fujitsu.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRG4u-000CFp-F1 for ccamp@ops.ietf.org; Mon, 08 Nov 2004 20:25:28 +0000
Received: (from root@localhost) by fncnmp04.fnc.fujitsu.com (8.12.9/8.12.9) id iA8KPOSD014389; Mon, 8 Nov 2004 14:25:24 -0600
Received: from UNKNOWN (167.254.105.50, claiming to be "FNCNMP01.fnc.fujitsu.com") by fncnmp04.fnc.fujitsu.com 00HZTLV5; Mon, 08 Nov 2004 14:25:23 CST
X-Scanned: Mon, 8 Nov 2004 14:25:02 -0600 Nokia Message Protector V1.3.32 2004072311 - RELEASE
Received: (from root@localhost) by FNCNMP01.fnc.fujitsu.com (8.12.9/8.12.9) id iA8KP2bV014385; Mon, 8 Nov 2004 14:25:02 -0600
Received: from rchemx01.fnc.net.local (167.254.101.101) by smtp.fnc.net.local 00bVT48o; Mon, 08 Nov 2004 14:25:00 CST
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: LMP mib and Sonet-SDH draft mis-alignment
Date: Mon, 08 Nov 2004 14:24:59 -0600
Message-ID: <7CA873794E52904EAA980A074B0767790DF68F@rchemx01.fnc.net.local>
Thread-Topic: LMP mib and Sonet-SDH draft mis-alignment
Thread-Index: AcTFz3oC0UPYg7XxQPmDFqpbBjiQpAAAHHvw
From: "Shiba, Sidney" <sidney.shiba@fnc.fujitsu.com>
To: Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Content-Transfer-Encoding: quoted-printable

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