Re: [CCAMP] Discussion on Flex-E YANG model structure [was RE:CCAMPDigest, Vol 139, Issue 5]

<> Mon, 23 December 2019 09:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D37F012008F for <>; Mon, 23 Dec 2019 01:31:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XoH6WlNt8SCp for <>; Mon, 23 Dec 2019 01:31:23 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 42DB8120046 for <>; Mon, 23 Dec 2019 01:31:22 -0800 (PST)
Received: from (unknown []) by Forcepoint Email with ESMTPS id B4AEDA8C2135F3BE2D16 for <>; Mon, 23 Dec 2019 17:31:19 +0800 (CST)
Received: from (unknown []) by Forcepoint Email with ESMTPS id 959E190336302E357634; Mon, 23 Dec 2019 17:31:19 +0800 (CST)
Received: from ([]) by with SMTP id xBN9O6LF013341; Mon, 23 Dec 2019 17:24:06 +0800 (GMT-8) (envelope-from
Received: from mapi (kjyxapp02[null]) by mapi (Zmail) with MAPI id mid17; Mon, 23 Dec 2019 17:24:05 +0800 (CST)
Date: Mon, 23 Dec 2019 17:24:05 +0800 (CST)
X-Zmail-TransId: 2b045e0087b5c1250cd0
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
From: <>
To: <>
Cc: <>, <>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: xBN9O6LF013341
Archived-At: <>
Subject: Re: [CCAMP] =?utf-8?q?Discussion_on_Flex-E_YANG_model_structure_=5Bw?= =?utf-8?q?as_RE=3ACCAMPDigest=2C_Vol_139=2C_Issue_5=5D?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Dec 2019 09:31:28 -0000


In clause 7.2.2 of FlexE IA, clients can be received from Eth PHY, that means they can stand alone before configured to a FlexE group.

7.2.1 FlexE Clients Generated internally within a system

A FlexE Client may be generated internally within a system, for example from a Network Processing Unit (NPU) within a router. The packet flow is generated at the determined FlexE Client MAC rate and 64B/66B encoded according to [802.3] Figure 82-5.

7.2.2 FlexE Clients received from an Ethernet PHY

FlexE Clients at the rates of 10G, 25G, 40G, 50G, 100G, 200G, and 400G (per existing [802.3] and [802.3cd] standards) can be created from an Ethernet PHY at the corresponding rate with some processing to convert to the FlexE Client format and rate.


Xiaobing Niu


发件人:Jiangyuanlong <>
收件人:牛小兵10019881; <>om>;
抄送人 <>rg>;
日 期 :2019年12月23日 12:02
主 题 :RE: [CCAMP]  Discussion on Flex-E YANG model structure [was RE:CCAMPDigest, Vol 139, Issue 5]



Thanks for your reply. I think we are converging now.

Just make sure to understand the requirement, can you give some more details on “when facing a FlexE client not determining which FlexE group it will be carried over”?

I am not sure this use case is covered in any OIF FlexE IAs or any ITU-T recommendations.





From: CCAMP []On Behalf Of
Sent: Friday, December 20, 2019 3:40 PM
Subject: Re: [CCAMP] Discussion on Flex-E YANG model structure [was RE: CCAMPDigest, Vol 139, Issue 5]



  Please see the line with [Xiaobing2].


发件人:RobWilton(rwilton) <>


抄送人 <>rg>;

日 期 :2019年12月14日 01:36

主 题 :Discussion on Flex-E YANG model structure [was RE: [CCAMP] CCAMPDigest, Vol 139, Issue 5]

Hi Xiaobing,


Thanks for the comments.  I’ve changed the title to make it clearer as to what is being discussed.


Please see [RW2] inline …


From: CCAMP <>On Behalf
Sent: 13 December 2019 09:37
Subject: Re: [CCAMP] CCAMP Digest, Vol 139, Issue 5


hi, Rob

Please see the lines with [Xiaobing].

Re: [CCAMP] Thoughts on Flex-E YANG models

"Rob Wilton (rwilton)" <> Mon,
 09 December 2019 15:46 UTCShow header

Hi Qilei, Thanks for your comments.  Please see inline … From: <>;Sent;;Sent: 09 December 2019 13:08To: Rob Wilton (rwilton) <>om>;; jiangyuanlong@huawei.comCc: ccamp@ietf.orgSubject: Re:[CCAMP] Thoughts on Flex-E YANG models  Hi,   Sorry for the late reply. We have reviewed the discussion about FlexE yang model in the maillist. Thanks a lot for your reference FlexE-yang model, which helps understand the FlexE group, FlexE clients, slots and so on. Evenmore, some comments help for understanding the FlexE requirements, agreements/disagreements in the models. Some differences in the models could be traced back to the differences in the respectively proposed requirements, for example, whether supports unidirectional FlexE client, whether FlexE instance should be considered in the model, etc. Maybe it's better to consider more application situations to understand the requirements, while not simplifying the requirements and hurrying to a concise model, which could not be applicable in some valuable situations. [RW] For me, the requirement of a standards based YANG model is to provide a configuration and operational YANG model that provides a clean and simple manageability interface for the OIF FlexE 2.0 IA.  At this stage I think that it should focus on doing the basic stuff well, but hopefully in a way that is extensible for vendor additions or future evolution of the standard. I don’t think the model should be trying to go beyond the IA, assuming that vendors may/will augment the standards based YANG model with vendor specific extensions and options. [xiaobing] Mostly Agree. When moving to the basic model, requirements clearly expressed in FlexE IAs should be considered while not leaving some alone, such as FlexE instance, bidirectional and uni-directional client flow, flexible CA replying mechanism.[RW2]I probably agree, but will need to understand the details of the specific options.  The key is that model covers the basic stuff well/easily, and the more advance stuff in a way that isn’t too complex.  YANG if-feature statements can also help here.  However, I think that if we can all reach agreement on the structure first, then we can move on to discussing some of the specific config. [Xiaobing2] OK, I agree with you on the proposed structure.  For the proposed skeleton model, we still have some different understanding about the relationship between FlexE client and FlexE group in the model. According to the description in FlexE-IA, the FlexE group and FlexE client could be configured separately, e.g., a new FlexE client does not need to be configured simultaneously with the FlexE group, it may not be flexible to use one FlexE group construct to include the list of FlexE client informatiokon. [RW] I’m not sure that the OIF IA is particularly specific on this, and one option might be to ask the OIF WG for clarification here. However, from my reading of the spec, I see the document referring to adding and removing client interfaces to a FlexE group, but I see no mention of moving client interfaces from one FlexE group to another.  In addition, I don’t see any information specifying that client-ids must be unique across all groups on the FlexE shim, and I think that would be a requirement to really allow client interfaces to move to different FlexE groups. So, my interpretation of the spec is that client-ids in the calendar are logically specific to a particular flex-e group, but equally the spec states that clients may use any value for clients except 0 and 65535.  Some implementations might be more restricted in what values that could use, which could potentially be expressed as a YANG ‘must’ statement that requires client-ids to be unique on a device. In terms of configuration dependency, similar to Italo’s comments, it is possible to configure a group with clients, but no bonded-phys and add them later.  Given that management clients can choose an arbitrary group-id, this doesn’t seem to be particular restrictive.
[Xiaobing] It’s reasonable to confine Client Numbers to a specific FlexE group and not need to be unique across all groups, so a client can be referenced with ‘Flexe group + client Number’. When the client is not determined which one FlexE group it will be configured into, the client can be bonded to the FlexE group (id=0) temporally.[RW2]Okay.  So, am I right in understanding that you okay with that aspect of the structure that I proposed? [Xiaobing2] The structure is ok, but has some weakness when facing a FlexE client not determining which FlexE group it will be carried over. In addition, there may exist another example that the switching of the carrier of FlexE client from one Group to another, in this case, change of the bonding relationship should be supported. In summary, from our understanding, decoupling the relationship between FlexE group and FlexE client would bring more flexibility. [RW] Yes, I completely agree that what you propose is more flexible, but is an increase in complexity by decoupling the client interfaces from the FlexE group.  It would also seem to have the potential to make deployment much harder.  E.g. what if a device had 100+ bonded connections to 100 devices.  Do we really want to require the client interface number to be unique across all flex-e groups?  What if those 100 devices have further flex-e connections to other devices?  I think that allowing the flex-e client number to be scoped outside of a flexE group will end up making the model much more difficult to manage and deploy across the network.
[Xiaobing] The FlexE Client Number should be unique in a FlexE group. 
But I think that what you want to achieve could potentially be modelled completely outside of FlexE.  I.e. define a virtual Ethernet interface that can be bound to an underlying Ethernet interface (perhaps restricted to a FlexE client interface types if you wish). The model could then allow the binding from the virtual Ethernet interface to be moved to other FlexE client interfaces dynamically.  But I would recommend modelling this entirely separately from a base FlexE model. [Xiaobing] Yeah. That’s our model intended to express. A client could be seen as a virtual Ethernet interface using Client Name, and after adapting into the calendar slots, it could be indexed by a client Number in the FlexE group.  ‘Client Name’ is needed. I think this should be considered in the modeling because it can give a more clear view how the client flow is processed.[RW2]If I understand your thinking, then that might still work with the model that I proposed: [Xiaobing2] Yes. So, with this tree output: 
module: ietf-if-flex-e

  augment /if:interfaces/if:interface:

    +--rw flex-e

       +--rw group-number              uint32

       +--rw more-group-config-here?   string

       +--rw bonded-phy* [name]

       |  +--rw name                           if:interface-ref

       |  +--rw phy-number?                    uint8

       |  +--rw more-bonded-phy-config-here?   string

       +--rw client-interface* [name]

          +--rw name                              if:interface-ref

          +--rw id?                               uint16

          +--rw more-flex-e-client-config-here?   string

 Effectively the “client name” is the name of the interface bound to the flex-e group with a particular client id.  Some implementations might have restrictions on what format that interface name can take (e.g. perhaps the group number and client id have to be part of the interface name in a particular format), other implementations might be more flexible and allow any arbitrary interface name. There is a binding from the flex-e group to the client-interfaces associated with that group. But in your implementation, you could potentially allow the client interfaces to be accepted in configuration without them being bound to any flex-e group.   Other implementations might require that a client interface can only be configured if it has also been bound to a flex-e group in the configuration.  In both cases I think that the same data model works, the only difference is the validation constraints that are being imposed. Do you think that this approach would work for you? I.e. do you think that you could live with the structure proposed, or do you have further concerns that still need to be addressed.  If the authors can reach agreement on the structure then we could move on to discussing the specific configuration.   There is another issue that we want to bring up, which is whether we need to configure the FlexE group as one interface. We can discuss about this. From our understanding, usually, when an interface is needed, there should have some strong requirements. For example, Ethernet LAG, the reason that we think to configure it as an interface is some traffic need to be switched directly to this interface, and obviously, this interface should be able to effect the routing of the traffic. But for FlexE group interface, the only use of this interface is to put FlexE client over it, and this interface only exists in the Ethernet PCS module, which need not be seen by others, so we are not sure whether an interface for FlexE group is needed. [RW] This issue I have more sympathy for.  I also questioned in my mind whether modelling these as interfaces was the right thing to do, but in the end convinced myself that modelling them as interfaces is probably the better choice. I completely agree that a FlexE group doesn’t directly carry client traffic (and hence in that way it is different from a LAG interface), but for me it still something that looks and feels like a L1 interface object, and I believe that many vendors have traditionally modelled similar things (e.g. OTN layers) as interfaces in MIBs.  E.g. I think that quite a lot of the interface types in iana-if-types.yang refer to lower layer interface objects that wouldn’t necessarily directly carry packets. The other potential benefit of modelling them as interfaces is that I believe that the FlexE Shim is very tightly bound to the hardware.  E.g. all member of a FlexE group probably have to be on the same linecard, perhaps even the same NPU chip.  The use of interfaces, with an appropriate location specifier in the name may make it easier for clients to mentally associate a FlexE group to a particular hardware location.  Probably not a critical benefit, but helpful nevertheless.
[Xiaobing] It may be better to think that. [RW2]Thanks,Rob Thanks,Rob



发件人 <>

收件人 <>rg>;


 Digest, Vol 139, Issue 5

Send CCAMP mailing list submissions to

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to

You can reach the person managing the list at

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CCAMP digest..."

Today's Topics:

   1. Re:  Thoughts on Flex-E YANG models (Rob Wilton (rwilton))

CCAMP mailing list