# CCAMP at IETF-114 ## Welcome 15 minutes * NOTE WELL * Scribe selection * Adrian Farrel is scribbling * Chairs suggest Haomian might like to help :-) * Italo is also writing * Agenda bashing * Administrivia * WG Status * Reporting on WG drafts not being presented * Milestones Update * Charter Update [Italo Busi] We have looked at your comments (on transport-nbi-app-statement), and plan to make an update ## Drafts 1. A YANG Data Model for Microwave Topology draft-ietf-ccamp-mw-topo-yang-03 Presenter: Scott Mansfield Length: 10 minutes [Adrian Farrel] Thank you for posting an updated verison of the draft. And I recognise that you use git for developing the draft. But could you do me a favour and keep the posted version of the working group draft alive as you go forward so that people outside the WG can see that we haven't abandoned microwave. [Scott Mansfield] Yes, and thank you for noting this. We do have a github and will also try to post the minutes of the call also on the list and not only on github to keep the WG informed about the progress [Fatai Zhang] I have an open question for discussion. There are two MW drafts, this one and RFC8432. Do we need a draft for OTN tunnels (over MW) etc.? [Scott Mansfield] If you want to do the work, then please submit it. We are trying to do this in a modular way so that "over the top" uses can achieve augmentation. 2. Framework and Data Model for OTN Network Slicing draft-ietf-ccamp-yang-otn-slicing-02 Presenter: Aihau Guo Length: 10 minutes (discussion on page 4) [Daniele Ceccarelli] It [transport-network-slice] is a common layer between other layers? What is the intention? [Aihua Guo] Yes, it is a common layer for OTN/WDM and microwave. [Daniele Ceccarelli] Like it has been done for the common types, it s would be good to extract it here so that one day if we want to build another technology slice it will be ambiguous to rely on the OTN network slide document. [Aihua Guo] Good suggestion. We will discuss this and make the decision. [Dhruv Dhody] IETF OTN slice is not currently defined. The confusion is the doc is called OTN, but the main focus is the transport slice. Perhaps rename the document. [Daniele Ceccarelli] That would work [Sergio Belotti] Partially right (from NBI perspective). But the document is also considering MPI, which is specific to OTN as far as extensions are concerned. Currently the module deals with two different things: the NBI models as well as the MPI model and the MPI model is OTN technology-specific. Separating (the transport part) from the document is a good suggestion. Currently the draft is dealing with two model, one for NBI, this is an extension in which you (Dhruv) are working and the other is for MPI [Italo Busi] Agree with Sergio. On top there is also a framework which is really OTN-specific. It is only the transport-slice YANG model that is generic. So maybe we can figure out how to split the two documents given different pieces. [Aihua Guo] Compliment from what Italo said, From yang model development perspective, we want to have the basic framework for transport network slice ready as a generic model, and then we know what we can exactly put over the OTN slice model. We do this step by step, and we agree with chairs/comments, we can consider separating into two drafts. We will discuss on the mailing list. (by the end of presentation...) [Dhruv Dhody] Wrt NRP, we also need to clarify if there could be any interaction between NRPs in IP layer and the NRP here, or are they going to be completely independent, this is not clear in the document. Also there is an NRP model in TEAS. Is that model considered as a generic model whereas the NRP OTN is going to be something specific? A bit more thought is needed. [Dhruv Dhody] The other issue is about the topology part. We discussed in TEAS about adding VN type 2 to network slicing, i.e., to put reference to an abstract topology as we do in VN type 2. Would that meet your requirement? or you still need to have a topology separate from that in the teas? Suggest to discuss with teas authors and come up with a good solution here. [Aihua Guo] I agree, one of the main driving factor for a common transport model is that we don't have an option to specify topology in the base model. Actually it depends and let's discuss offline to support the topology. [Adrian Farrel] Thank you for the update with closer ties to the TEAS IETF network slice service model, since I requested it. This version of the document is much cleaner. This document is moving to that direction, we do need to step back and try to understand whether a slice is supposed to expose anything about the underlying topology. Also want to raise the question of whether we should expose the topology. Perhaps the slice service is opaque (like a VPN service) and if we integrate with it we should also not expose the underlay topology, but if we want to expose the topology, we should stick with the virtual topology approach. [Dhruv Dhody] (from chat): BTW italo - To be frank I am not sold on the need for NRP for OTN but that could just be me.... [Adrian Farrel] (from chat): I'd agree with that (and NRP is optional) OTOH, you might want to build an NRP of coherent lambdas or fat timeslices or ... 3. A YANG Data Model for L1 Connectivity Service Model (L1CSM) draft-ietf-ccamp-l1csm-yang Presenter: Haomian Zheng Length: 10 min > Note Well > Meetecho and connectivity issues meant that physical room became detached from the rest of the meeting during this presentation and extentding into the next item. > The meeting continued in virtual space, and was recorded with losing the video in the meeting room. [Daniele Cecccarelli] Since we are quite close to the WG LC, I would bring the two open issues to the mailing list to see the opnions of the WG. 4. A YANG Data Model for Optical Impairment-aware Topology draft-ietf-ccamp-optical-impairment-topology-yang-10 Presenter: S.Belotti Length: 15 minutes No questions/comments 5. A YANG Data Model for Layer 0 Types draft-ietf-ccamp-rfc9093-bis-01 Presenter: S.Belotti Length: 10 minutes No questions/comments 6. A YANG Data Model for Network Hardware Inventory draft-yg3bp-ccamp-network-inventory-yang Presenter: Chaode YU Length: 15 minutes [Daniele Ceccarelli] When this draft was first presented we thought it was a good idea to discuss with Netmod about what was the right place and we agreed to continue this work in CCAMP. Does anyone believe this work does not belong to CCAMP WG? [John Scudder] Not sure at the moment 7. A YANG Data Model for requesting Path Computation in an Optical Transport Network (OTN) draft-gbb-ccamp-otn-path-computation-yang-01 Presenter: Italo Busi Length: 10 minutes [Daniele Ceccarelli] Need also to keep alignment with the Path Computation RPC under definition in TEAS WG [Italo Busi] Agree 8. YANG Data Models for requesting Path Computation in Optical Networks draft-gbb-ccamp-optical-path-computation-yang-01 Presenter: Italo Busi Length: 10 minutes [Daniele Ceccarelli] We should try to align between tunnel and path computation models. A merge between WSON and flexi-grid models seems possible. [Italo Busi] Just need to check the details 9. Problem Statement and Gap Analysis for Connecting to Cloud DCs via Optical Networks draft-liu-ccamp-optical2cloud-problem-statement-02 Presenter: Aihua Guo Length: 10 minutes [Daniele Ceccarelli] You say BGP is not commonly used in OTN devices. I thought BGP-LS, not BGP, was common on optical devices. [Aihua Guo] As far as I know, BGP is not common in optical networks. Also there are no OTN extensions to BGP or BGP-LS. [Daniele Ceccarelli] This is not very different from OTN slicing. Is it? [Aihua Guo] OTN slice is an application. You could create an OTN slice by using this to support the slice. The use of this work is mainly to introduce the OTN capability to better support cloud-based services by runing them directly over OTN. Without using OTN slices, you could use this work to better support DC traffic carrying it over OTN. [Daniele Ceccarelli] This scenario is a subset of slicing or slicing is a subset of this. I'm not sure. [Yi Lin] We may need some clarification among L1vpn/Optical service/OTN slicing. From underlay perspective we are all using OTN network. L1vpn is carrying L1 services; Optical service is carrying L2 and L3 services; OTN slicing is for OTN resources – but may not touch the service layer. [Aihua Guo] Yes. OTN slicing does not care what service it is running. Just captures the requirement for the QoS of slice. This work could be used as realisation of slice in OTN. [Dhruv Dhody] Are PCEP extensions for OTN really needed or can we have common generic PCEP extensions. [Aihua Guo] A lot of the extensions should be common, and we need to work on that. [Italo to Daniele Ceccarelli] I think that both of the things you mentioned. This solution could be one way to realise an OTN slice. But also, this work may be one way to request an OTN slice.