[CCAMP] Comments on draft-jiang-ccamp-flexe-ifmps & draft-jiang-ccamp-flexe-yang

[<[e-mail]>]

Dear Authors,




Personally speaking, I think there are some drawbacks in your model. The model should be comprehensive to support the configuring of any types FlexE capable functions/devices. For the control/management modelling work, we should not assume to much about the implementing of devices. The data model should be able to be applied in different cases. We should avoid the developing of the vendor specific model. The model we are developing should be capable of being applied to various kinds of device. The draft-xiaobn-ccamp-flexe-yang-mod is progressing towards this direction.





Comments on some PS in your slides:

PS2:Slot-status should be enumerated

Comments: I agree with this, but I suspect whether the model in draft-jiang can deal with every cases. According to the description in FlexE IA, Usually, the unavailable slots are placed at the end of each relevant sub-calendar (the highest numbered slots). Could you please give some clarification that whether your model support the unavailable slot distributed over several sub-calendars, i.e., FlexE instance? In draft-xiaobn-ccamp-flexe-yang-mod, it can be well dealt with by indicating the unavaile slots number on different instances.




PS3: how to configure FlexE? only PHY, FlexE group, FlexE client, slot mapping are mentioned in your draft.

Comments: the figure on page 4 of your slides is not from the latest version of FLEXE IA. The latest version replace the FlexE PHY number with FlexE instance number. In OIF FLEXE IA and ITU-T G.8023 Amd1, the descritpion explicitly tell that the allocation and verification of slots are done at instance level. Why does your model just manipulate at PHY level and not align with FLEXE IA and G.8023 Amd1? 

draft-xiaobn-ccamp-flexe-yang-mod aligns with FLEXE IA and G.8023 Amd1 well.




PS4: implement overhead information or not?

• A negotiation protocol between calendars is introduced

• CCA, CCB, CC, CR, CA should be data plane internal artifacts, NOT necessary to be exposed




Comments: for the first item, the negotiation protocol is not clear.

I can not find any description about this in FlexE data plane documents. Currently, only static and master/slave are described in the data plane documents, which are relevant to the negotiation between source and destination devices. It would be better to align with data plane. It is not a good idea to invent new technology for this, as this will bring confusion.




For the second item, I would say CC, CR and CA is data plane internal artifacts, but for CCA and CCB, it's not. Example below:

Please see the two figures below. For the first case, controller is responsible for deciding the initial A or B calendar configuration installed on the data plane devices; for the second case, the device is responsible for deciding A or B calendar configuration. It looks your model can only deal with the second case by assuming these calendar configuration functions implemented on the device. This is dangeous way for modelling work. The model should be comprehensive, and could deal with all kinds of devices. draft-xiaobn-ccamp-flexe-yang-mod could be applied in all the cases mentioned above.












PS6: support of bidirectional transport or not


• FlexE links are all bidirectional symmetric links so far

• Unidirectional parameters Tx/Rx should NOT be considered till the real use case




Comments: Please think about the case that the slots allocated for bidirectional transport are asymmetric.

We authors from https://tools.ietf.org/html/draft-xiaobn-ccamp-flexe-yang-mod-03 talked about this. I also confirmed this with FlexE IA editor Steve Trowbridge.




The FlexE yang model draft from you is based on the problem statement draft, so the above issues exist in the yang model as well.




Thanks

Qilei