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

["Rob Wilton (rwilton)" <[e-mail]>]

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 <[e-mail]> On Behalf Of [e-mail]
Sent: 13 December 2019 09:37
To: [e-mail]
Cc: [e-mail]
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)" <[e-mail]<mailto:[e-mail]>> Mon, 09 December 2019 15:46 UTCShow header<https://mailarchive.ietf.org/arch/search/?q=xiaobing>

Hi Qilei,



Thanks for your comments.  Please see inline …



From: [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]%3e>;

Sent: 09 December 2019 13:08

To: Rob Wilton (rwilton) <[e-mail]><mailto:[e-mail]%3e>;; [e-mail]<mailto:[e-mail]>Cc: [e-mail]<mailto:[e-mail]>Subject: 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.







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 information.



[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?





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:





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


原始邮件
发件人：[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
收件人：[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>;
日 期 ：2019年12月09日 23:46
主 题 ：CCAMP Digest, Vol 139, Issue 5
Send CCAMP mailing list submissions to
    [e-mail]<mailto:[e-mail]>

To subscribe or unsubscribe via the World Wide Web, visit
    https://www.ietf.org/mailman/listinfo/ccamp
or, via email, send a message with subject or body 'help' to
    [e-mail]<mailto:[e-mail]>

You can reach the person managing the list at
    [e-mail]<mailto:[e-mail]>

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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ccamp