CCAMP working group agenda - IETF 113
Friday, March 25, 2022
10:00-12:00 (Meeting time) - 9:00-11:00 (UTC) Friday Morning Session I

Presentation Start Time Duration Information

0 10:00 15 Title: Administrivia - WG Status - Reporting on WG drafts not being presented - Milestones Update - Charter Update
Presenter: Chairs
[Daniele Ceccarelli] draft-ietf-ccamp-dwdm-if-param-yang-06 draft is expired. What are the plans?
[Gert Grammel] Waiting for other drafts to progress (layer 0 types…) to materialize

1 10:15 15 Title: A YANG Data Model for Optical Impairment-aware Topology
Draft: https://datatracker.ietf.org/doc/draft-ietf-ccamp-optical-impairment-topology-yang
Presenter: Sergio Belotti

(regarding page 7, empty type issue)     

[Robert Wilton] It seems an overengineering (to set the empty type), don’t know the detailed case yet. If the expectation is sometimes you do not return the value, don’t make it mandatory, put it optional. If the expecation is the service should always return the value, put it as mandatory. If sometimes the service is expected to return the value but it does not give, you mean just did not send it. I am not sure if it is the problem you want to solve here. It looks a generic YANG issue, and we should target on a generic solution. Otherwise you seem to be overengineering to a specific problem.
[Daniele Ceccarelli] Is it already discussed in Netmod?
[Robert Wilton] Not recently I can think of, it came in the discussions of NMDA architecture, that the text said the service is allowed not to return a data or similar scenarios. If you don’t send the value, then you have a case where you don’t receive the expected value. The point is that this should be a generic question to Netmod, and see what the comments are.
[Sergio] Good observation, it was a problem detected during the implementation. If the expected value is not known, it’s a problem for implementation. So we try to solve in parallel with the description in the draft. This would be appearently a good solution from experimental field.
[Daniele Ceccarelli] It is (best from experimental), the current point is it also needs to be solved in a general way.
[Sergio Belotti] Agree, but in the meantime we also request for solution.
[Robert Wilton] If you raise this in the netmod areas, hopefully it can be discussed and concluded quickly. If the proposal is found right way to deal with, then we are perfect. Otherwise if the document is shipped to YDR, it would be considered as a unusual use of YANG.
[Daniele Ceccarelli] We can raise the question to other WGs, we know some of you are active in Netmod. If you think we can raise the problem as a WG, we can also do in this way. In either way we encourage to discuss in netmod and look for a generic solution. Let us know how you want to go.
[Italo Busi] I agree to raise this to the netmod and get some advices. The issue we are facing is the need to distinguish the case where the attribute should not be reported from the case where the attribute should be reported but the value to report is unknown.
[Daniele Ceccarelli] May be better to report the problem with preference rather than make it open.
[Robert Wilton] Please also highlight the distinction between different options.

2 10:30(40) 10 Title: A YANG Data Model for Layer 0 Types
Draft: https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-rfc9093-bis-00.html
Presenter: Sergio Belotti

[Daniele Ceccarreli] Good idea to have a bis. While other WG (teas) prefer to have updated draft. Please John confirm it is the right approach.
[John Scudder] You could do either way, but I prefer a bit to do bis as you can put everything in one place.
[Robert Wilton] You can complete replace the whole YANG model through a bis, so recommend to do a bis.
[Fatai Zhang] Discussion in IETF 112 determines to have a bis and happy to see ADs confirmation.
[Julien Meuric] (from chat) For YANG modules, a bis seems more suitable.
[Robert Wilton] (from chat) I’ve only seen/suggested doing an update when the original RFC contains multiple YANG models and only a subset of YANG modules are being updated in a backwards compatible way (i.e., the other modules are not being changed).
[Dieter Beller] (from chat) Makes perfectly sense!

3 10:40(48) 15 Title: OTN Slicing Draft
Draft: https://datatracker.ietf.org/doc/draft-zheng-ccamp-yang-otn-slicing
Presenter: Aihua Guo
[Fatai Zhang] Still any open issue left from Igor’s comments on the list?
[Aihua Guo] The most important one ‘the necessity of OTN slicing’ is addressed and concluded. There are a few other questions about ‘slicing’, but not OTN-specific and should be addressed by teas. For example one question could support just P2P or also P2MP/MP2MP.
[Daniele Ceccarreli] Teas presented the network slicing draft and mentioned some concerns from ccamp. Please have joint discussion and make sure all of them are properly handled.

4 10:55(02) 15 Title: Use of Ancestor Function in YANG and update on Flexi-Grid work
Draft: https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexigrid-yang/
Draft: https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexigrid-media-channel-yang-03
Presenter: Daniel King

[Robert Wilton] just personal. If the existing works can give the widest exhaustive possibilities. You could do the ‘clever’ thing with technically allowed. To a bigger scope we may want to support this by putting a new YANG issue tracker. I need more exhaustive check and context to understand. Keep it correct and simple are the top importances.
[Daniele Ceccarelli] This suggestion is just opposite… Let’s do what Rob suggested. This is not a document we need to publish tomorrow, so we have time and it’s longer-term change. Maybe we can wait for other experts/WG.
[John Scudder] Agree to Daniele to wait. The proposal is not wrong, but Robert is correct not to put ourselves into envelop. I am okay if the timeline allows to wait for the tool to catch up.
[Robert Wilton] I need to further look into this. Many proposals bout the Xpath usage are there. The usage of ‘ancestor’ here is just a concise way to use Xpath. The tool is natually not supporting using this, they just support normal use of Xpath. Another suggestion will be input to YANG guidelines, and just make sure people have sufficient discussions before decision.
[Daniele Ceccarelli] That’s great feedback and we will work with you. We will highlight this with some related documents in teas as well.
[Italo Busi] RFC8407 is okay to use ancestor but only not supported by the tools. We can do in old ways first and wait for changes in the tool.
[Aihua Guo] Agree with Italo.
[Daniel King] (from chat) Thanks Rob, all. We will follow up with NETMOD and wider discussion.

