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

Hi Yuanlong, Rob


Please see the sentences with [Xb03].


B.R.


Xiaobing Niu







原始邮件



发件人：Jiangyuanlong <[email protected]>
收件人：Rob Wilton (rwilton) <[email protected]>;牛小兵10019881;
抄送人：[email protected] <[email protected]>;
日 期 ：2020年01月10日 20:41
主 题 ：RE: [CCAMP]  Discussion on Flex-E YANG model structure [was  RE:CCAMPDigest, Vol 139, Issue 5]




Rob,


 


Please see my comments inline.


 


Cheers,


Yuanlong


 



From: Rob Wilton
 (rwilton) [mailto:[email protected]] 
Sent: Wednesday, January 08, 2020 10:24 PM
To: Jiangyuanlong <[email protected]>; [email protected]
Cc: [email protected]
Subject: RE: [CCAMP] Discussion on Flex-E YANG model structure [was  RE:CCAMPDigest, Vol 139, Issue 5]




 


Hi Yuanlong,


 


I think that it is a question of what is expected when the configuration is validated:


  E.g. (1) does the device allow a management agent to configure a FlexE client
 interface under the /interfaces/interface list without a corresponding entry under the FlexE group client interfaces?


[Jiang] I think “configure a FlexE client interface under the /interfaces/interface list” can be allowed if the interface is just configured as a
 traditional MAC interface (i.e., without any FlexE attributes), such as its MAC address.


 


          (2) does the device allow a management agent to configure a FlexE client
 interface under a FlexE group without a corresponding entry under the /interfaces/interface/ list?


 


I think that doing (2) is fine (as per my previous email).  But my questioning
 was really whether (1) should be allowed or not, but most importantly whatever is decided, it would be good to document the expected behavior.


Thanks,



Rob


 


 


 




From: Jiangyuanlong <[email protected]>
Sent: 08 January 2020 12:39
To: Rob Wilton (rwilton) <[email protected]>;[email protected]
Cc: [email protected]
Subject: RE: [CCAMP] Discussion on Flex-E YANG model structure [was  RE:CCAMPDigest, Vol 139, Issue 5]




 


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:[email protected]]
Sent: Monday, January 06, 2020 8:19 PM
To: Jiangyuanlong <[email protected]>;[email protected]
Cc: [email protected]
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 <[email protected]>On Behalf Of Jiangyuanlong
Sent: 06 January 2020 02:20
To: [email protected]
Cc: [email protected]
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:[email protected]]On Behalf Of [email protected]
Sent: Friday, January 03, 2020 6:36 PM
To: [email protected]
Cc: [email protected]
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.




[Xb03] For the four choices, I prefer to select (1).  It gives more check in consistency between both entries.

           And considering the NDMA architecutre,   it's better IMHO to consider the entry in /interfaces/interface as configuration data and the entry in /flex-e/group/client-interface  as operational data.




Thanks,
Rob

 


BR


Xiaobing Niu

_______________________________________________
CCAMP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ccamp