Re: [CCAMP] gmpls-g.709-lmp-discovery Rev02 vs Rev06 - OTU2e

"Pickering, Ladan" <Ladan.Pickering@us.fujitsu.com> Mon, 09 September 2013 14:42 UTC

Return-Path: <Ladan.Pickering@us.fujitsu.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5E521F9EE5 for <ccamp@ietfa.amsl.com>; Mon, 9 Sep 2013 07:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.998
X-Spam-Level:
X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9Kc3UJ9s6p8 for <ccamp@ietfa.amsl.com>; Mon, 9 Sep 2013 07:42:41 -0700 (PDT)
Received: from fncnmp03.fnc.fujitsu.com (fncnmp03.fnc.fujitsu.com [168.127.0.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3660B11E80D3 for <ccamp@ietf.org>; Mon, 9 Sep 2013 07:33:52 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.90,866,1371099600"; d="scan'208,217"; a="39075856"
Received: from rchexhcp1.fnc.net.local ([168.127.134.75]) by fncnmp01.fnc.fujitsu.com with ESMTP/TLS/AES128-SHA; 09 Sep 2013 09:33:52 -0500
Received: from RCHEXMBP1.fnc.net.local ([169.254.2.43]) by RCHEXHCP1.fnc.net.local ([168.127.134.75]) with mapi id 14.02.0347.000; Mon, 9 Sep 2013 09:33:52 -0500
From: "Pickering, Ladan" <Ladan.Pickering@us.fujitsu.com>
To: "Zhangxian (Xian)" <zhang.xian@huawei.com>
Thread-Topic: gmpls-g.709-lmp-discovery Rev02 vs Rev06 - OTU2e
Thread-Index: Ac6rW0fMZ2iAV1hxSIKwo5rUiHL0uABocWPgABqbMUA=
Date: Mon, 09 Sep 2013 14:33:51 +0000
Message-ID: <01B828A5E4EE9748A7A3575B6CE345C66F86283A@RCHEXMBP1.fnc.net.local>
References: <01B828A5E4EE9748A7A3575B6CE345C66F862575@RCHEXMBP1.fnc.net.local> <C636AF2FA540124E9B9ACB5A6BECCE6B18A13218@szxeml510-mbx.china.huawei.com>
In-Reply-To: <C636AF2FA540124E9B9ACB5A6BECCE6B18A13218@szxeml510-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [168.127.136.253]
x-tm-as-product-ver: SMEX-10.2.0.3176-7.000.1014-20138.000
x-tm-as-result: No--46.966700-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_01B828A5E4EE9748A7A3575B6CE345C66F86283ARCHEXMBP1fncnet_"
MIME-Version: 1.0
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] gmpls-g.709-lmp-discovery Rev02 vs Rev06 - OTU2e
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Sep 2013 14:42:55 -0000

Hi Xian,
Thanks for your reply. Do we still need to keep “Flag F”?
Flag F: indicates whether LO ODU2e is supported.

Thanks,
Ladan

From: Zhangxian (Xian) [mailto:zhang.xian@huawei.com]
Sent: Sunday, September 08, 2013 8:44 PM
To: Pickering, Ladan
Cc: ccamp@ietf.org
Subject: RE: gmpls-g.709-lmp-discovery Rev02 vs Rev06 - OTU2e

Hi, Ladan,

     The change made in the OTN LMP draft was just reflecting what was agreed a while ago in CCAMP WG that only G.709 is referenced.

As you probably already know that OTU2e is not supported in G.709( as the note states below Table 7-1 of the version published in Feb. 2012), but rather specified in G.sup43. That’s why we do not cover it any more in the our OTN LMP draft.

I hope this clarify your question.

Regards,

Xian


From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Pickering, Ladan
Sent: 2013年9月7日 7:46
To: ccamp@ietf.org
Subject: [CCAMP] gmpls-g.709-lmp-discovery Rev02 vs Rev06 - OTU2e

Hi Xian,
I have noticed that in revision 02 of the LMP draft, OTU2e was defined as a HO-ODU with a value of 5 under OD(T)UK, but on rev 06 of this draft this has been removed, but  “Flag F” corresponding to ODU2e as a LO-ODU is still in rev 6.

Version 2:
OD(T)Uk field     Signal type of HO ODUk or OTUk
   -------------     ------------------------------
      0              Reserved (for future use)
      1              HO ODU1 or OTU1
      2              HO ODU2 or OTU2
      3              HO ODU3 or OTU3
      4              HO ODU4 or OTU4
      5              OTU2e
      6              OTU3e1
      7              OTU3e2
      8-15           Reserved (for future use)

Version 6:
OD(T)Uk field     Signal type of HO ODUk or OTUk
   -------------     ------------------------------
      0              Reserved (for future use)
      1              HO ODU1 or OTU1
      2              HO ODU2 or OTU2
      3              HO ODU3 or OTU3
      4              HO ODU4 or OTU4
      5-15           Reserved (for future use)

Can you please help me understand why OTU2e was removed from OD(T)UK?

If we have a link that supports OTU2e and allows a 11.095 rate, what should go in ODU(T)UK?

Thanks,
Ladan