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

From: <[email-masked]>
Date: Mon, 9 Dec 2019 21:08:28 +0800 (CST)

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.

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

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.

Thanks

Qilei (on behalf of Xiaobing)

原始邮件

发件人：RobWilton(rwilton) <[email-masked]>
收件人：Jiangyuanlong <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2019年11月27日 01:34
主 题 ：Re: [CCAMP] Thoughts on Flex-E YANG models

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

Hi Yuanlong,

Okay.  I think that we seem to be in rough alignment on the overall structure.

I think that the next steps are to wait for comments from Xiaobing and Qilei to see if this top level structure would be an acceptable starting point to then try on the detailed configuration.

In case it helps, the updated YANG is here: https://github.com/rgwilton/flex-e-yang/blob/master/ietf-if-flex-e.yang

Thanks,
Rob

From: Jiangyuanlong <[email-masked]>
Sent: 26 November 2019 12:39
To: Rob Wilton (rwilton) <[email-masked]>; [email-masked]
Subject: RE: Thoughts on Flex-E YANG models

Rob,

Sometimes we do things faster than we think;)

Please see my further comments inline prefixed with[Jiang2].

Thanks,

Yuanlong

 

From: Rob Wilton (rwilton) [mailto:[email-masked]]
Sent: Tuesday, November 26, 2019 7:24 PM
To: Jiangyuanlong <[email-masked]>;[email-masked]
Subject: RE: Thoughts on Flex-E YANG models

Sorry, I accidentally hit send on my last email before typing anything!

Please see some further comments [RW] inline …

From: Jiangyuanlong <[email-masked]>
Sent: 26 November 2019 03:05
To: Rob Wilton (rwilton) <[email-masked]>;[email-masked]
Subject: RE: Thoughts on Flex-E YANG models

Rob,

I believe we are quite aligned in the abstract structure of the FlexE model.

Please see my further comments inline prefixed with[Jiang1].

Thanks again,

Yuanlong

From: Rob Wilton (rwilton) [mailto:[email-masked]]
Sent: Monday, November 25, 2019 11:40 PM
To: Jiangyuanlong <[email-masked]>;[email-masked]
Subject: RE: Thoughts on Flex-E YANG models

Hi Yuanlong,

Please see [RW] comments inline …

From: Jiangyuanlong <[email-masked]>
Sent: 25 November 2019 03:54
To: Rob Wilton (rwilton) <[email-masked]>;[email-masked]
Subject: RE: Thoughts on Flex-E YANG models

Hi Rob,

Thank you  a lot for your comments, they are very helpful.

Please see my further comments inline.

Cheers,

Yuanlong

From: CCAMP [mailto:[email-masked]]On Behalf Of Rob Wilton (rwilton)
Sent: Friday, November 22, 2019 11:01 PM
To: [email-masked]
Subject: [CCAMP] Thoughts on Flex-E YANG models

Hi,

I have some general thoughts on modelling Flex-E in YANG that may help the authors converge.  These comments mostly relate to what I would call the overall shape of the YANG model rather specific configuration
 (which I think can probably be sorted out once the shape has been agreed).

1.     Flex-E groups should be identified by their group-number (both models seem to do this, but the group number seems to be optional in one model)

2.     The configuration to identify the bonded phys should be under the flex-e group (both models do this).

[Jiang] Agreed to both...

3.     In the flex-e group’s bonded-phy interface configuration list, bonded-phy interface list entries could be keyed either by the bonded phy interface name, or the flex-e phy number. 

a.     I would suggest that the bonded-phy interface name is the more meaningful identifier to clients.  

[Jiang] Just to be clear, are your saying that the list of flexe-phy should be keyed by the interface name? I think in our model, current
 key “flexe-phy-if” is exactly the PHY interface name, as shown in RFC 8343:

