CCAMP Session IETF 99
Thursday, July 20, 2017(CEST)
15:50-17:50 – Afternoon Session
II
Presentation Start
Time Duration
Information
0 15:50
10
Title: Administrivia - WG Status - Reporting on WG
drafts not being presented
Draft:
Presenter: Chairs
1
16:00
10
Title: A framework for Management and Control of DWDM
optical interface parameters
Draft:https://tools.ietf.org/html/draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-06
Presenter: Ruediger Kunze
Jan Kundrat: Editorial change, the text refers to a
“yellow” triangle. Please remove it. Daniele Ceccarelli: Thanks for
intermediate versions. Readability OK now.
[Poll] Does anyone object moving the draft to WG LC?
No one.
Fatai Zhang: please check if you use RFC language, if not
please remove section 1.1
2 16:10 0
Title: A Yang
Data Model for WSON Optical Networks and tunnels
Draft: https://tools.ietf.org/html/draft-ietf-ccamp-wson-yang-07
Draft: https://tools.ietf.org/html/draft-lee-ccamp-wson-tunnel-model-01
Presenter: Young Lee
*draft presented in the joint YANG session (see TEAS
session II)
3 16:10
10
Title: Info
model and information encoding for WSON with impairments validation
Draft: https://tools.ietf.org/html/draft-ietf-ccamp-wson-iv-info-05
Draft: https://tools.ietf.org/html/draft-martinelli-ccamp-wson-iv-encode-08
Presenter: Giovanni Martinelli
(regarding the first draft)
Dieter Beller: What is the added value of defining the
optical parameters without having a model for optical feasibility calculation?
Still unresolved issue in my opinion.
Giovanni M.: The parameters have been discussed with
the ITU-T several times. There are refences to ITU-T documents in the draft.
Dieter B.: The problem is not lack of reference but
lack of model to guarantee optical feasibility.
Gabriele Galimberti: The document allows anyone to use
the parameters (e.g. by a controller) and defines how to exchange them. The
document does not define them nor how to use them.
Young Lee: I agree with Gabriele, this draft adds additional
attributes for path computation.
Giovanni M.: We have also split the document and thrown
away those not defined in ITU.
Julien Meuric: Everyone acks it is not the full solution
to the big problem, but it remains useful and required.
Dieter B.: Is the set of optical impairments
parameters complete?
Giovanni M.: It is complete according to the scope of
the document. See section 3 of the document.
(regarding the second draft):
Authors believe it is ready for WG adpoption (still
open points and encoding...)
Sergio Belotti: (regarding first draft). There is an
uncompleted section (Section 5.4).
Giovanni: It is an issue, without many content, and we
will continue working on it.
4
16:20
10
Title: A
framework and YANG model for Management and Control of microwave and millimeter
wave interface parameters
Draft: https://tools.ietf.org/html/draft-ietf-ccamp-microwave-framework-01
Draft: https://tools.ietf.org/html/draft-ietf-ccamp-mw-yang-01
Presenter: Jonas Ahlberg
Daniele C.: Congratulations to you and the team for
the award at the hackathon. I have a comment from Lou to try to make another
effort about what can be generalized. The microwave technology has a variable
bit-rate but there are also other technologies like e.g. elastic optics. We can
add some notes in the framework indicating that the considerations are
applicable also to other technologies. Little bit more changes are expected on
the YANG model.
Two options for the model: one is to have a new
document with the generic part and leave the technology-specific parts here or
to keep the generic and mw-specific parts in the current document but clearly
separated.
Amy Y.: Personally, prefer the second option.
Oscar G.: Is there any reference to ETSI specification
in the YANG model parameters?
Jonas A.: We have referred to a set of documents (each
of which often referring each other), but not indicated in detail where each
parameter comes from.
Giovanni M.: Something that could be generalized could
be the protection part (manual, force switch) and priority support.
Jonas A.: Will need to consider different protection
mechanisms.
6
16:30
15
Title:
Transport Northbound Interface Use Cases and Gap Analysis UC1
Draft: https://tools.ietf.org/html/draft-tnbidt-ccamp-transport-nbi-use-cases-02
Draft: https://tools.ietf.org/html/draft-tnbidt-ccamp-transport-nbi-analysis-uc1-00
Presenter: Italo Busi
Jan Kundrat: Are you considering also OpenROADM(No)
Daniele C.: We could help you with liaisons and
communications once the draft are WG documents. How did you provide feedbacks
to TEAS?
Italo B: contributions to the design team call.
Fatai Z.: Some coordination with Igor's draft is
needed to avoid conflicts on the NBI.
Italo: will do
Sergio: Regarding OpenROADM, that is a device model
while our scope is a network model.
Daniele C.:[poll] How many have read the use cases
draft? almost everyone.
How many think the WG should adopt this work? almost
everyone.
7
16:45
10
Title:
Flexigrid and flexigrid media channel YANG models
Draft: https://tools.ietf.org/html/draft-vergara-ccamp-flexigrid-yang-05
Draft: https://tools.ietf.org/html/draft-vergara-ccamp-flexigrid-media-channel-yang-00
Presenter: Oscar
Gonzalez de Dios
Jan K.: Same values of M and N could be used to
identify incompatible channels. Was it ever considered to use Ghz or Thz to
identify the center of the channel of the channel width?
Gabriele G.: We are using M and N first because this
is in line with ITU-T and second because using THz or lambda we may end up in rounding
issues and the frequency can be misinterpreted (5 digits after the comma are
not enough). Maybe you are thinking about the OpenROADM model which I disagree
with because it has this issue.
Dieter B: M and N parameters are well defined in ITU-T
recommendation G694.1, which should apply here. G694.1 should be added as
normative reference.
Gabriele G.: Moreover, N is still valid in case you
add future granularities (e.g. 3.125Ghz) or apply it to fixed grid (e.g.
50Ghz).
Yuji T.: Can you please clarify terminology in the
draft when speaking about Media Channel and Network Media Channel?
Oscar G.: Terminology is discussed in the framework
document(RFC7698) and in ITU.
Yuji T.: This should be aligned with ITU-T recommendation
G.872, and with a new work in ITU-T called G.media.
Oscar G.: In IETF we define how we abstact those data
plane constructs.
Young L.: Good base for WG adoption. The names need to
be aligned with TE-Tunnel mode.
Haomian Z.: Terminology alignment occurred between flex
grid and RFC7698(framework). We need to align also with other IETF models.
Dieter B.: Please reconsider the definition of
connectivity matrix in the TEAS TE Topology. Extensions should be aligned with
the connectivity matrix definition in the base model. In addition, it should be
read-only for WDM networks.
Young L.: Late changes we need to align with. We also
still need application codes. Authors will align offline with TE Topology
authors.
8
16:55
10
Title: Signaling extensions for Media Channel
sub-carriers configuration in SSON in LSC Optical Line Systems.
Draft: https://tools.ietf.org/html/draft-ggalimber-ccamp-flexigrid-carrier-label-01
Presenter:
Gabriele Galimberti
Note: Given the interesting discussion raised by the
presentation Gabriele decided to use the time allocated to slots 9 and 10 to
continue the discussion related to slot 8.
Qilei Wang: Could you explain the relationship between sub-carrier and OTSi? In my
understanding, one OTSi can contain two sub-carriers.
Gabriele Galimberti: ITU-T
defines that one OTSi can have two or more sub-carriers. In the example, the
payload is shared between two OTSi. If one OTSi is lost, all the payload is
lost. It is a sort of inverse multiplexing, but is detailed implementation.
Dieter Beller: Why the change from experimental to
informational? Also, I wonder whether CCAMP is the right place to standardize
proprietary solution.
Gabriele Galimberti: It is
about experimental, but I think this can also inform what the solution could
solve the problem of multi-carrier transponder.
Dieter Beller: A product from which vendor?
Gabriele: My vendor.
Daniele Ceccarelli: This is a perfect example for
experimental. It is something not standard, but with real code.
Gabriele Galimberti: No
problem to move back to experimental
Julien Meuric: As operator, I would be happy to have
other proprietary proposals joining this initiative, because it could be a way
to turn into a standard track document. Considering I am actually deploying
this multi-vendor alien wavelength, this is required to stop doing manual or
multiple-step operations. I support the
work, we would like to see multiple vendors work on this topic.
Daniele Ceccarelli: How would you like to see this
progress? Experimental?
Haomian Zheng: Explicit data plane standard to support multi vendor should be required,
however we don't have it yet. If every vendor bring their own implementation,
it still cannot support operator's requirements.
Gabriele Galimberti: We are open to hear from other
vendors’ solution on SSON.
Yuji Tochio: This draft defines modulation ID inside,
it needs to have clear references for the modulation ID.
Gabriele Galimberti: I list a lot of modulation
formats in the draft, probably it is not exhaustive. Probably it is not the
best to represent the parameters. We have a number for each modulation format.
I am open, no problem to change the order.
Italo Busi: Q6/15 in ITU-T is working on a standard data plane, it is better to wait
for data plane standard before having control plane standard.
Gabriele Galimberti: The market is not waiting.
Sergio Belotti: You said before no more experimental but this is proto. Question is that
whether IETF has to standardize company proto even it is supported by
operators.
Daniele Ceccarelli: An experimental draft doesn’t mean standardization. You cannot be informational because you are defining TLVs. Let’s progress
with the assumption that this document goes back to experimental status.
Giovanni Martinelli: For
multi-vendor issue, ITU-T does not define interoperable standard. Something
need to be moved even though the data plane standard is not available now. For
modulation formats, we can have a table to refer. Changing encoding give you
changing modulation format.
Julien Meuric: An informative or experimental draft is
better than nothing.
9
17:05
10
Title:
Extension to LMP for DWDM Optical Line Systems to manage the application code
of optical interface parameters in DWDM application
Draft: https://tools.ietf.org/html/draft-dharinigert-ccamp-dwdm-if-lmp-04
Draft: https://tools.ietf.org/html/draft-ggalimbe-ccamp-flex-if-lmp-02
Presenter:
Gabriele Galimberti
(skipped to have more time for previous discussion)
10
17:15
10
Title: A
YANG model to manage the optical interface parameters for an external
transponder in a WDM network and optical paramenter in a WDM network
Draft: https://tools.ietf.org/html/draft-dharini-ccamp-dwdm-if-param-yang-02
Draft: https://tools.ietf.org/html/draft-galimbe-ccamp-iv-yang-03
Presenter:
Gert Grammel
(skipped to have more time for previous discussion)
11
17:25
10
Title: GMPLS
Routing and Signaling Framework for B100G
Draft: https://tools.ietf.org/html/draft-merge-ccamp-otn-b100g-fwk-01
Presenter: Qilei
Wang
Yuji Tochio: -01 has three flexE use cases, there seems to be new for 4.5,
please handle it carefully.
Qilei: We will
check.
12
17:35
15
Title: GMPLS Routing and Signaling
Framework for Flexible Ethernet (FlexE)
Draft: https://tools.ietf.org/html/draft-izh-ccamp-flexe-fwk-03
Presenter:
Loa Andersson
Deborah Brungard: in the diagram, what's switching in the middle box?
Loa Andersson: FlexE is not a switching technology.
Deborah Brungard: as individual, FlexE
calendar slot is not switching, but terminiated. LSP as an example, FlexE ,
show the architeture, FlexE is purly a link, terminated inside. FlexE then just
a encoding of the link. It's nothing to be switched
Andrew Malis: two different approaches, GMPLS approach,
label is not exist
on the data packet; MPLS apporach, labels on the data packet
Yuji Tochio: Is the FlexE
sub link differnt from FlexE clinet (in OIF
IA)?
Loa Andersson: FlexE sub-link is a link with one
Ethernet interface at each end and FlexE client between them.
Mach Chen: We do not support FlexE switching. FlexE
terminates at each hop. The FlexE frame will be recovered to Ethernet/MPLS
packet, then transmitted to the next hop. It is just like what is defined in
the OIF FlexE IA.
Loa Andersson: We are setting up an MPLS LSP.configure the undelying and sub
link by GMPLS signaling and routing.
Deborah Brungard: it's not controllable,
it's atuomatic. talk to the ITU-T people.
13
17:50
0
Title: ISIS Extensions for Flexible Ethernet (if
time permits)
Draft: https://tools.ietf.org/html/draft-zcdc-isis-flexe-extention-01
Presenter:
Mach Chen
Daniele Ceccarelli: once we have understood what to
switch, I would say this is a CCAMP draft, not ISIS draft
Julien Meuric: We have done IGP extension in CCAMP.
But I think this draft doesn't match.
Daniele Ceccarelli: Need to make it clear what you
want to advertise. The draft is talking about changing the switching capability
descriptor.
Mach: OK