5 11:10(17) 10 Title: YANG Data Models for requesting Path Computation in Optical Networks
Draft: https://datatracker.ietf.org/doc/html/draft-gbb-ccamp-optical-path-computation-yang-00.html
Presenter: Italo Busi

[Haomian Zheng] To clarify/check the model dependences, does this work depend on models besides layer 0 and 1 types?
[Italo Busi] It also depends on the generic path computation.
[Haomian Zheng] The number of documents can be decided by the dependency. Given the clarification we can have two, one for OTN and the other for WDM. In each document we can have multiple modules.
[Daniele Ceccarreli] It’s good to split the layer 0 and layer 1.

6 11:20(24) 10 Title: A YANG Data Model for Network Inventory
Draft: https://www.ietf.org/archive/id/draft-yg3bp-ccamp-network-inventory-yang-00.html
Presenter: Chaode Yu

[Daniele Ceccarelli] This is another draft we request coordination from other WG (teas, opsawg). I did not remember this work presented in other WGs. If they are happy to progress this work as it is in CCAMP, I think we can make a poll. Is my understanding correct that the work can be proceeded in ccamp WG?
[Chaode Yu] Yes, in last meeting the opsawg agreed to have this work in ccamp and we also presented this work in the meeting. We are good to stay in the ccamp WG.
[Robert Wilton] Not reviewed this document yet. Maybe overlapping with some entities, and maybe more proper to run in ops area, but need to understand what is the scope of this document. The point is to make sufficient review and comments from the area to make the document more complete. We are not doing in this WG for very generic stuffs.
[Robert Wilton] The other thing for this is the structure. In terms of flat models, such as openconfig platform, we have only parent and their children. I think that structure may work for this problem.
[Chaode Yu] Open to the WG, please have a look and provide your suggestions. For the integration, the problem comes when the network is large and the tree structure is deep. We are having issues during integration. Please check the question we raised on the list, future discussions are welcome.
[Daniele Ceccarreli] It is possible that the work can be splitted into two, one generic in OPS and another tech-specific in ccamp.
[Robert Wilton] The selection of WG depends on where the document can be better reviewed and commented. If we forward the work to ops and get effective feedback, the WG can also handle the document as well.
[Haomian Zheng] The term inventory is used for different interpretation in opsawg. Opsawg experts are saying this work closer to ‘hardware inventory’, and are happy to see the work proceed in ccamp. From the perspective of hardware inventory, not much differences were detected among different technologies. We may not need a generic and another tech-specific.
[Aihua Guo] The scalability issue comes from the number of levels during the retrieval. The data amount is huge, but not very much related with data structure. The openconfig modules provide a single node mode so the data is not a huge amount and may not be a good reference. But, I do agree that we need a generic solution to handle it.
[Dieter Beller] I don’t see the scalability issue yet but it should be considered.

7 11:30(40) 10 Title: Application of FlexE configuration model
Draft: https://tools.ietf.org/id/draft-xiaobn-ccamp-application-flexe-cm-00.txt
Presenter: Xiaobing Niu
[Robert Wilton] Welcome back. I agree to make the merge flexE-cm, to talk about the applicability and the YANG models. Explaining how to use the YANG model in the appendix will be useful. One comment for the current structure probably in the other daft rather than this one is, I question a bit about having the FlexE client configuration under the client interface rather than having it under flexE container. My reason is that for flexE client configuration isn’t really so much abou the client interface, but related to how the flexE interfaces are set up. For exapmle you need to make sure the TS you are using are organized with other client interfaces. I think such change will help improve the consistency.
[Dieter Beller] (from chat) How is this Flex-E draft related to draft-wang-ccamp-flexe-yang-cm-02?
[Xiaobing Niu] In this work we construct examples based on that work, and summarized the requirement.
[Daniele Ceccarreli] Also suggest to merge. There is another configuration model (now expired) which is competing. Are they still competing or having a common ground? Or how do we proceed these works to make everyone happy? Just dont want to forget the other side.
[Xiaobing Niu] We were not renewing the draft-wang-ccamp-flexe-yang-cm-02 draft, but will merge it.

8 11:40(51) 10 Title: Accessing Cloud via Optical Network Problem Statement
Draft: https://www.ietf.org/id/draft-liu-ccamp-optical2cloud-problem-statement-00.txt
Presenter: Sheng Liu
[Daniel King] An EU project, Teraflow, is also working on this area, using optical for interconnecting cloud for terabits data transmission. So there is maybe some interesting requirement that we have identified in that project. Although it is research it has commercial applicability. There are operators involved in the project, and we also have some technical findings/conclusions which may be input to this work, I will post the link in the chat, and follow up with you offline.
[Haomian Zheng] IETF in this week also had some good discussion regarding the future trend for routing solutions, including the CAN BoF and RTGWG. These remind us to reevaluate the goals and objectives for the current protocol stack as well. We invite more review and comments.
[Daniel King] (from chat) TeraFlow Project - https://www.teraflow-h2020.eu/publications
There are specific requirements for optical interconnects to Cloud resources described across various documents. I’ll review your I-D and see if there is some overlap with our findings.

Adjourn 12:00