“     typedef interface-ref {

       type leafref {

         path "/if:interfaces/if:interface/if:name";

”

[RW]

Yes.

b.     Either way, the entries should also indicate the binding to the bonded-phy interface (e.g. by an interface-ref – both models seem to do this).

4.     The configuration required to define the client interfaces associated with a flex-e group should be under the flex-e group list entry, based on the assumption that that 16 bit client id must be unique within the group rather than across
 groups.

[Jiang] Totally agreed...

5.     In the flex-e group’s client interface configuration list, client interface list entries could be keyed either by the client interface name, or the client id.

a.     Again, I would suggest that using the client interface name is the more meaningful identifier for clients.

[Jiang] Earlier we already planned to use “flexe-client-if” as the key to flexe-client-list. Could this resolve your comment?

[RW]

Yes, I think so.  It would be an interface-ref, similar to bonded-phy interface-ref.

However, I think that there is probably a slight difference in semantics:

In the case of the interface-ref for bonded phys, semantically it should probably be “require-instance true” (which is the default behaviour).  I.e. for the flex
 group configuration to be valid, it makes sense for the referenced bonded-phy interfaces to also exist in the configuration.

But in the case of the interface-ref for client interfaces, I think that it should be “require-instance false”...  This is because the flex-e client interface configuration
 defines the parameters to create the client interface but should not require that the client interface to exist in the configuration at the same time (even if that may often be the case).

[Jiang1] Agreed. My colleague Italo also expressed such an opinion during ITU-T Q14/SG15 interim meeting not long ago.

b.     Either way, the entries should also indicate the binding to the client interface (by interface-ref – both models seem to do this).

6.     Client interfaces should be modelled as regular interfaces, and use the normal iftype for Ethernet interfaces, i.e. the dubiously named iftype:ethernetCsmacd.  Without using this type regular Ethernet YANG configuration (e.g. as defined
 in 802.3.2) won’t work properly.

a.     I don’t think that there should be flex-e specific configuration under the client interface itself, instead, the flex-e specific configuration should be defined as part of the group + client interfaces.

[Jiang] Agreed to bullet a). But I have some doubts whether we can use the normal iftype for Ethernet interfaces directly. As FlexE Client
 includes only a thin MAC layer, while PHY layer is decoupled into the FlexE PHY, FlexE client management should be simpler than the regular Ethernet YANG configuration, furthermore, it seems to me all the YANG models defined in 802.3 or 802.2 more or less
 include some PHY configuration which cannot be applied to a FlexE client. Nevertheless, we look forward to seeing more discussions on this topic.

[RW]

From the rest of the system perspective, a client interface really should look/feel like a regular physical Ethernet interface, and I think that the majority of
 the 802.3.2 configuration/statistics should apply.  Auto-neg, duplex, speed shouldn’t be configurable, but then they can’t be configured on most higher speed optical interfaces anyway.  I would have thought that the rest of the module should apply (otherwise
 this Ethernet configuration would need to be duplicated in another module, which isn’t ideal).

[Jiang1] If a reference model can work, that will be better for sure.

But I think that the main issue to resolve is whether Flex-E group configuration is global or scoped to a FlexE group interface.  I can see pros and cons both ways:

1.     Putting the configuration under an FlexE group interface seems like a slightly artificial construct.

2.     However, this does mirror how LAG interfaces are represented (at least in our vendor model), and in some ways FlexE interfaces could be considered to be like an L1 LAG interface.  However, in the LAG case, the LAG interface can forward
 traffic, where as for FlexE groups, this would not be the case.

3.     There is probably a natural binding between a FlexE group and the client interfaces that closely relates to the parent child relationship between an interface and sub-interface.  E.g. disabling a FlexE group should have the effect of
 disabling each FlexE client interface.

4.     My overall feeling is that representing the FlexE groups as a type of interface seems like a reasonable configuration model.

[Jiang] Totally agreed...

[RW]

Note, I have made an assumption here that it is reasonable to represent the L1 layer of an interface as an entry in if:interfaces/if:interface.  It is worth noting
 that not all configuration/state in ietf-interfaces would apply sensibly to an L1 interface representation.  In particular, none of the statistics would seem to apply to the physical layer. 

[Jiang1] That is true indeed.

Anyway, hopefully these comments are useful to help the two sets of authors converge towards a common model.  I have other suggestions on the specific models but would suggest solving the big picture issues
 first.

[Jiang] Very useful indeed, we look forward to your further suggestions on the models.

[RW]

Thanks.  It would also be useful to see comments from other members of the WG, in particular, the authors of the draft-xiaobn-ccamp-flexe-yang-mod-03.

[Jiang1] Yes, we also hope to see more inputs from the WG.

In case it helps, here is the pyang tree output of the structure that I believe is most suitable to represent Flex-E interfaces:

module: ietf-if-flex-e

  augment /if:interfaces/if:interface:

    +--rw flex-e

       +--rw group

          +--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

 

[Jiang1] Not sure we need both “flex-e” and “group” the same time (a little redundant in the structure IMO), otherwise I believe we are
 fully aligned in the overall structure.

[RW]

So this is a relatively minor point, and I could go either way on this.

From my perspective it is ‘nice’ from a modelling perspective if the configuration for a particular feature is under a single container:

-       It makes it easier to either just get that configuration, or to filter it out if it is not wanted.

-       It is easier for clients to immediately relate the configuration back to a particular feature/protocol.

E.g., if it is plausible that there is any need for any device-global flex-e configuration, then I would propose putting that under a single top-level flex-e container...

Equally, if there could ever be flex-e configuration on a flex-e-group interface that isn’t specific to the group then having the extra layer in the hierarchy is cleaner.  However, that this seems unlikely
 in this case, given that the interface represents a flex-e group …

[Jiang2] Yes, we had considered this option too. BTW, if such global inter-group FlexE configurations are found later, we can still follow
 this approach.

Another choice could be to only have a single layer of hierarchy, but call the top level container “flex-e” rather than “flex-e-group”, e.g. :

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

[Jiang2] Currently, I think this is a somewhat more graceful approach.

 

I don’t know whether phy-number and id should be mandatory.  I.e. always defined, or whether it is feasible that these could be automatically allocated by the device.

[Jiang1] phy-number and client id are mandatory. They can be configured in most use cases, but for static configuration as described in
 FlexE IA, they can be fixed (i.e., determined by the device), that means, they may be read-only.

[RW]

Okay, so from a YANG perspective, I think that makes them “mandatory false”, since they don’t have to be configured.  The description statements should make it clear
 that these fields must be provided in the operational datastore.

[Jiang2] Points taken. We can discuss more details on respective attributes if the WG could have an agreements on the overall structure.

Thanks,
Rob

Of course, I have excluded any specific configuration options.  I would suggest trying to get agreement on the overall structure (i.e. the shape of the YANG model) first.

The YANG model that this is built from is available at:https://github.com/rgwilton/flex-e-yang/blob/master/ietf-if-flex-e.yang

Regards,
Rob

 

Regards,
Rob

---

From: Italo Busi <[email-masked]>
Date: Mon, 9 Dec 2019 15:03:27 +0000

Hi Qilei,

Thanks for your reply. See some comments of mine in line below

Italo

Italo Busi
Principal Optical Transport Network Research Engineer
Huawei Technologies Co., Ltd.
Tel : +39 345 4721946
Email : [email-masked]

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

From: [email-masked] [mailto:[email-masked]]
Sent: lunedì 9 dicembre 2019 14:08
To: [email-masked]; Jiangyuanlong <[email-masked]>
Cc: [email-masked]
Subject: Re: [CCAMP] Thoughts on Flex-E YANG models

Hi,

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.

[[Italo Busi] ] With the YANG model skeleton proposed by Rob you can create a FlexE Group with zero, one or more FlexE clients and, later on, you can add/remove FlexE clients from the list at any time

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.

[[Italo Busi] ] Considering that FlexE client is an interface and not a switching layer, this requirement looks a bit strange to me
Moreover, when if you “move” the FlexE client from one group to another, its calendar slots need to be re-configured since there is no guarantee that the two groups support the same set of calendar slots nor that the calendar slots allocated to the FlexE client on the old group are available on the second group
Using the YANG model skeleton proposed by Rob, you can remove the old FlexE client (which contains the set of calendar slots used on the old FlexE group), create a new FlexE client (with the calendar slots to be used on the new FlexE group) and point to the same interface as the old FlexE client

[[Italo Busi] ] One advantage of modelling FlexE Group as an interface is to allow a common management pattern between LAG and FlexE, which would result is simplification of FlexE management. What are the drawbacks?
I also do not understand your argument about that “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”. In RFC8343, the type leaf references RFC2863 ifType. Looking at the IANAifType-MIB DEFINITIONS, I can find many examples which are similar to the FlexE Group case:

https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib

Thanks

原始邮件
发件人：RobWilton(rwilton) <[email-masked]<mailto:[email-masked]>>
收件人：Jiangyuanlong <[email-masked]<mailto:[email-masked]>>;[email-masked] <[email-masked]<mailto:[email-masked]>>;
日 期 ：2019年11月27日 01:34
主 题 ：Re: [CCAMP] Thoughts on Flex-E YANG models
_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp
Hi Yuanlong,

Thanks,
Rob

From: Jiangyuanlong <[email-masked]<mailto:[email-masked]>>
Sent: 26 November 2019 12:39
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Thoughts on Flex-E YANG models

Rob,

Thanks,
Yuanlong

From: Rob Wilton (rwilton) [mailto:[email-masked]]
Sent: Tuesday, November 26, 2019 7:24 PM
To: Jiangyuanlong <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]>
Subject: RE: Thoughts on Flex-E YANG models

