CCAMP Meeting minutes – IETF 109 - Online
Friday, November 20, 2020
16:00-18:00 Friday Session III
9:00-11:00 (UTC)
Presentation Start
Time Duration Information
0 16:00 20 Title: Administrivia - WG Status - Reporting on WG drafts not being
presented
Presenter: Chairs.
[Daniele Ceccarelli] Open mic for WG documents not in agenda
[Gabriele Galimberti] wdm-interface lmp . It
will follow the te-topology draft. After the meeting
the update will be done together with an internal meeting.
[Daniele Ceccarelli] Flexi grid yang has weekly calls.
1 16:20 20 Title: Update on the L1CSM YANG Modules and
Layer1 Types
Draft: https://tools.ietf.org/html/draft-ietf-ccamp-layer1-types-08
Draft: https://tools.ietf.org/html/draft-ietf-ccamp-l1csm-yang-13
Presenter: Haomian Zheng
[Gert Grammel]: Interesting work. Do you consider the
OIF 400G-ZR as line interfaces or as client signals
[Haomian Zheng]: in this document 400G-ZR is not in
the scope so far. The target is only MEF63 and the
client signals specified in ITU-T.
The OIF 400G-ZR can have impact on more documents: may be worthwhile reviewing
its impact.
[Daniele Ceccarelli]: Do you need support with any liaison
activity with MEF?
[Haomian Zheng]: MEF has done its job. It is mainly
IETF work.
2 16:40 20 Title: Applicability of GMPLS for B100G
Optical Transport Network
Draft: https://tools.ietf.org/html/draft-ietf-ccamp-gmpls-otn-b100g-applicability-03
Presenter: Qilei Wang
[Yuji Tochio] There is no major changes in B100G in
G.709-2020, we can directly put G.709-2020 as reference.
[Qilei Wang] Good point, we can take it into account in the next revision.
[Fatai Zhang] If the M value
is not enough, which additional information is needed? This should be described
in the draft.
[Qilei Wang] There is no standardized algorithm on which slot is used so M is
not sufficient.
[Fatai Zhang] Is this related to ITU-T specification
or vendor-specific?
[Qilei Wang] It is related to ITU-T specification.
[Yuji Tochio] Same feeling and comment as Fatai.
[Italo] In the draft it is clarified that the two ends of the ODUCn link need to know the list of available time-slots.
How they discover this information depends on the mechanism used to setup the ODUCn link, which is outside the scope of this draft.
3 17:00 20 Title: A Yang Data Model for Optical
Impairment-aware Topology
Draft: https://tools.ietf.org/html/draft-ietf-ccamp-optical-impairment-topology-yang-05
Presenter: D.Beller/S.Belotti
[Gert Grammel] If inter-op, you can stand with the
application codes. If extended capability, use explicit mode. (please see
comments on the mailing list)
[Dieter Beller] We agreed on 3 different modes in
Singapore. We have further described the organizational mode with capabilities.
The optical pluggables need to know the capabilities.
The organizational mode with ID can have a decision on whether such
capabilities are included in implicit way or make it explicit.
[Daniele Ceccarelli] Let’s focus on the technical part, we need consensus from
whole WG.
[Sergio Belotti] This is a YANG model, with some
approval on the github. We have been going back and
forth for a few iterations.
[Italo Busi] Regarding the RFC7581, the vendor-specific approach is ‘for future
study’, we don’t know how to manage it.
[Gert Grammel] What problems are we trying to solve? Column 1, 2, 3 or 4? (see
slides) The issue is when can we use the same mode-id and when we need to
define a new mode-id. For example, it is not wise to use the same mode-id for
C-band and L-band.
[Dieter Beller] An implementation can use one
approach or another. The YANG model is very flexible to allow any approach.
[Julien Meuric] I think the current mode is flexible enough to accommodate the
different transponder capabilities.
I am confused by the slide since either mode 42 is not the same or if the same
it cannot be used in some cases.
The best approach would be to add some clarification text and guidelines to
mitigate the wrong rules an implementer can use if not fully familiar with the
model.
[Fatai Zhang] Sergio’s slide, page 5: it mentions
that ACs do not support beyond 100G capabilities. Why ITU-T members do not go
to ITU-T to define ACs for beyond 100G capabilities so that can support these
ACs in IETF?
[Daniele Ceccarelli]
I will send a poll to the WG (one week time to reply) to gather input on how to
move forward:
Option A: leave everything as is
Option B: add text in the draft to clarify the scope or better to clarify what
is out of scope
Option C: go back to ITU-T to get ACs for beyond 100G capabilities
Option D: if Gert has a proposal for an option D
4 17:20 20 Title: OTN network slicing
Draft: https://www.ietf.org/archive/id/draft-zheng-ccamp-yang-otn-slicing-00.txt
Presenter: Aihua Guo
[Adrian Farrel] It would be useful to put this
document in the context of the work done in TEAS rather than defining new
stuff. Do the authors expect some deviations from the terminology and work done
in TEAS?
[Aihua Guo] The framework should be in common but the use cases are more OTN
technology-specific and we may augment generic models developed in TEAS
[Adrian Farrel] There is also an ACTN applicability draft in TEAS which is
relevant for this work.
[Daniele Ceccarelli]
How is the OTN slice different from an OTN service?
[Aihua Guo] It is mainly a VN type 2 service
[Yuji Tochio] Please clarify the use of term OTN;
[Aihua Guo] OTN is the technology defined in G.709, including ODU and future
Optical Service Unit(OSU).
[Sergio Belotti] slice
representation and realization are two different concepts. Are you defining the
OTN slice itself or its realization?
[Aihua Guo] It’s more than realization, the requirement is what type of the OTN
resources are needed, and then realize.
[Italo Busi] We are struggling when aligning with TEAS work. Sometimes the
users are requesting OTN specific connections, and it may come from the CMI.
Adjourn 17:40