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

[Jiangyuanlong <[e-mail]>]

Robert,

Thanks for your in-depth comments. I think they touched an important issue, that is the instantiation relationship between a FlexE Group interface (including FlexE client list as a container) and the actual client interfaces (each interface is referenced by an if:interface-ref in our models).
My opinion is,  the creation of a FlexE Group interface and the creation of client interfaces are decoupled processes, as interface-ref only needs to reference to an interface name. Thus all options can be supported.
Or did I miss something?

Best regards,
Yuanlong

From: Rob Wilton (rwilton) [mailto:[e-mail]]
Sent: Monday, January 06, 2020 8:19 PM
To: Jiangyuanlong <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: [CCAMP] Discussion on Flex-E YANG model structure [was  RE:CCAMPDigest, Vol 139, Issue 5]

Please see [RW] inline for my comments:

From: CCAMP <[e-mail]<mailto:[e-mail]>> On Behalf Of Jiangyuanlong
Sent: 06 January 2020 02:20
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [CCAMP] Discussion on Flex-E YANG model structure [was  RE:CCAMPDigest, Vol 139, Issue 5]

Xiaobing,

Please see my comments inline.

Thanks,
Yuanlong

From: CCAMP [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Friday, January 03, 2020 6:36 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [CCAMP] Discussion on Flex-E YANG model structure [was  RE:CCAMPDigest, Vol 139, Issue 5]


hi,  yuanlong

Please refer to comments entitled with [Xiaobing]



On the contrary, the description in Section 5 of OIF FlexE 2.0 is more specific: "The FlexE Shim is the layer that maps or demaps the FlexE Clients carried over a FlexE Group" and "Each FlexE Client has its own separate MAC, Reconciliation Sublayer, and xMII above the FlexE Shim which operate at the FlexE Client rate." The relationship of a FlexE Client, FlexE Shim and its FlexE Group is rather fixed according to this description.

[Xiaobing] In my opinion, those descriptions exactly support the flexibility between FlexE clients and a FlexE group.

[Jiang] Yes, it should be flexible, but not in the way “they (FlexE Clients) can stand alone before configured to a FlexE group”.

In Rob’s YANG module, the modeling of “client-interface” (similar to flexe-client-list in draft-jiang) actually has an attribute “name if:interface-ref”, which can reference to any internal interface (as described in 7.2.1, unclear what parameter is to be managed yet) or any Ethernet PHY (as described in 7.2.2).

Therefore, it provides the flexibility to support any type of FlexE Client bit-stream (i.e., 64B/66B encoded bit-stream).



Otherwise, if FlexE Client is modeled as standalone and could be associated with different FlexE Groups (assuming there is such a support in the data plane), we can hardly configure anything when its FlexE Group is undetermined, since:

[Xiaobing] The configuration of a FlexE client and group can be performed at different time. Just image you first establish a FlexE group without carry any FlexE client, and then configure some FlexE clients over that group.

[Jiang] Totally agreed that we can create a FlexE Group first, and then configure FlexE Clients over that group. My point was “not to create FlexE Clients first, and then associate with a FlexE Group”.

[RW]

I also completely agree that FlexE groups can be configured first, and then Flex-E client interfaces can be subsequently created, deleted, or have their bandwidth modified after the group exists.  I think that this is one of the core concepts of the flexible ethernet architecture.

In terms of creating client interfaces without flex-e groups, that isn’t so obvious to me.  A flex-e client interface has two key parts of configuration:

(i)                 A client interface entry under a Flex-e group.  I see that this list entry is the trigger that forces the creation of a flex-e client interface in the system.

(ii)               An interface entry under /interfaces/interface.  I see that this is really the container for all configuration associated with a flex-e client interface, but doesn’t cause its existence.

As I see it, there are four choices as to how to handle this co-dependent configuration:
(1)    Require both the /interfaces/interface list entry to exist and the /flex-e/group/client-interface list entry to exist
(2)    Allow the /interfaces/interface list entry to be optional when the /flex-e/group/client-interface list entry exists
(3)    Allow the /flex-e/group/client-interface list entry to be optional when the /interfaces/interface list entry exists
(4)    Allow both list entries to be optional, i.e. either can exist without the other

Also considering the NDMA architecture (RFC 8342), there is a logical split between what exists in configuration (i.e. intended/running datastores) vs what exists operationally in the system and is reflected in the operational datastore.

For me, I think that option (2) represents the cleanest model:
-          the existence of /flex-e/group/client-interface is the trigger for creating the client interface, and when that configuration is applied in the system, then I would expect the corresponding client interface to exist in the system and be represented by an entry in /interfaces/interface in the operational datastore.
-          an entry for the client interface only has to exist in /interfaces/interface in the running datastore if some interface configuration has been provided by the operator.

However, I also think that it may be okay to allow some flexibility if a client configures an entry in /interfaces/interface without a corresponding entry in the /flex-e/group/client-interface list:
-          some devices may reject this configuration as being invalid
-          other devices could allow this configuration to be accepted into the running configuration datastore, but not create the interface in operational.  I.e. this is handled equivalently to a missing linecard (as per section 5.3.2 of RFC 8342).

But whatever is decided by the WG, it would be good to document the expected behavior in the model.

Thanks,
Rob



BR

Xiaobing Niu