From: Jiangyuanlong <[email-masked]<mailto:[email-masked]>>
Sent: 26 November 2019 03:05
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]>
Subject: RE: Thoughts on Flex-E YANG models

Rob,

Thanks again,
Yuanlong

From: Rob Wilton (rwilton) [mailto:[email-masked]]
Sent: Monday, November 25, 2019 11:40 PM
To: Jiangyuanlong <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]>
Subject: RE: Thoughts on Flex-E YANG models

Hi Yuanlong,

From: Jiangyuanlong <[email-masked]<mailto:[email-masked]>>
Sent: 25 November 2019 03:54
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]>
Subject: RE: Thoughts on Flex-E YANG models

Hi Rob,

Cheers,
Yuanlong

From: CCAMP [mailto:[email-masked]]On Behalf Of Rob Wilton (rwilton)
Sent: Friday, November 22, 2019 11:01 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [CCAMP] Thoughts on Flex-E YANG models

Hi,

I have some general thoughts on modelling Flex-E in YANG that may help the authors converge.  These comments mostly relate to what I would call the overall shape of the YANG model rather specific configuration (which I think can probably be sorted out once the shape has been agreed).

[Jiang] Just to be clear, are your saying that the list of flexe-phy should be keyed by the interface name? I think in our model, current key “flexe-phy-if” is exactly the PHY interface name, as shown in RFC 8343:

