Re: [CCAMP] WG last call -draft-ietf-ccamp-layer1-types-04

Italo Busi <Italo.Busi@huawei.com> Tue, 28 January 2020 01:37 UTC

Return-Path: <Italo.Busi@huawei.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 B73853A081A for <ccamp@ietfa.amsl.com>; Mon, 27 Jan 2020 17:37:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmLlVLmEUUKd for <ccamp@ietfa.amsl.com>; Mon, 27 Jan 2020 17:37:02 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E6E3A0818 for <ccamp@ietf.org>; Mon, 27 Jan 2020 17:37:02 -0800 (PST)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id CDA6C6EE1C470CDD1AAC; Tue, 28 Jan 2020 01:37:00 +0000 (GMT)
Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 28 Jan 2020 01:36:59 +0000
Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml715-chm.china.huawei.com (10.206.15.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 28 Jan 2020 02:36:59 +0100
Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.1713.004; Tue, 28 Jan 2020 02:36:59 +0100
From: Italo Busi <Italo.Busi@huawei.com>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "CCAMP (ccamp@ietf.org)" <ccamp@ietf.org>
Thread-Topic: [CCAMP] WG last call -draft-ietf-ccamp-layer1-types-04
Thread-Index: AQHVyhgBZ5oA1h1XBkCqsm1th1iKLaf/W1ZQ
Date: Tue, 28 Jan 2020 01:36:59 +0000
Message-ID: <4b9cd06e46fe4ee59ce68d25b21d8368@huawei.com>
References: <AM6PR0702MB3606091CD18BB381557CD2FBF0350@AM6PR0702MB3606.eurprd07.prod.outlook.com>
In-Reply-To: <AM6PR0702MB3606091CD18BB381557CD2FBF0350@AM6PR0702MB3606.eurprd07.prod.outlook.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.210.165.173]
Content-Type: multipart/related; boundary="_004_4b9cd06e46fe4ee59ce68d25b21d8368huaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/AXafb1SO7urxn4IHOwcR3AUZeLo>
Subject: Re: [CCAMP] WG last call -draft-ietf-ccamp-layer1-types-04
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 28 Jan 2020 01:37:07 -0000

As a co-author, I have reviewed draft-ietf-ccamp-layer1-types-04 as well as the changes proposed in github to address YANG doctor's review comments

Regarding the YANG doctor's review, I have just sent another mail discussing the issues related with the references to informational documents and on the use of identityref versus enumeration.

I have reviewed the changes proposed in github to address YANG doctor's review comments, and got the following comments (see: https://github.com/haomianzheng/IETF-ACTN-YANG-Model/pull/52):


1.       I would agree with redefining the range-type as an enumeration since no vendor-private label resources are expected.

However, it is also worth noting that the (otn-label-type) choice is not unconstrained but constrained by the value of the range-type. This condition should be captured in the YANG model.
See: https://github.com/haomianzheng/IETF-ACTN-YANG-Model/issues/55



2.       It would be worthwhile re-inserting the value range (i.e., 1...4095) for the otn-tpn and otn-ts typedefs.



3.       It would be worthwhile adding a reference to MEF 63 for the definitions of "coding function", "optical interface function" and "performance metric" base identities



4.       In the description of the tsg leaf within the otn-label-range-info grouping it would be worthwhile clarifying that this leaf shall be present when the range-type is ts and can be omitted to represent the TPN value to be used when mapping an ODUk over an OTUk Link:

·       the range-type is tpn

·       the odu-type-list contain only one entry (ODUk)

·       the tpn range is only value (1)



5.       I support the proposal to remove the default statement for the label-step and to find another solution to maintain the same default behavior. Please take into account that there is some text in section 4.3 about this default behavior which needs to be reviewed and aligned with the new solution, once defined.

See: https://github.com/haomianzheng/IETF-ACTN-YANG-Model/issues/54



6.       Editorial: please update the description of the range-type leaf within the otn-label-range-info grouping as:



OLD

      description "type for range";

NEW

      description

        "The type of range (e.g., TPN or TS)

         to which the label range applies";



7.       Editorial: the rate of the different signals is sometimes represented as "G" (e.g., the ODU4 rate is represented as 104.79G) and sometimes as "Gb/s" (e.g., the 10GE-LAN rate is represented as 10.3 Gb/s).

It is suggested to be consistent and use "Gb/s" every time the "G" represents a "Gb/s" rate.

See: https://github.com/haomianzheng/IETF-ACTN-YANG-Model/issues/57

I have also reviewed draft-ietf-ccamp-layer1-types-04 and have the following additional comments:


8.       I support the proposal to add an example on how to use the label-range-info

See https://github.com/haomianzheng/IETF-ACTN-YANG-Model/issues/49



9.       Some enhancements are needed to support ODUflex:

1.       In order to setup an ODUflex LSP, additional information should be added to the otn-path-bandwidth grouping to indicate the ODUflex bit rate (e.g., 3 Gb/s) and which TS allocation rule to use (section 5.1 or section 5.2 of RFC7139)

2.       In order to support path computation for an ODUflex LSP, additional information should be added to the otn-link-bandwidth grouping to report the maximum ODUflex rate supported.

3.       For example, on free OTU4 Link, it is possible to setup an ODUflex with any rate up to 100 Gb/s but, after a 3Gb/s ODUflex is setup, it would be possible to setup other ODUflex with any rate up to 97 Gb/s.

4.       There are four ODUflex types in Table 7-2 of ITU-T G.709: CBR, GFP-F, IMP and FlexE-aware and three types in RFC7139: CBR, GFP-F non-resizable and GFP-F resizable. The definitions of the ODUflex identities should be revisited after the otn-path-bandwidth and the otn-link-bandwidth groupings have been updated

5.       Editorial c/ODUFlex/ODUflex/

See https://github.com/haomianzheng/IETF-ACTN-YANG-Model/issues/56



10.   Editorial: please update the description of the odu-type-list list within the otn-label-range-info grouping as:



OLD

      description

        "List of ODU types to which the label range applies.

        Empty odu-type-list means all the ODU types are applicable

        per label range. ";

NEW

      description

        "List of ODU types to which the label range applies.

         An Empty odu-type-list means that the label range

         applies to all the supported ODU types.";

See: https://github.com/haomianzheng/IETF-ACTN-YANG-Model/issues/58

I think all these comments can be addressed during WG LC process

Thanks, Italo


Italo Busi
Principal Optical Transport Network Research Engineer
Huawei Technologies Co., Ltd.
Tel : +39 345 4721946
Email : italo.busi@huawei.com
[cid:image001.png@01D5D583.CE2263D0]

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: lunedì 13 gennaio 2020 14:47
To: CCAMP (ccamp@ietf.org) <ccamp@ietf.org>
Subject: [CCAMP] WG last call -draft-ietf-ccamp-layer1-types-04

CCAMP,

the IPR declaration collection has been successfully completed and we can move to the next step.

This starts a 2 weeks working group last call on draft-ietf-ccamp-layer1-types-04
The last call ends on Monday January 27th. Please send you comments to the CCAMP mailing list.

All the IPR declarations from authors and contributors have been collected and can be found in the history of the document.
If interested, please volunteer to be the shepherd of the draft (authors excluded).




Thanks

Daniele & Fatai