Minutes interim-2020-ccamp-02: Wed 14:00
minutes-interim-2020-ccamp-02-202009231400-00
The information below is for an old version of the document.
Meeting Minutes | Common Control and Measurement Plane (ccamp) WG Snapshot | |
---|---|---|
Date and time | 2020-09-23 12:00 | |
Title | Minutes interim-2020-ccamp-02: Wed 14:00 | |
State | Active | |
Other versions | plain text | |
Last updated | 2020-09-23 |
minutes-interim-2020-ccamp-02-202009231400-00
CCAMP interim meeting 2020 September 23rd MINUTES OF THE MEETING 1. Updated on OTN drafts and L1CSM (40 mins) * draft-ietf-ccamp-layer1-types; * draft-ietf-ccamp-otn-topo-yang; * draft-ietf-ccamp-otn-tunnel-model; * draft-ietf-ccamp-l1csm-yang; Presenter: Italo Busi draft-ietf-ccamp-layer1-types Daniele: What is the pending issue with L1CSM? Italo: Discuss when we get to that draft draft-ietf-ccamp-otn-topo-yang Daniele: will ask for yang doctor review draft-ietf-ccamp-otn-tunnel-model Daniele: Maybe do joint Yang Dr review with topo draft-ietf-ccamp-l1csm-yang Dieter: Did you discuss this with authors of MEF63? Italo: No: the requirements from MEF63 are clear. The problem is how to model _with YANG. Daniele: Summary. Next step is topo and tunnel ready for (pre-last-call) YANG Dr review. Probably start IPR poll in parallel. Then move them to WGLC. Need to try to avoid having a large cluster, but reviewing is made better by keeping documents in the same cluster. 2. YANG model for Flexi-grid topology (15 mins) * draft-ietf-ccamp-flexigrid-yang; Presenter: Haomian Zheng Daniele: Putting this in cluster with L0 drafts would be a bit late. Maybe ready for Yang Dr. Framework for flexigrid is an RFC for 2 years, so should have been well read. So can remove unwanted material from this draft, also material (such as impairments) that doesnt belong. Haomian: Yes, thats the plan 3. YANG model for impairment aware optical topology (20 mins) * draft-ietf-ccamp-optical-impairment-topology-yang Presenter: Sergio Belotti Daniele: If we allow 3 options there is probablitity that different ends of link will pick different options. Can we shrink set of options? Sergio: Long dicussion about this since Singapore. Need explicit mode because of how interface model is built. Other two modes are quite close to each other (see slides), but difference is driven by what ITU-T application codes dont allow. Dieter: While capabilities can be described in 3 ways, there is just one list of capabilities. I dont think that any 2 can be combined. Must also support application codes from G.698. Daniele: If 3 different methods of encoding the same information then would inist on combining. Dieter: Did discuss merging modes, but found different reasons for keeping them. 4. Update on Network Slicing design team work in TEAS (15 mins) * draft-nsdt-teas-ns-framework * draft-nsdt-teas-transport-slice-definition draft-nsdt-teas-ns-framework Presenter: Eric Gray Lou Berger: What work might fall to CCAMP Eric: Was proposed to bring this all to CCAMP, but not currently our thinking. TEAS can generically talk about TE stuff, but when trying to talk about a service interface (outside of TE and packet switching) that part of the work probably would be done in CCAMP. Lou: Thats the answer I hoped for. Generic in TEAS; technology specific L1/L2 might be in CCAMP. Dhruv Dhody (in chat window): I thought it would be mainly transport slice realization directly on a LO/L1 networks that could be done in CCAMP draft-nsdt-teas-transport-slice-definition Presenter: Reza Rokui Haomian: Maybe some understanding gaps (such as treansport, TE, generic). TEAS does generic, CCAMP specific technology approaches. Discussion seems to say transport has wider sope than TE. Cant imagine a network slice can be a non-TE representation (because TE tracks performance of SLA/SLO). Reza: When we talk about non-TE we are talking about realisation of a transport slice in the network. Implementation is dependent on the operator. As long as SLA is met then TE or non-TE is operators decision. Haomian: Confirm proposal to this WG. CCAMP has not much experience on non-TE technology. Fatai: F/w doc refers to terminology doc. Need to be consistent about slicing transport networks. Adrian: Note that when Reza talks of resolving things tomorrow this refers to a Network Slicing Design Team meeting on Thursday. Adrian:Do you think there is need to slice a transport network which uses CCAMP technology? Eric: Yes Eric: Not reinventing wheels. Expect to point most of the time to things that have already been done. Eric: We are attempting to address a liaison from 3GPP routed to us via BBF. Italo: Distinguish between TE technology in the network, and TE metrics used to describe services Lou: Thank Reza and Eric and CCAMP for presentations. This work is ongoing in TEAS. Open Design Team call tomorrow: see announcement on TEAS list. Planning a TEAS interim roughly mid-October Jie (in chat window): IMO TE is a generic characteristic of several technologies, such as packet, optical, etc, When talking about TE/non-TE, may need some explanation of what is a non-TE network. BLUE SHEET Haomian Zheng - Huawei Technologies Adrian Farrel - Old Dog Consulting Italo Busi - Huawei Dhruv Dhody - Huawei Dieter Beller - Nokia Gabriele Galimberti - Cisco Eric Gray - Ericsson Oscar Gonzalez de Dios - Telefonica Aihua Guo - Futurewei Sergio Belotti- Nokia Fatai Zhang - Huawei Lou Berger - LabN Yuji Tochio - Fujitsu Bo Wu - Huawei Jie Dong - Huawei Vishnu Pavan Beeram - Juniper Networks Luis M. Contreras - Telefonica Yi Lin, Huawei Technologies Julien Meuric - Orange Reza Rokui - Nokia