b.     Either way, the entries should also indicate the binding to the bonded-phy interface (e.g. by an interface-ref – both models seem to do this).
4.     The configuration required to define the client interfaces associated with a flex-e group should be under the flex-e group list entry, based on the assumption that that 16 bit client id must be unique within the group rather than across groups.
[Jiang] Totally agreed...

In the case of the interface-ref for bonded phys, semantically it should probably be “require-instance true” (which is the default behaviour).  I.e. for the flex group configuration to be valid, it makes sense for the referenced bonded-phy interfaces to also exist in the configuration.

But in the case of the interface-ref for client interfaces, I think that it should be “require-instance false”...  This is because the flex-e client interface configuration defines the parameters to create the client interface but should not require that the client interface to exist in the configuration at the same time (even if that may often be the case).

b.     Either way, the entries should also indicate the binding to the client interface (by interface-ref – both models seem to do this).
6.     Client interfaces should be modelled as regular interfaces, and use the normal iftype for Ethernet interfaces, i.e. the dubiously named iftype:ethernetCsmacd.  Without using this type regular Ethernet YANG configuration (e.g. as defined in 802.3.2) won’t work properly.
a.     I don’t think that there should be flex-e specific configuration under the client interface itself, instead, the flex-e specific configuration should be defined as part of the group + client interfaces.
[Jiang] Agreed to bullet a). But I have some doubts whether we can use the normal iftype for Ethernet interfaces directly. As FlexE Client includes only a thin MAC layer, while PHY layer is decoupled into the FlexE PHY, FlexE client management should be simpler than the regular Ethernet YANG configuration, furthermore, it seems to me all the YANG models defined in 802.3 or 802.2 more or less include some PHY configuration which cannot be applied to a FlexE client. Nevertheless, we look forward to seeing more discussions on this topic.
[RW]
From the rest of the system perspective, a client interface really should look/feel like a regular physical Ethernet interface, and I think that the majority of the 802.3.2 configuration/statistics should apply.  Auto-neg, duplex, speed shouldn’t be configurable, but then they can’t be configured on most higher speed optical interfaces anyway.  I would have thought that the rest of the module should apply (otherwise this Ethernet configuration would need to be duplicated in another module, which isn’t ideal).
[Jiang1] If a reference model can work, that will be better for sure.

But I think that the main issue to resolve is whether Flex-E group configuration is global or scoped to a FlexE group interface.  I can see pros and cons both ways:
1.     Putting the configuration under an FlexE group interface seems like a slightly artificial construct.
2.     However, this does mirror how LAG interfaces are represented (at least in our vendor model), and in some ways FlexE interfaces could be considered to be like an L1 LAG interface.  However, in the LAG case, the LAG interface can forward traffic, where as for FlexE groups, this would not be the case.
3.     There is probably a natural binding between a FlexE group and the client interfaces that closely relates to the parent child relationship between an interface and sub-interface.  E.g. disabling a FlexE group should have the effect of disabling each FlexE client interface.
4.     My overall feeling is that representing the FlexE groups as a type of interface seems like a reasonable configuration model.
[Jiang] Totally agreed...
[RW]
Note, I have made an assumption here that it is reasonable to represent the L1 layer of an interface as an entry in if:interfaces/if:interface.  It is worth noting that not all configuration/state in ietf-interfaces would apply sensibly to an L1 interface representation.  In particular, none of the statistics would seem to apply to the physical layer.
[Jiang1] That is true indeed.

