Skip to main content

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 doesn’t belong. Haomian: Yes, that’s
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 don’t allow.
Dieter: While capabilities can be described in 3 ways, there is just one list
of capabilities. I don’t 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: That’s 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. Can’t
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 operator’s 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