Re: [CCAMP] Comparison of Flex-E YANG model parameters

Jiangyuanlong <jiangyuanlong@huawei.com> Thu, 02 April 2020 03:21 UTC

Return-Path: <jiangyuanlong@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 960343A0866; Wed, 1 Apr 2020 20:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level:
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 9cMXdHZm3Wzf; Wed, 1 Apr 2020 20:21:42 -0700 (PDT)
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 8E3623A0862; Wed, 1 Apr 2020 20:21:41 -0700 (PDT)
Received: from lhreml730-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id B09C9434CB9981BABADD; Thu, 2 Apr 2020 04:21:39 +0100 (IST)
Received: from lhreml730-chm.china.huawei.com (10.201.108.81) by lhreml730-chm.china.huawei.com (10.201.108.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 2 Apr 2020 04:21:37 +0100
Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml730-chm.china.huawei.com (10.201.108.81) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Thu, 2 Apr 2020 04:21:37 +0100
Received: from DGGEML512-MBX.china.huawei.com ([169.254.2.152]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0487.000; Thu, 2 Apr 2020 11:21:33 +0800
From: Jiangyuanlong <jiangyuanlong@huawei.com>
To: "niu.xiaobing@zte.com.cn" <niu.xiaobing@zte.com.cn>
CC: "rwilton@cisco.com" <rwilton@cisco.com>, "daniele.ceccarelli@ericsson.com" <daniele.ceccarelli@ericsson.com>, "draft-jiang-ccamp-flexe-yang@ietf.org" <draft-jiang-ccamp-flexe-yang@ietf.org>, "draft-xiaobn-ccamp-flexe-yang-mod@ietf.org" <draft-xiaobn-ccamp-flexe-yang-mod@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: Re:[CCAMP] Comparison of Flex-E YANG model parameters
Thread-Index: AQHV7XsiVesI8PMP5EupuCSLxsHHrqgwJ56w//+MSgCABoi6gIAGMI2AgCF9JxCABb0eAIABq8+g
Date: Thu, 2 Apr 2020 03:21:32 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BD39DDA0F@dggeml512-mbx.china.huawei.com>
References: 202003071759451807041@zte.com.cn, 3B0A1BED22CAD649A1B3E97BE5DDD68BD39BD5BF@dggeml532-mbs.china.huawei.com <202004011702261124059@zte.com.cn>
In-Reply-To: <202004011702261124059@zte.com.cn>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.74.202.215]
Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68BD39DDA0Fdggeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/crng0L-bDyX4zPb6Cav_ag9cn6A>
Subject: Re: [CCAMP] Comparison of Flex-E YANG model parameters
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: Thu, 02 Apr 2020 03:21:48 -0000

Xiaobing,

Please see my comments inline with [YJ].

Regards,
Yuanlong

From: niu.xiaobing@zte.com.cn [mailto:niu.xiaobing@zte.com.cn]
Sent: Wednesday, April 01, 2020 5:02 PM
To: Jiangyuanlong <jiangyuanlong@huawei.com>
Cc: rwilton@cisco.com; daniele.ceccarelli@ericsson.com; draft-jiang-ccamp-flexe-yang@ietf.org; draft-xiaobn-ccamp-flexe-yang-mod@ietf.org; ccamp@ietf.org
Subject: Re:[CCAMP] Comparison of Flex-E YANG model parameters


hi,

Thank you for reformating the text.

Please see the text with [xb4].



B.R.

Xiaobing NIU


原始邮件
发件人:Jiangyuanlong <jiangyuanlong@huawei.com<mailto:jiangyuanlong@huawei.com>>
收件人:牛小兵10019881;rwilton@cisco.com <rwilton@cisco.com<mailto:rwilton@cisco.com>>;
抄送人:daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com> <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>;draft-jiang-ccamp-flexe-yang@ietf.org <draft-jiang-ccamp-flexe-yang@ietf.org<mailto:draft-jiang-ccamp-flexe-yang@ietf.org>>;draft-xiaobn-ccamp-flexe-yang-mod@ietf.org <draft-xiaobn-ccamp-flexe-yang-mod@ietf.org<mailto:draft-xiaobn-ccamp-flexe-yang-mod@ietf.org>>;ccamp@ietf.org <ccamp@ietf.org<mailto:ccamp@ietf.org>>;
日 期 :2020年03月28日 17:40
主 题 :RE: Re:[CCAMP] Comparison of Flex-E YANG model parameters
Hi folks,
Thank Rob and Xiaobing for all the discussions.
To move forward, I summarized the points (following Rob’s numbering) we already have some rough consensus:
(A1) define a per group slot granularity (slot-granularity/cal-slot-gran), the base model should include 5g and 25g, and a default value of 5g is preferred.
  [xb4] ok.
(A2) configuration of Flex-E phy type (100g, 200g, 400g, 50g) (flexe-phy-type) is optional, no default value is needed.
  [xb4] ok.
(A4) the leaf to control the calendar protocol (calendar-protocol-enable/tx-calendar-neg) is named to "calendar-mode", enumeration is preferred for extensibility.
  [xb4] ok.
Note: the Enumeration choices are still to be discussed, but calendar configuration is assumed to be the same for both RX and TX.
(B1) "remote-phy-interface" is not needed.
   [xb4] ok.
(D1) expected-group-number, expected-phy-map, expected-cal-cfg are not required.
[xb4] These are related to the verification function. They can be used only in the Verified mode.
[YJ] Since we currently only consider bidirectional service, the expected parameters are the same as those configured for transmitting direction. We can augment to the unidirectional service in the future and then add the TX, RX and EX parameters.
(E1) initially start with the bidirectional only, i.e., similar to Note in (A4).
 [xb4] ok. The bi-directional client service has more priorities compared with the uni-directional client service, and we suggest to keep track of the support of the uni-directional service.
(F1) Use the 'client-interface', how to manage the slots is still to be cleared up.
 [xb4] Ok, the 'client-interface' only keeps the necessary configuration information for the cliient as the client is mapped into the FlexE group. As to the question, we can refer to B2 for a better solution.
(F4) client interface bandwidth is required and bandwidth in Gbps (in mac-rate) is sufficient.
 [xb4] ok.
(G2) flexe-client-status is presumed to be available under the client interface itself and not needed currently.
 [xb4] ok.
Some other items need more study:
(A3) Configuring the available bandwidth for a flex-e group (flexe-gp-avb-bw) is not needed presumably. Do we need to operationally report the available bandwidth in addition to the total available slots and the allocated client slots? It seems redundant.
 [xb4] It's easy to computer the available bw using available slots and slot granularity, but it's a little boring to counting the total available slot expressed in the form of (B). So it's better to keep both views of the same FlexE group. The available bandwidth will be Config false.
[YJ] Either the front end app or the EMS system can do the computation, I have no strong opinion on this issue.
(A5) reply-ca-mode is not required presumably, and it shall be considered (or solved) together with (A4).
[xb4] At first, we could lay aside the CA replying modes. It should be noted that some scenarios could not be supported without configuring/controling the CA.
[YJ] Good to know it. I think you are referring to the calendar negotiation process, where the CA bit should be driven automatically by the protocol specified by the OIF FlexE, so an enumeration choice in (A4) seems enough to do the job. Or any other scenarios are you referring to?
(B2) how to represent the unavailable slots? It is possible to use ranges of the available slots instead.
Note: This bullet should be considered together with (F1). It is agreed that specifying the slots in a range string makes sense when the clients are well planned, however, if clients are added/deleted/resized frequently, then the slots are fragmented and it may be more difficult to represent them in range strings. This bullet is also closely related to (A3).
 [xb4] In some cases, the format of slots in range string looks awkward, especially for every other slot. Generally it works.
[YJ] OK, let us tag it as “For further study”.
(C1) it seems instance configuration is not needed, and it will be more concise and simpler for clients if this is just configured under the bonded phy as a range of slots.
  [xb4] Ok, just not take the instance configuration into account.
(F2) Explicit configuration for both calendar A and calendar B are not required presumably, it is for further study whether to use a default calendar and an optional backup and then a separate config item to indicate which calendar is being used. It should also be noted that there is no use case in the OIF FlexE IA that we need to configure CCA and CCB at the same time.
 [xb4] For simplification, we could lay aside the calendar A/B configuration.
(F3) rx calendar slots and expected calendar slots are not required presumably.
 [xb4] The expected calendar slots are related to the verification function. Same as D1, they can be used only in the Verified mode. The rx calendar slots are related to the uni-direction client service, and that will not supported in the first FlexE yang model.
[YJ] Good.
(G1) flexe-phy-status is for further study, some people think it is a duplicate of information already available in a generic Ethernet Phy YANG model, though it should be noted that LPF and RPF status for a PHY are not captured in any Eth Phy YANG model yet.
 [xb4] It may be better to update flexe-phy-status into Ethernet PHy yang model.
[YJ] OK.
If there is no other opinion, we can update the base YANG model with the points in consensus. Any comments?
Regards,
Yuanlong

From: niu.xiaobing@zte.com.cn<mailto:niu.xiaobing@zte.com.cn> [mailto:niu.xiaobing@zte.com.cn]
Sent: Saturday, March 07, 2020 6:00 PM
To: rwilton@cisco.com<mailto:rwilton@cisco.com>
Cc: Jiangyuanlong <jiangyuanlong@huawei.com<mailto:jiangyuanlong@huawei.com>>; daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>; draft-jiang-ccamp-flexe-yang@ietf.org<mailto:draft-jiang-ccamp-flexe-yang@ietf.org>; draft-xiaobn-ccamp-flexe-yang-mod@ietf.org<mailto:draft-xiaobn-ccamp-flexe-yang-mod@ietf.org>; ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: Re:[CCAMP] Comparison of Flex-E YANG model parameters


hi Rob,

Please see [xb3] inline.



B.R.

Xiaobing Niu




原始邮件
发件人:RobWilton(rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>
收件人:牛小兵10019881;jiangyuanlong@huawei.com <jiangyuanlong@huawei.com<mailto:jiangyuanlong@huawei.com>>;daniele.ceccarelli@ericsson.com <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>;
抄送人:draft-jiang-ccamp-flexe-yang@ietf.org<mailto:draft-jiang-ccamp-flexe-yang@ietf.org> <draft-jiang-ccamp-flexe-yang@ietf.org<mailto:draft-jiang-ccamp-flexe-yang@ietf.org>>;draft-xiaobn-ccamp-flexe-yang-mod@ietf.org <draft-xiaobn-ccamp-flexe-yang-mod@ietf.org<mailto:draft-xiaobn-ccamp-flexe-yang-mod@ietf.org>>;ccamp@ietf.org <ccamp@ietf.org<mailto:ccamp@ietf.org>>;
日 期 :2020年03月03日 19:29
主 题 :RE: Re:[CCAMP] Comparison of Flex-E YANG model parameters
Hi Xiaobing,

Please see [RW2] inline …


From:niu.xiaobing@zte.com.cn<mailto:niu.xiaobing@zte.com.cn> <niu.xiaobing@zte.com.cn<mailto:niu.xiaobing@zte.com.cn>>
Sent: 28 February 2020 07:42
To: jiangyuanlong@huawei.com<mailto:jiangyuanlong@huawei.com>; daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>; Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>
Cc: draft-jiang-ccamp-flexe-yang@ietf.org<mailto:draft-jiang-ccamp-flexe-yang@ietf.org>; draft-xiaobn-ccamp-flexe-yang-mod@ietf.org<mailto:draft-xiaobn-ccamp-flexe-yang-mod@ietf.org>; ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: Re:[CCAMP] Comparison of Flex-E YANG model parameters


hi Rob, Daniele, Yuanlong,

Based on previous discussion, I think we are moving forward, although a little slow. I support to make more progress.

Please check the comments with [xb2] for more consideration.

Thanks!



B.R.

Xiaobing NIU


原始邮件
发件人:Jiangyuanlong <jiangyuanlong@huawei.com<mailto:jiangyuanlong@huawei.com>>
收件人:Daniele Ceccarelli <daniele.ceccarelli@ericsson.com<mailto:daniele.ceccarelli@ericsson.com>>;Rob Wilton(rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>;牛小兵10019881;
抄送人:draft-jiang-ccamp-flexe-yang@ietf.org<mailto:draft-jiang-ccamp-flexe-yang@ietf.org> <draft-jiang-ccamp-flexe-yang@ietf.org<mailto:draft-jiang-ccamp-flexe-yang@ietf.org>>;draft-xiaobn-ccamp-flexe-yang-mod@ietf.org <draft-xiaobn-ccamp-flexe-yang-mod@ietf.org<mailto:draft-xiaobn-ccamp-flexe-yang-mod@ietf.org>>;ccamp@ietf.org <ccamp@ietf.org<mailto:ccamp@ietf.org>>;
日期:2020年02月28日 14:46
主题:RE: [CCAMP] Comparison of Flex-E YANG model parameters
Definitely I support this, and will be glad to work together with Rob and others who are interested on a common FlexE model.
I also think the initial model structure in the (https://github.com/rgwilton/flex-e-yang<https://protect2.fireeye.com/v1/url?k=e174f393-bde6fe8c-e174b308-0cc47ad93db4-98b9e82d83e7e414&q=1&e=c450afb8-466e-44b9-b548-a0246e2e97e0&u=https%3A%2F%2Fgithub.com%2Frgwilton%2Fflex-e-yang>) is quite reasonable a start.

Thanks,
Yuanlong

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Thursday, February 27, 2020 10:35 PM
To: Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>;niu.xiaobing@zte.com.cn<mailto:niu.xiaobing@zte.com.cn>
Cc:draft-jiang-ccamp-flexe-yang@ietf.org<mailto:draft-jiang-ccamp-flexe-yang@ietf.org>;draft-xiaobn-ccamp-flexe-yang-mod@ietf.org<mailto:draft-xiaobn-ccamp-flexe-yang-mod@ietf.org>;ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: RE: [CCAMP] Comparison of Flex-E YANG model parameters

“If that is a reasonable approach, then do you think that it would be possible for both sets of authors to get together to produce a combined updated draft that takes into account the suggestions below and the prior proposed outline structure (https://github.com/rgwilton/flex-e-yang<https://protect2.fireeye.com/v1/url?k=e174f393-bde6fe8c-e174b308-0cc47ad93db4-98b9e82d83e7e414&q=1&e=c450afb8-466e-44b9-b548-a0246e2e97e0&u=https%3A%2F%2Fgithub.com%2Frgwilton%2Fflex-e-yang>)?  Perhaps this could be done somewhere on github, with issues opened for the particular points that need further discussion?  I’m happy to be in those author discussions if it helps, but probably will have limited time actually working on a draft.”

This is exactly what I was suggesting…thank Rob for reiterate the message.

Thanks,

Daniele

From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>>On Behalf Of Rob Wilton (rwilton)
Sent: den 21 februari 2020 19:06
To:niu.xiaobing@zte.com.cn<mailto:niu.xiaobing@zte.com.cn>
Cc:draft-jiang-ccamp-flexe-yang@ietf.org<mailto:draft-jiang-ccamp-flexe-yang@ietf.org>;draft-xiaobn-ccamp-flexe-yang-mod@ietf.org<mailto:draft-xiaobn-ccamp-flexe-yang-mod@ietf.org>;ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: Re: [CCAMP] Comparison of Flex-E YANG model parameters

Hi Xiaobing,

Thanks for the comments.

I’ve given responses [RW] inline below, but please note that my aim here is just to come up with a common model that both sets of authors can agree as a starting point for further discussion.  I would suggest that the model should start relatively simple, but all the outstanding issues can and should be tracked, and the WG can discuss and decide whether or not the model should be extended to support each of those issues.

If that is a reasonable approach, then do you think that it would be possible for both sets of authors to get together to produce a combined updated draft that takes into account the suggestions below and the prior proposed outline structure (https://github.com/rgwilton/flex-e-yang<https://protect2.fireeye.com/v1/url?k=e174f393-bde6fe8c-e174b308-0cc47ad93db4-98b9e82d83e7e414&q=1&e=c450afb8-466e-44b9-b548-a0246e2e97e0&u=https%3A%2F%2Fgithub.com%2Frgwilton%2Fflex-e-yang>)?  Perhaps this could be done somewhere on github, with issues opened for the particular points that need further discussion?  I’m happy to be in those author discussions if it helps, but probably will have limited time actually working on a draft.

Further comments inline.

From:niu.xiaobing@zte.com.cn<mailto:niu.xiaobing@zte.com.cn> <niu.xiaobing@zte.com.cn<mailto:niu.xiaobing@zte.com.cn>>
Sent: 21 February 2020 13:06
To: Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>
Cc:jiangyuanlong@huawei.com<mailto:jiangyuanlong@huawei.com>;ccamp@ietf.org<mailto:ccamp@ietf.org>;draft-xiaobn-ccamp-flexe-yang-mod@ietf.org<mailto:draft-xiaobn-ccamp-flexe-yang-mod@ietf.org>;draft-jiang-ccamp-flexe-yang@ietf.org<mailto:draft-jiang-ccamp-flexe-yang@ietf.org>;shirley.yangfan@huawei.com<mailto:shirley.yangfan@huawei.com>
Subject: Re:Comparison of Flex-E YANG model parameters


Hi Rob,

I've added some comments with [xbn]. Please have a look.



B.R.

Xiaobing Niu



发件人:RobWilton(rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>
收件人:牛小兵10019881;jiangyuanlong@huawei.com <jiangyuanlong@huawei.com<mailto:jiangyuanlong@huawei.com>>;ccamp@ietf.org <ccamp@ietf.org<mailto:ccamp@ietf.org>>;draft-xiaobn-ccamp-flexe-yang-mod@ietf.org <draft-xiaobn-ccamp-flexe-yang-mod@ietf.org<mailto:draft-xiaobn-ccamp-flexe-yang-mod@ietf.org>>;draft-jiang-ccamp-flexe-yang@ietf.org <draft-jiang-ccamp-flexe-yang@ietf.org<mailto:draft-jiang-ccamp-flexe-yang@ietf.org>>;
抄送人:shirley.yangfan@huawei.com<mailto:shirley.yangfan@huawei.com> <shirley.yangfan@huawei.com<mailto:shirley.yangfan@huawei.com>>;
日期:2020年02月21日 01:53
主题:RE: Re:Comparison of Flex-E YANG model parameters
Just pinging this thread to see if any of the authors had further thoughts on this.

I guess that the clock is ticking to get an updated model & draft before IETF 107, and it would be good to keep this work progressing.

Thanks,
Rob


From:niu.xiaobing@zte.com.cn<mailto:niu.xiaobing@zte.com.cn> <niu.xiaobing@zte.com.cn<mailto:niu.xiaobing@zte.com.cn>>
Sent: 31 January 2020 16:40
To:jiangyuanlong@huawei.com<mailto:jiangyuanlong@huawei.com>; Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>
Cc:ccamp@ietf.org<mailto:ccamp@ietf.org>; draft-xiaobn-ccamp-flexe-yang-mod@ietf.org<mailto:draft-xiaobn-ccamp-flexe-yang-mod@ietf.org>;draft-jiang-ccamp-flexe-yang@ietf.org<mailto:draft-jiang-ccamp-flexe-yang@ietf.org>;shirley.yangfan@huawei.com<mailto:shirley.yangfan@huawei.com>
Subject: Re:Comparison of Flex-E YANG model parameters


Hi Rob, Yuanlong

Thanks for your detailed analysis and trade-off recommendation.

Recently, several contributions about FlexE have been discussed in ITU-T SG15 meeting and some more will be discussed in following days.  And more clear requirements about FlexE processing functions and related configuration are expected. I think that will be helpful to the model.



B.R.

Xiaobing Niu




原始邮件
发件人:Jiangyuanlong <jiangyuanlong@huawei.com<mailto:jiangyuanlong@huawei.com>>
收件人:Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>;ccamp@ietf.org <ccamp@ietf.org<mailto:ccamp@ietf.org>>;draft-xiaobn-ccamp-flexe-yang-mod@ietf.org <draft-xiaobn-ccamp-flexe-yang-mod@ietf.org<mailto:draft-xiaobn-ccamp-flexe-yang-mod@ietf.org>>;draft-jiang-ccamp-flexe-yang@ietf.org <draft-jiang-ccamp-flexe-yang@ietf.org<mailto:draft-jiang-ccamp-flexe-yang@ietf.org>>;
抄送人:Yangfan (IP Standard) <shirley.yangfan@huawei.com<mailto:shirley.yangfan@huawei.com>>;
日期:2020年01月31日 07:36
主题:RE: Comparison of Flex-E YANG model parameters
Hi Rob,

Thanks a lot for the detailed comments, I agree with most of them (except several minor items, I will comment on them later).
I will be glad to work with you and the other authors on a common FlexE model draft.

Cheers,
Yuanlong

-----Original Message-----
From: Rob Wilton (rwilton) [mailto:rwilton@cisco.com]
Sent: Thursday, January 30, 2020 12:58 AM
To: ccamp@ietf.org<mailto:ccamp@ietf.org>; draft-xiaobn-ccamp-flexe-yang-mod@ietf.org<mailto:draft-xiaobn-ccamp-flexe-yang-mod@ietf.org>; draft-jiang-ccamp-flexe-yang@ietf.org<mailto:draft-jiang-ccamp-flexe-yang@ietf.org>
Subject: Comparison of Flex-E YANG model parameters

Hi,

Sorry for the delay.

After I think that we reached rough agreement on Flex-E model structure, I have now (with my limited knowledge) gone through the flex-e configuration parameters in draft-xiaobn and draft-jiang.  I think that I have hopefully given comments on all areas of the configuration.  I think that some aspects will be easier to resolve and reach conclusion on than other parts.

Hence, to try and make forward progress, I suggest that we try and defer getting stuck in discussion on the following topics:

  1.  Whether we need to have explicit configuration for both A and B calendars or not.  The model will definitely be simpler for client if this is not required, so I would recommend that we assume that it is not required, try and resolve the other points and then come back to this potentially thorny issue.

[xbn] If no explicit configuration for A/B calendar, some scenarios could not be supported.
  2.  Whether we need to have the "expected" configuration leaves.  I'm not sure I fully understand the intent of this, but I suspect that the intent is to use the calendar protocol as a way of checking that both sides are correctly configured.  My suggestion, to simplify the model, is to assume that in this case that the RX and TX calendar for client interfaces are the same, and hence this configuration could probably be expressed through a different "calendar-protocol-enable/tx-calendar-neg" setting.  But again, I suspect that this might be another can or worms that we might want to try and keep the lid on for the moment whilst we get agreement for the other parts of the model.  But, of course, this could be handled through a vendor or standard augmentations, or YANG features, but I still have a preference is trying to keep the base model as simple as we can.
 [xbn] Setting expected configuration info is aiming to strictly check the configuration in both ends. It can be relieved as you recommended above.
[RW]
Okay, so I think that I understand that you are happy to defer this issue for the moment (perhaps track the issue on a github repro).
Barring these two points, you will see that I have tried to give a suggestion for the other configuration items, with an aim to try and get a compromise starting model that the authors and WG can move forward with.

Based on the comments that I receive, I propose updating the YANG model here (https://github.com/rgwilton/flex-e-yang<https://protect2.fireeye.com/v1/url?k=1159a1ef-4dcbacf0-1159e174-0cc47ad93db4-fce603909f727dd8&q=1&e=c450afb8-466e-44b9-b548-a0246e2e97e0&u=https%3A%2F%2Fgithub.com%2Frgwilton%2Fflex-e-yang>)2Fflex-e-yang>).  If we do manage to find common ground over the next week or two, hopefully it will be possible for both sets of authors to take the combined model, polish it, and work together on a common FlexE model draft?

FlexE Group, Bonded-phy, instance and client configuration comparison:

(A) Group level configurable attributes:
    (A 1) Both drafts define a per group slot granularity (slot-granularity/cal-slot-gran)
     - both represented by an enum
     - both allow 5g and 25g (as per the OIF standard)
     - draft-jiang draft also allows "slot-others".
     - draft-jiang defines a default value (5g), but draft-xiaobn does not.
     - My recomendation:
       - The base model should only include 5g and 25g, because that is what is in the spec, and vendors can always deviate this leaf if required to support non-standard values.
       - I think that a default value is useful and should be defined, but possibly using 25g as the default because it is more forward looking (as bandwidths increase).
      [xbn] Maybe 5G slot is better, because 5G slot is more flexible to support various clients( e.g. BW lesss than 25G).
[RW] Sure, I think that this is a minor detail.
    (A 2) Both drafts support configuring Flex-E phy type (100g, 200g, 400g, 50g) (flexe-phy-type)
     - I'm not sure that this configuration is required, or just useful as an extra check.
     - Vendors could always deviate add "mandatory" if required.
     - I suggest that this leaf should be optional, and have no default value defined.

    (A 3) draft-xiaobn supports limiting the bandwidth for a flex-e group (flexe-gp-avb-bw)
     - This configuration seems to act as an additional constraint.  I don't see any harm in this configuration, but it seems somewhat redundant (given the bandwidth can be calculated for each member interface), and hence as a starting point, my preference would be to leave this out of a standard FlexE configuration data model.
     [xbn]When you take the Unequipped instance and Unavailable slot into consideration, the bandwidth can provide some sense. It gives the total BW directly.
[RW] Operationally reporting the available bandwidth definitely makes sense (which would take into account unavailable slots, etc).  But I’m less convinced of it as a configuration item.  E.g. what would it mean if the configured value doesn’t match the real bandwidth?  Would the config be rejected?
 [xb2] Could we make it readable only? When a slot is used or released, the available bandwidth changes accordingly. That can be used to jusge whether there is enough bandwdth available for a new requirement.
[RW2] By read-only, I assume that you mean config false, if so I think that would be fine.
   [xb3] Yeah, config false.
    (A 4) Both drafts seem to have a mechanism to control the calendar protocol (calendar-protocol-enable/tx-calendar-neg):
      - I would suggest changing the name of this leaf to "calendar-mode", and use an enumeration for future extensibility.
      - Enumeration choices could be
         "Static", - calendar configuration is static (and assumed to be the same for both RX and TX), calendar protocol information is ignored.
         "Verified" - calendar configuration is static (and assumed to be the same for both RX and TX), calendar protocol information is checked, otherwise the client interface is kept down in an errored state?  E.g. replacing the need for the "expected" configuration values in draft-xiaobn.

    [xbn] Originally this kind of ‘verifiy function’ was considered in ‘Static’ mode. Here you put it in a ‘Verified’ mode, and it is OK.

[RW] Okay.


         "Master-Slave" calendar configuration is static for TX, RX is determined from the calendar protocol (although perhaps should use different terminology for political correctness)
      - Having a default value for the calendar protocol makes sense, but I don't know what the appropriate default is.

    (A 5) draft-xiaobn defines reply-ca-mode:
      - I'm not quite sure what this leaf is for, and hence I question whether it is required since it appears to be somewhat implementation specific.
     [xbn] After recieving the CReq, the demux may delay for some time and then reply with the CA ,while not immediately reply. Some reasons for that are described in FlexE IAs. To consider both cases, the moment of replying CA should be flexible.
[RW] Okay, ideally it wouldn’t be necessary to expose this sort of detail into the model.  I would suggest that we leave this out to start off with, and raise a issue to track and discuss.
  [xb2] Could we leave this open that the default behaviour is replying CA immediately and other behaviour may be augmented later?
[RW2] Yes, but I don’t really know about the CA response.  I think that this should follow whatever the Flex-E spec states.  I.e. possibly the YANG model should say nothing about this at all.
  [xb3] Yeah, we should follow the FlexE spec. For more information about the CA bit, please refer to middle part of Page 31 in the FlexE IA 2.0. here it shows as follows,

When the FlexE demux is prepared to accept the switch of calendar configuration, it

informs the FlexE mux by changing its CA bit to match the incoming CR bit on all 100G

FlexE Instances of the FlexE Group beginning with the same overhead frame in the

overhead positions on each 100G FlexE Instance. When this occurs is application

specific. At the earliest, it occurs once the assignment of every calendar slot in the offline

configuration has been received by the FlexE demux in a FlexE overhead frame with a

good CRC after the change of the incoming CR bit. But the CA bit indication may be

delayed for a variety of reasons: for example, software may need to be prepared for the

incoming bandwidth change, for example in SDN applications.

    From above description in italic,we can get to the conclusion that there are different replying choices for the CA bit. That should be taken into consideration in Yang model. One of the implementations is to config reply-ca-mode just as shown in draft-xiaobn.

(B) Bonded-phy level configuration:
    (B 1) draft-xiaobn contains a "remote-phy-interface" as an interface-ref.  This configuration cannot work as an interface-ref (because it would attempt to validate against the local device's interface list).  I suspect that this isn't really configuration at all, but possibly just documentation.  As a starting point, my preference would be to leave this out of a standard FlexE configuration data model.  Vendors could always augment this in, with little interop issues.
    (B 2) Both drafts define mechanisms under the bonded-phy/[instance for draft-xiaobn] to specify the unavailable slots.  Rather than defining these as lists of unavailable slots, I would merge these into a single per bonded-phy leaf of ranges of what are the available slots, and if the leaf is not configured then all slots (for available instances) can be used.
        E.g. I am suggesting a per bonded-phy leaf:
            available-calender-slots = "1-15, 19, 20-29"
     [xbn] It’s ok. The slot number may be not consecutive.
[RW] Okay.
(C) Instance configuration:
    (C 1) draft-xiaobn has explicit support for flex-e "instances" from FlexE 2.1,(e.g. a 200G PHY is represented as 2x100G instances, a 400G PHY, has 4x100 instances).
     - I would think that any instance configuration should naturally be under the PHY, since from the spec, it seems to be phy specific, and relative to the phy.
     - FlexE has the ability to disable instances, but it must always be the highest instance numbers on a phy that are disabled.
        * One option is that this could be represented by a single configurable uint8 under the bonded-phy that indicates the number of supported-instances and defaults to all instances being supported if not configured.  [Note - this configuration is probably equivalent to the "uneq-flexe-instance", but in reverse sense and represented in a more concise way.]
        * An alternative option would be to infer which instances are disabled from the available-calendar-slot list.  E.g. for a 400G interfaces, stating available-slots="1-39" would imply that only instances 1 and 2 are in use, and instances 3 and 4 are disabled.
     - Otherwise I don't think that it is necessary to configure/define a separate calendar slot availability per instance.  I think that it will be more concise and simpler for clients if this is just configured under the bonded phy.  E.g., assuming 5G slots,  instance 0 would be slots 0-19, instance 1 would be slots 20-39, instance 2 would be slots 40-59, etc...

[xbn] OK
(D) "Expected configuration":
  (D 1) draft-xiaobn defines expected-group-number, expected-phy-map, expected-cal-cfg.
    - I don't think that these configuration items should be required.  These settings should either just be (i) regular configuration, i.e. covered by the other configuration items, or learned from the peer (e.g. if it can be carried via protocol).
    [xbn] It's related to the verifying function mentioned previously.
[RW] Okay, great.  Thanks for confirming that these are not required.

(E) "Calendar configuration"
  (E 1) draft-xiaobn defines tx-calendar, rx-calendar (and also tx-calendar-neg but that has been covered above).
   - I think that it is useful to be able to configure whether the A or B calendar is being used, defaulting to "A" if not specified.
   - I'm not convinced that the standard model should have rx-calendar. In the case that it is statically configured, I think that the standard model should assume that the RX and TX calendar are the same.

  [xbn] I think the unidirectional client service should also be considered.

[RW] Okay.  Can we initially start with the bidirectional only, and then raise an issue to discuss the unidirectional client service.  I think that it would be good to understand the real use cases here.

  [xb2] Ok. The bi-directional client service has more priorities compared with the uni-directional client service, and we suggest to keep track of the support of the uni-directional service.

[RW2] Okay.


(F) Client interface configuration
(F 1) From reading the OIF-FlexE spec, on the wire it looks like clients are bound to instances, but I don't think that this should be in the management model, it feels like it would be exposing unnecessary complexity.
   - draft-jiang allows each individual slot to be assigned to assigned to a phy and a slot on that phy.  This could end up being verbose.  E.g. 20 entries for a 100G client interface with 5G slot sizes.  Client ordering is explicitly specified by the client-slot-id leaf.
   - draft-xioabn maps to instance number and slot-id.  Client ordering isn't specified.  This would probably work if the list is "ordered-by user".
   - In both cases, I think that the configuration is a bit verbose, particularly for simple/normal configurations.  Hence, I would recommend a more compact format:
     - An ordered-by user list of phys, where for each phy the slots are specified in a range string, e.g. "1-10, 15-19".  The mapping from the client slot to phy slot is implicit from the client ordering of the phys and the slots.
     - This does effectively impose some restrictions (or simplifications):
       - The slots used by a client on a given phy are always in order, e.g.. I think that "10-1" or "6,3,2,9,5" should not be allowed.
       - You can't have some slots on one phy, then some on another phy, and then more on the first phy again.  All the slots on a given phy must be specified together (because the phy interface would be the list key).
     [xbn] It maybe work in this way after increasing or decreasing the width several times.
[RW] I still think that might be okay.  If the configuration is being done manually, then some of these changes could end up being service impacting, but if calendar negotiation was being used, then I think that this restriction should probably be okay (again, at least from a starting point)?
  [xb2] According to the restrictions above, the slot list configured for a client will be always ordered from lower number PHYs to higher number PHYs. That's OK.

 [xb2]There's a problem about the client and the client-interface under the FlexE group. we have talked about it.

   A client is Ethernent flow based on a MAC data rate. It can be generated within system or received from an Ethernet PHY. When configuring the client into a FlexE group, the client can be seen as an interface with MAC.

   In the proposed YANG model, the FlexE group includes PHYs, list of client-interface, and slots allocated for a client interface.  Because of the slots, the client-interface in Flexe group is diiferenet from the client that would be carried by the FlexE group, and they are two different kinds of interfaces. It's also one of the reason why Flexe-group is dfferent from LAG. They should be considered in different ways in the YANG model.

[RW2]

The “client-interface” under the flex-e group isn’t really the client-interface at all.  It is really just the configuration that is necessary to create the client interface, and I would see this as the configuration that controls creating the client interface.

 [xb3] I got it. The 'client-interface' only keeps the  necessary configuration information for the cliient as the client is mapped into the FlexE group.

Yes, the slots are logically a property of the FlexE group. But ultimately what is being configured here is a mapping from flex-e group calendar slots to client interfaces carrying useful data.  From a manageability aspect I think that it is much easier for clients to describe this relationship in the context of each flex-e client – I think that is also effectively what your model is doing.



We think the model should include client, slot and PHY three parts. The client should be mapped into( or binded to) one of the client-interface in the FlexE group.

The client can be numbered with (Node ID+client number) in order to make it unique and conveniently maintained. While the client-interface can be numbered in the scope of a FlexE group( e.g. 1,2,3) or a node(Node ID+x). Even both can be numbered in the same value, they are diferent in essence.

[RW2]

Sorry, but I don’t fully understand your description/explanation above.  Probably this is something that needs to be discussed verbally further.



I agree that FlexE should be modelled a bit differently from LAG.



Roughly using your terminology then what I am trying to model is:

1. The “client” is defined under the FlexE group.

2.  The “client-interface” is defined under /if/interfaces/, and looks like any other physical Ethernet interface, but with the difference that its bandwidth could change dynamically on the fly.



There also needs to be a binding (as a leafref) between “client” defined under the flex-e group and the “client-interface” defined under /if/interfaces/.  In the model that I’ve currently proposed the mapping is keyed by interface name, but I think that you are asking that this be keyed by client-id instead, and be called “client” instead of “client-interface?  I still regard this as a relatively minor issue, and one that can be tracked via a issue and then discussed further.  I.e. I really think that this is a point discussion about the lifecycle of the client interface relative to the flex-e group configuration and what level of forward referenced configuration is required. Note, whatever we come up with here needs to be compatible with NMDA (RFC 8342).

  [xb3] OK, it's fine to keep the 'client-interface' intact.


(F 2) Explicit configuration for calendar A vs calendar B.
  - draft-xioabn allows both A and B calendars to be specified separately, draft-jiang does not.
  - My view is that configuring both A and B calendars complicates the model, and I would prefer that it is left out of an initial joint WG draft, but I understand that significant further discussion on this point is probably required.
    [xbn]Some scenarios about configuring A/B to specific value are described in FlexE IAs. If this is not considered, the model would not be applicable for some applications.
[RW2] Okay, but rather than explicitly configurating A and B calendars, it might be better to have a default calendar and an optional backup calendar, and then a separate config item to indicate which calendar is being used.  So, I agree that this should be discussed further, but was suggesting that we try and start from the simplest point and then add in the extra bits that are really required.
     [xb3]  OK, I agree with you to have a default calendar and an optional backup calendar, and then a separate config item to indicate which calendar is being used.
(F 3) rx calendar slots and expected calendar slots.
  - draft-xioabn allows, if the tx-calendar is in static mode, to specify the rx-calendar slots, and the expected A and B calendar slots.
  - I think that in static mode we should probably assume that RX calendar slots are the same as the TX calendar slots.
  - I don't think that the expected slots configuration should be required, or perhaps could be better modelled via the calendar protocol mode.
    [xbn] It’s related to two uni-directional flows with different BWs and directions. For example, in the same FlexE group, Flow A->Z uses slots[1, 2], while flow Z->A uses slots[2,3,4]. How to support this?
[RW] I think that for that more complex scenario we should rely on the calendar negotiation (for the standard model), but allow vendors to augment with this functionality if required.
  [xb2] It's a good idea to include a default calendar, optional backup calendar and configurable will-be-used calendar. That enables the network manager explicitly changes the calendar if he wants.
[RW2] This will probably end up needing further discussion. I.e. whatever is decided here we need to make sure that the device doesn’t have to change the configuration.  I.e. configuring the device to use the backup calendar doesn’t change the configuration to being the primary calendar.  The client would need to explicitly configure that, as a second step, if required.
  [xb3] To simplify the model,  I would like not to take this feature into account currently and leave it for further discussion.
(F 4) Bandwidth
   - draft-xiaobn defines client inteface bandwdth both in terms of the signal rate and mac-rate.
   - I think that having client interface bandwidth is required, and probably appropriate to define here under flexe client interface configuration.
   - Specifying the bandwidth in Gbps is probably sufficient, the signal rate can be inferred from the bandwidth.  Allowable values (10, 40, or m*25).
     [xbn] OK.
(G) Operational values:
(G 1) draft-jiang defines flexe-phy-status:
   - I think that this is okay, although I question whether this would end up being a duplicate of information already available in a generic Ethernet Phy YANG model.
   - I propose that this is retained at this time.
     [xbn]OK.
[RW]
Thanks, Rob
  [xb2]After more discussion, we think the flexe-phy-status is duplicated, and it's better not considered here.
[RW2] Fine.  Again, my aim here is really just to get to a common starting position.  Then issues can be raised and discussed for points like this one to decide what is best.
Thanks,
Rob
(G 2) draft-jiang defines flexe-client-status:
   - I think that this is a duplicate of the status information that should be available under the clinet interface itself for all Ethernet interfaces