Anyway, hopefully these comments are useful to help the two sets of authors converge towards a common model.  I have other suggestions on the specific models but would suggest solving the big picture issues first.
[Jiang] Very useful indeed, we look forward to your further suggestions on the models.
[RW]
Thanks.  It would also be useful to see comments from other members of the WG, in particular, the authors of the draft-xiaobn-ccamp-flexe-yang-mod-03.

module: ietf-if-flex-e

[Jiang1] Not sure we need both “flex-e” and “group” the same time (a little redundant in the structure IMO), otherwise I believe we are fully aligned in the overall structure.

[RW]

Equally, if there could ever be flex-e configuration on a flex-e-group interface that isn’t specific to the group then having the extra layer in the hierarchy is cleaner.  However, that this seems unlikely in this case, given that the interface represents a flex-e group …
[Jiang2] Yes, we had considered this option too. BTW, if such global inter-group FlexE configurations are found later, we can still follow this approach.

module: ietf-if-flex-e

[Jiang1] phy-number and client id are mandatory. They can be configured in most use cases, but for static configuration as described in FlexE IA, they can be fixed (i.e., determined by the device), that means, they may be read-only.

[RW]
Okay, so from a YANG perspective, I think that makes them “mandatory false”, since they don’t have to be configured.  The description statements should make it clear that these fields must be provided in the operational datastore.
[Jiang2] Points taken. We can discuss more details on respective attributes if the WG could have an agreements on the overall structure.

Thanks,
Rob

Regards,
Rob

Regards,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 9 Dec 2019 15:46:10 +0000

Hi Qilei,

Thanks for your comments.  Please see inline …

From: [email-masked] <[email-masked]>
Sent: 09 December 2019 13:08
To: Rob Wilton (rwilton) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re:[CCAMP] Thoughts on Flex-E YANG models

Hi,

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

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

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

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.

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

Thanks,
Rob

Thanks

原始邮件

Thanks,
Rob

Rob,

Thanks,
Yuanlong

Rob,

Thanks again,
Yuanlong

Hi Yuanlong,

Hi Rob,

Cheers,
Yuanlong

Hi,

module: ietf-if-flex-e

[RW]

module: ietf-if-flex-e

[RW]

Thanks,
Rob

Regards,
Rob

Regards,
Rob

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 10 Dec 2019 16:23:24 +0000

Hi Qilei,

I agreed to the comments from Italo and Rob. Furthermore, I have some more comments inline.

Thanks,
Yuanlong

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, December 9, 2019 9:08 PM
To: [email-masked]; Jiangyuanlong <[email-masked]>
Cc: [email-masked]
Subject: Re:[CCAMP] Thoughts on Flex-E YANG models

Hi,

[Jiang] We believe the application scenarios in FlexE 2.1 are all covered, currently no other applications are discussed in your analysis, so please give some details of the applications if you think there is a need to address them.

[Jiang] The FlexE IA does not describe how to configure the FlexE group and FlexE client, nor does it describe any switching of FlexE client from one FlexE group to another FlexE group. The slots belong to a particular FlexE group and cannot be switched, so maybe you are saying the MAC frames of a FlexE client could be associated with two different FlexE groups. In that case, our models include a leaf node flexe-client-if with the type of if:interface-ref, and it is quite easy to be associated with different FlexE groups upon reconfiguration (as a result, a change of the parent FlexE group is realized).

[Jiang] I think there is a misunderstanding in your saying “this interface only exists in the Ethernet PCS module”.  The YANG abstraction of a FlexE group interface includes both bonding PHYs and its FlexE clients, thus goes beyond the Ethernet PCS layer. Actually, all FlexE logics are in the PCS layer according to FlexE IA, but we still need to configure those FlexE attributes.

Thanks

原始邮件

Thanks,
Rob

Rob,

Thanks,
Yuanlong

Rob,

Thanks again,
Yuanlong

Hi Yuanlong,

Hi Rob,

Cheers,
Yuanlong

Hi,

module: ietf-if-flex-e

[RW]

module: ietf-if-flex-e

[RW]

Thanks,
Rob

Regards,
Rob

Regards,
Rob