[CCAMP] 答复: Reply: Thoughts on Flex-E YANG models

["Yangfan (Shirley)" <[e-mail]>]

Hi Rob and WGs,
See the inline comments begin with [Fan].
Thanks!

Cheers,
Fan

发件人: Rob Wilton (rwilton) [mailto:[e-mail]]
发送时间: 2019年11月26日 19:51
收件人: Yangfan (Shirley) <[e-mail]>; [e-mail]
主题: RE: Reply: [CCAMP] Thoughts on Flex-E YANG models

Hi Fan,

I’m not sure that I want to discuss the specific configuration yet for a couple of reasons:
(1)    I believe that we are more likely to get alignment in the models if we can break the discussion down into stages, focus on getting agreement on the overall structure, before then working on the detailed configuration.
(2)    I will probably need to refresh my memory on some of the flex-e configuration specifics to be able to give helpful precise feedback.
[Fan] Totally agreed. After the rough alignment, firstly let’s see the feedback from others in WG. And the detailed discussion is the next step.

However, I am willing to share some of the principles that I would generally apply:
(1)    It is useful to identify what is likely to be the minimal configuration required to configure flex-e.  That applies both to what is available in the Flex-E specs now, and also how it is likely to evolve over time.  E.g. if you look at regular Ethernet, speed, duplex, flow-control used to be manually configured, but overtime that configuration has been superseded by auto-negotiation (but the ability to manually set the parameters is still useful, and hence preserved in the models).  If the Flex-E feature gains market traction, then I would expect that same thing to happen here.  I.e. aspects of the configuration that must be configured manually today may well end up being negotiated by protocol in future.
(2)    Even if in future, or in some implementations, some of the functionality can be negotiated dynamically, it is still generally reasonable to allow clients to manually configure particular aspects of the configuration covered by the protocol.  Some operators want more direct control over their configuration than others.
[Fan] Agree with you. Both the negotiation and manual approach are the scenarios should be covered. Let’s discuss this after we get alignment of the structure in WG.
(3)    We also what to ensure that the feature to be deployable today.  If multiple vendors require similar configuration then putting that in the standard model improves interoperability (by using the same paths/names/types for the equivalent configuration).
(4)    Use of YANG features, at an appropriate level of granularity, but be used to make parts of the model optional to implement.
[Fan] So, comments from other vendors are strongly welcomed and appreciated.
Thanks,
Rob





From: Yangfan (Shirley) <[e-mail]<mailto:[e-mail]>>
Sent: 26 November 2019 02:02
To: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Reply: [CCAMP] Thoughts on Flex-E YANG models

Hi Rob,

Thanks for your quick respond.  To check the YANG models from the perspective of YANG doctor would help a lot in the discussion.
Another question I would like to ask your opinion is about the attributes such as local-phy-interface, remote-phy-interface, expected-group-number, expected-phy-map, expected-cal-cfg, tx-calendar, rx-calendar etc. These terminologies are defined and introduced from ITU-T G.8023. I understand there could be some signaling negotiation between two nodes in the data plane. However, I don’t think it is appropriate to extract YANG model in a Tx/Rx approach. Once the information is set from controller, data plane of nodes can decide whether FlexE works or how it works. It is not necessary to assign the remote node information to local node.
I’d appreciate that if you can have some comments on this particular part, which is one of the big differences of the two models.
Thanks a lot.

Cheers,
Fan


发件人: Jiangyuanlong
发送时间: 2019年11月25日 11:54
收件人: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
主题: 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:[e-mail]] On Behalf Of Rob Wilton (rwilton)
Sent: Friday, November 22, 2019 11:01 PM
To: [e-mail]<mailto:[e-mail]>
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";
”
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?

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.

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.

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.

Regards,
Rob