Re: [CCAMP] CCAMP Digest, Vol 139, Issue 5

[<[e-mail]>]

hi, Rob


Please see the lines with [Xiaobing].


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


"Rob Wilton (rwilton)" <[e-mail]> Mon, 09 December 2019 15:46 UTCShow header


Hi Qilei,

Thanks for your comments. Please see inline …

From: [e-mail] <[e-mail]>;
Sent: 09 December 2019 13:08
To: Rob Wilton (rwilton) <[e-mail]>;; [e-mail]: [e-mail]: 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.

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. 

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.

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.

Thanks,
Rob






原始邮件



发件人：[e-mail] <[e-mail]>
收件人：[e-mail] <[e-mail]>;
日 期 ：2019年12月09日 23:46
主 题 ：CCAMP Digest, Vol 139, Issue 5


Send CCAMP mailing list submissions to
    [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]

You can reach the person managing the list at
    [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]
https://www.ietf.org/mailman/listinfo/ccamp