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

[Jiangyuanlong <[e-mail]>]

Dear Daniele,

Thanks a lot for providing us a guidance on how to progress.
Definitely, we can put together a table with all the agreements (based on the FlexE IA, some basic attributes in FlexE Group, FlexE client, and PHY respectively should not be very controversial).
Regarding how to organize these components into a FlexE module, we need to have consensus on some important topics:

-          Shall we augment from interface or some other IETF modules? Or build a totally independent new FlexE model?

-          Shall we incorporate all G.8023 management information on FlexE? Or just expose the necessary information?

-          What is the relationship between FlexE Group and its FlexE clients? Are they Hierarchical or in parallel?

-          Shall we just model a single FlexE Group (together with its FlexE clients and PHYs)?  Or model all FlexE Groups and FlexE Clients as a whole?

BTW, even the management requirements are different in draft-wang-ccamp-flexe-control-analysis-03 from draft-jiang-ccamp-flexe-ifmps-00, perhaps we need some consensus on the requirements firstly.

Best regards,
Yuanlong


From: Daniele Ceccarelli [mailto:[e-mail]]
Sent: Thursday, November 21, 2019 7:45 PM
To: Jiangyuanlong <[e-mail]>; [e-mail]; [e-mail]
Subject: RE: [CCAMP] Comments on draft-jiang-ccamp-flexe-ifmps & draft-jiang-ccamp-flexe-yang

Authors,

Instead of providing a table describing what’s wrong in the other draft, could you please spend some effort in putting together a table with the agreements and the disagreements?
I would like to start working on the agreements, see if there is enough meat to put together a very basic joint draft and then we can discuss disagreements one by one (and maybe find tradeoffs).

I would like to avoid calling for consensus for one or the other because, like in politics, I don’t think people agree will each and every statements made by one or the other party.
Identifying a common part and building on top of it item by item is to me the best way forward.

Do you thinks this is possible?
Thanks,
Daniele

From: CCAMP <[e-mail]<mailto:[e-mail]>> On Behalf Of Jiangyuanlong
Sent: den 21 november 2019 09:16
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [CCAMP] Comments on draft-jiang-ccamp-flexe-ifmps & draft-jiang-ccamp-flexe-yang

Hi Qilei，

Thank you much for all the comments, please see my replies inline.

Thanks,
Yuanlong

From: CCAMP [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Thursday, November 21, 2019 9:41 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [CCAMP] Comments on draft-jiang-ccamp-flexe-ifmps & draft-jiang-ccamp-flexe-yang


Dear Authors,



Personally speaking, I think there are some drawbacks in your model.

[Jiang] Would appreciate much if you can provide a similar table as we provided in slide 15 & 16 of slides-106-ccamp-7-yang-data-model-for-flexe-interface-management-01.

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.

[Jiang] Agreed, and that is our intent.

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.

[Jiang] Definitely, unavailable slots can be marked in flexe-slot-status (a leaf of calendar-slot-list) in our model. Actually, this model provides a clear status indication of {used, unused, unavailable} for each slot. On the contrary, in your model, unused slots are not in bookkeeping, thus unused slots can only be determined after traversing all the flexe-clients (deduct the used slots for each client from the overall calendar slots) which is not efficient.

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.

[Jiang] slide 10 in slides-106-ccamp-7-yang-data-model-for-flexe-interface-management-01 answers this question. It seems your model cannot align with FlexE 1.0 & FlexE 1.1, as FlexE instance was first introduced in FlexE 2.0. Furthermore, exposing all management information defined in G.8023 Amd1 as you proposed is discouraged even in ITU-T SG15.

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.

[Jiang] As we already replied on the site, it is just an introduction of OIF defined overhead for calendar switching, see FlexE 2.0 and 2.1. There is nothing to be invented.

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.

[Jiang] IMO, both case 1 and case 2 as you describe are optional solutions. Under what circumstance that a controller needs to know details of CCA & CCB (maybe quite a large table as each slot needs an item respectively) and configure both of them will be a more valid use case (in our analysis, writing to CCA & CCB at the same time will cause loss of traffic on all the FlexE clients, thus should best be avoided). As an optional solution for your case 1, a controller/NMS can provide a single initial calendar configuration for the device, and the device then installs them on calendar A directly (in initiation as you says). If there is any device which happens to be switched to CCB, it must be capable to be initialized to CCA or switched back to CCA by an RPC command, that will be much simpler compared with managing both CCA & CCB on the controller/NMS as your model suggested (while also taking the risk in loss of traffic on all existing FlexE clients).





[cid:image003.png@01D5A14C.783010A0]



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.

[Jiang] transport network is typically bidirectional asymmetric, even in future if asymmetric bandwidth is needed like in PON network, the module can be easily augmented to add RX attributes (IMHO, we don’t see such a need yet).

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