CCAMP working group agenda - IETF 121
Friday, November 8th, 2024
9:30-11:30 (Meeting time) Room Liffey Hall 1 Presentation Start Time Duration Information 0 9:30 15 Title: Administrivia - WG Status - Reporting on WG drafts not being presented - Milestones Update - Charter Update
Presenter: Chairs
Happy Birthday to Daniele.
Julien Meuric: (tsvmode-signalling draft) will update for alignment -
and there are new contributors.
Oscar: (pluggable-usecase-gap-analysis) pluggable draft: we are working
to address the issues during adoption call, and the title will change
from coherent pluggable to generic pluggable.
Italo Busi: (for ITU-T presentation of the impairment) okay to have an
ITU-T contribution, but better to also join the IM/DM call to have joint
discussion on any comments from ITU-T.
Italo Busi: (missing flexi-grid topology draft for WG drafts):
flexi-grid topology model is also ready for WG LC.
Daniele: Yes, was planning to go together with impairment topology.
Yi Lin: (ETSI liaison) this is about the control plane for fgOTN, about
requirement - and there is a draft solve the problem, on the agenda.
There will be no ccamp meeting in IETF 122. Two interims are arranged on
Feb 17 (prioritize for WDM/pluggable) and April 10 (prioritize for OTN)
Daniel King: the number of notifications on the ccamp mailing list is
big without much information - the compilation or issue updates, may not
need be notified - new issues, yes. Would the users of the Github look
to minimise the messaging that is sent to the CCAMP list, please.
1 9:45 10 Title: A YANG model to manage the optical
interface parameters for an external transponder in a WDM network
Draft:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-dwdm-if-param-yang/
Presenter: Gabriele Galimberti
Daniele: the state is quite stable. Probably we can bind the three
documents together.
Gabriele: a review from ITU-T is also helpful.
Aihua: how to manage the relationship with pluggables? Any gaps
identified?
Gabrielle: we are open to add attributes for pluggable - the draft is
focus on optical interface parameters and not target on pluggable.
Daniele: probably if we find any gaps we can address them in the
pluggable draft.
Sergio: from YANG perspetive, it aligns with RFC9093bis and optical
impairment models. However the text need to be re-aligned, happy to
help.
2 9:55 10 Title: A YANG Data Model for WDM Tunnels
Draft:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-wdm-tunnel-yang/
Presenter: Aihua Guo
No discussion.
3 10:05 15 Title: Modelling of Optical Pluggables in
Packet Over Optical Network
Draft:
https://datatracker.ietf.org/doc/draft-rokui-ccamp-actn-wdm-pluggable-modelling/
Presenter: Reza Rokui
Daniel King: I found two docs about pluggables - a use case and a data
model, that seem to be "active". the WG adoption proposal is a merge of
these documents, or something else?
Reza: different lifecycle for two draft - operator drives uc and gap,
the other one is this, about the artifect to support pluggables. They
are separate and no plan to merge.
Daniel King: need to clarify the uc and gap document, there should be
more authors/contributors.
Reza: that one is driven by operator, and this document is from the
vendor. It's a logical separation.
Daniel King: for adoption, Googledoc needs to be converted into draft
text. We only just got used to using Github so having new tools might be
a problem. Googledocs might not be accessible from everywhere.
Reza: I don't think there is a way to convert directly - will try to
make it. Open to any suggestions. A sharepoint, google sheet, Github,
etc.
Daniel King: Please consider using Github.
Daniele: these are the two documents we decided to work on. Others from
ccamp are expiring.
Haomian: Great to see the google sheet providing a list of attributes
and reference to existing parameters. It's great to reuse what has been
specified. The model dependency relationship is very important and
please indicate that in the future update. So that the progress could be
managed together.
Reza: Good suggestion for the second one (gap analysis). At this point I
will try to finish the Googlesheet as quickly as possible.
4 10:20 10 Title: YANG Data Models for fine grain
Optical Transport Network
Draft:
https://datatracker.ietf.org/doc/draft-tan-ccamp-fgotn-yang/
Presenter: Yanxia Tan
Daniele: you are having the topo/tunnel augementation together.
Haomian: the augmentation on topo and tunnel from fgOTN is light so that
could be separate augementations in the same draft as multiple clips, to
avoid having multiple drafts.
Daniele: that's fine.
Chaode: there is bi-weekly call on Wednesday. The augmentation in the
slides are used in 3 scenarios introduced in this draft. All the
attributes (link, path, switching capabilities) have been described so
far in the draft.
5 10:30 10 Title: Applicability of GMPLS for fine grain
Optical Transport Network
Draft:
https://datatracker.ietf.org/doc/draft-lin-ccamp-gmpls-fgotn-applicability/
Presenter: Yi Lin
No discussion.
6 10:40 10 Title: A YANG data model of Performance
Management Streaming
Draft:
https://datatracker.ietf.org/doc/draft-yoon-ccamp-pm-streaming/
Presenter: Bin Yeong Yoon
Chaode: in the side meeting, we discussed the splitting of the document
(shown on last slide), for document 1 could you indicate the
applicability on the NBI?
Bin: Okay for that.
Chaode: for data intervall- need to differentiate the PM collection rate
from device/network, given the limited management bandwidth.
Bin: good point, plan to classify the PM parameters into different
catalogs.
Luis: Thank you for proposing the spliting generic and tech-specific.
There are multi tech mentioned in P13 as well (OTN, MPLS), one or
multiple document?
Bin: Not decided yet, open for that.
Daniele: The splitting would also depends on the size of
model/parameters. Too small splitting wont make much sense.
Aihua: there are duplicated clips for 15min and 24hour - probably a
common structure for that.
Bin: yes.
Aihua: the splitting (into generic and tech-specific), if we only have
ccamp use case, it may not make sense if we generate for ops area.
Bin: so you mean we work on the parameters useful in ccamp?
Aihua: we share common model in ccamp. Going to OPSAWG and cover IP
parameters without use case would be less interest.
Bin: G.7710 provides common framework and performance parameters for
OTN, MPLS, EThernet. Detailed IM is in G.8051 and so on. Anyway we can
discuss how to classify the parameters.
Roberto Manzotti: great to cover multiple technologies, now it mainly
focus on digitals signals, but for optical analog parameters it also
shares the common framework.
Italo: seconding Aihua and Roberto. General model for optical is good
for me. I am struggling on the question whether to extend it outside
optical, especially there is no endorsement.
Daniele: it's always good to check, no answer is a good answer as well.
Bo: Tech-agnostic may overlap with opaswg RFC9375, there is work about
vpn and network performance, which also contains the generic framework.
7 10:50 10 Title: AI based Network Management
Agent(NMA): Concepts and Architecture
Draft:
https://datatracker.ietf.org/doc/draft-zhao-nmop-network-management-agent/
Presenter: Xing Zhao
Swamy (slide 7): there is close-loop illustration. Does the NMA mean the
procedure bypass the controller?
Xing: there are independent mode and integrated mode, it depends.
Swamy: A fundamental question, What additional capability beyond than
the controller in the NMA?
Xing: current draft would be following the current architecture, for
tech-independent capabilities. there could be optical-specific network
functions in ccamp in future.
Swamy: Are you going to choose one from the integrated mode/independent
or do separately?
Xing: probably choose one if we have consensus.
Daniel King: Controller/NMA data patitionning would be a problem, if you
plan to make changes in the network thatr bypasses the controller.
Consider Cap Theorem, partition tolerance, avaliblity and data
consistancy.
Daniel King: What would you like CCAMP to help with, is this only
applicable to optical/microwave transport, or a wider scope?
Xing: the concept of NMA covers multiple technologies. If accepted here
there could be network functionality works in ccamp.
Daniele: this is an NMOP draft and there is also the relationship with
ccamp in later slides.
Chaode: there is Use case description on Optical/Electricity AN L4 in
separate document. This framework is useful.
Italo: where is the applicability of NMA and Intent-Based interface? on
top of optical controller? or on top of IP and optical integrated
controller?
Xing: prefer to between NMA and applications. it also depends on the
mode we choose.
Italo: is the underlaying network an optical only or packet optical?
Xing: maybe just single tech for the 1st stage.
Haomian: we may not be able to choose only mode A or B and exclude
another. It depends on the current deployment and people are free to
choose which is easier to evolve.
Haomian: some capabilities are quite different between technologies
(e.g., planning) while others have similarities (e.g., fault). So if the
underlying network is single-tech or multi-tech may depend on the
network capabilities we are tryinng to introduce. It is very useful to
have the NMA and reach cross-tech consensus if possible.
Xing: not able to answer at this moment.
Haomian: no problem, just try to figure out the right question.
Daniel: do you have an intent-based interface already?
Xing: intent interface is not available at this moment, but people are
working on that and probably there will be some available soon. Probably
requirement first and then approach.
Daniel: Please look at the NMRG and work that has been done on the IB
interface and NDT is offering useful input. How to map the network
objective "intent", declarative policy, with the network "policy",
imperative function. We have tools currently, let us know what is
missing and that would also be worth investigating.
Swamy: Is the work complementing TMF autonomous networks framework?
Network layers are different with business layers and service layers -
suggest to focus on network first, the migration could happen between
transport, packet and access. L0 to L5 is measuring network layers on
controllers. I would suggest to clarify the scope and focus on network
first.
Xing: this draft provides a means to approach Autonomous Networking, but
not the only ones, we are open to find the right one. We will check the
scope and try to get our contents better.
Luis: when we check the availability of YANG models, there are different
models across different WGs. Do you foresee that maybe for some
technologies will be a common approach for cross-tech and some not?
IB-NBI YANG should be encouraged to reuse the legacy YANG, is the
applicability not yet analyzed right? (Yes.)
Adjourn 11:30