Minutes IETF104: ccamp
minutes-104-ccamp-01

0 - Administrivia - WG Status -  Reporting on WG drafts not being presented

two documents adopted
draft-ietf-ccamp-b100g-applicability
draft-ietf-ccamp-mw-topo-yang

draft-ietf-ccamp-otn-topo-yang: Aligned with the TE generic model
-tunnel-model
wson-iv-encode
wson-iv-info
Gabriele Galimberti: (regarding the iv documents) The documents have been
refreshed and according to the authors they are ready for last call. Daniele
Ceccarelli: will review and proceed.

- Liasons
     Classic liason on the progress of ONTN standardization with ITU-T SG15.

1                 9:10        10        Title:        Transport Northbound
Interface Applicability Statement
https://tools.ietf.org/html/draft-ietf-ccamp-transport-nbi-app-statement-05
Italo Busi

Daniele Ceccarelli: Could you go through the future plan to detail what you are
focusing on? what is missing now? Italo Busi: We still need to fix some
editorials and references. A major one is about the description of the
protection. No other big issues. Daniele Ceccarelli: Use the list to confirm,
and as said last time, we can go on anytime when it's ready. Don't need to
cover everything. Italo Busi: If people have concerns we can have them in
future document.

2                 9:20        15        Title:        YANG models for WSON
Draft:        https://tools.ietf.org/html/draft-ietf-ccamp-wson-yang-19
Draft:        https://tools.ietf.org/html/draft-ietf-ccamp-wson-tunnel-model-03
Presenter:        Young Lee
(discussion regarding the topology models)
Daniele Ceccarelli: The TE topology is now back to the working group. The
drafts need to wait for the topology. Gert Grammel: operation modes contain
already FEC type, but FEC is spelled out explicitly in the YANG model. That
needs to be cleaned up to avoid overlap. Young Lee: FEC type is expected to be
in the operation mode as a Layer-0 type, actually this document contains the
Layer-0 types. Dieter suggested the layer 0 type to be a separate document. TE
type was doing the same way. We need to decide whether to separate. The
feedback from YANG doctors is the separating types module without any content
is not easy to follow. Dieter Beller: you can add references in the draft that
contains L0 types Young Lee: so you still prefer to separate the types? Dieter
Beller: Yes. There are also other related topics on the agenda, and side
meeting as well. At the end of the sessions we will see how to move forward
(like the L0 impairments drafts) Daniele Ceccarelli: we still need to figure
out on the list. Lou Berger: update on TE topology: last call finishes on
Friday. The type was blocking the progress (it was in another draft). Fatai
Zhang: If the WG agrees to have a L0 types document, we prefer to have it in
ccamp right? (Lou: yes. ) Italo Busi: L0 Types is putting grouping used in many
models. The risk is to depend too much on the potential new L0 draft. The other
option would be we go step by step, like v1 for WSON and v2 for other features.
Daniele Ceccarelli: this makes me think splitting is a better option. Lou
Berger: completely agree (with Italo). As TE types is referenced by multiple
modules, it makes sense to split. Oscar González de Dios: reminder that we also
have flexi-grid. Young Lee: added flexi-grid and WSON types in L0-types
already. (Discussion regarding the tunnel models) Igor Bryskin: (regarding the
progress of TE-tunnel) we expect last call, it's very stable, and there will
not be much technical changes. Fatai Zhang: clarifies that there are no issues
in the TE-tunnel. (Igor: yes. ) Young Lee: It's great, meanwhile is it possible
to request YANG doctor review? Daniele Ceccarelli: we need to figure out the
splitting first before going to that. It may impact the YAND doctor review.
(Discussion regarding flexi-grid models) Young Lee: there is a small error on
the naming in the flexi-grid model, it needs to use the correct flexi-grid
term. Daniele Ceccarelli: it would be good to find the same yang doctor to
review these document. Igor Bryskin: Errors and error handling were missing in
the tunnel models. There is corresponding sessions in te-tunnel models.  You
need to look a t the errors that need to be sent to the client. Daniele
Ceccarelli: are the errors already added? Igor Bryskin: they are in the update
of the generic tunnel draft.

3                 9:35        10        Title:        A Yang Data Model for L1
Connectivity Service Model (L1CSM) Draft:       
https://tools.ietf.org/html/draft-ietf-ccamp-l1csm-yang-09 Presenter:       
Young Lee Fatai Zhang: The draft has no dependencies on other wg documents.
(Young: No, that's right.) Haomian Zheng: Do we have the same motivation to
split the types apart? Young Lee: AFAIK, the types in this document is not
imported in elsewhere. Daniele Ceccarelli: How about integrating a
'L0-L1-types' for all? Young Lee: No, not preferred. Haomian Zheng: No. The
proposal is just to figure out common types in this work and otn-tunnel draft.
Currently they are semantically aligned but just belongs to different drafts.
Young Lee: No, these two are not identical, there are some terms similar but
not same attributes. Haomian Zheng: So we can either have a super set of these,
or a separate L1-service-type and another otn-types. Daniele Ceccarelli: no
particular reason for not having the types together (L1 and OTN) Young Lee: not
sure how much we shared, but it is worth to merge. If OTN is going to split
anyhow, this work may be a good place. OTN is the only Layer-1 technology we
know today. Haomian Zheng: Yes, the L1CSM provided in this draft is mainly
achieved with OTN networks, it makes sense to have common types. Young Lee: Ok,
let's evaluate. Michael Scharf: Do we need a more formal definition of the
performance metrics? Young Lee: the draft reuses MEF performance metrics.
Offilne China Unicom asked for more metrics. Michael Scharf: we need Reference
explicitly. Young Lee: The refernce is specificed in MEF 63. Igor Bryskin:
Likes L0 types and L1 types different. No need to combine L1 and L0. Young Lee:
clarifies that is exactly the proposal. Oscar González de Dios: even in the
same layer, you can have different technologies, L1 is easier. Igor Bryskin: In
L0 flexi can be separated, but not a must. But L0 and L1 have to be separated.
Young Lee: we agree that. Sergio: just to clarify, the reference to MEF, should
be confirmed by MEF that they are fully aligned? Young Lee: MEF is in UML, and
no YANG.  Currently we think we are aligned. Dieter Beller: did you present
this work to MEF? how they respond? Young Lee: MEF has UML/API people more than
YANG people. Dieter Beller: No need to look into yang, just check the
attributes. Young Lee: We did, and that part is good. Fatai Zhang: we may send
out liaison to MEF to confirm, MEF focus on parameters definition, we focus on
YANG models in IETF, but we may turn to them to check. Young Lee: MEF LSO
defines the UMLs. Deborah Brungard: There is a liaison, but not response.
Reminds that IETF has not responded. Need to put it in their language. Young
Lee: do we need to make it to UML? Deborah Brungard: No, just attributes. Young
Lee: that is done.

4                 9:45        10        Title:        A YANG Data Model for
Microwave Topology Draft:       
https://tools.ietf.org/html/draft-ietf-ccamp-mw-topo-yang-01 Presenter:       
Amy Ye No questions.

5                 9:55        10        Title:        A YANG Data Model for
Transport Network Client Signals Draft:       
https://tools.ietf.org/id/draft-zheng-ccamp-client-signal-yang-06.txt
Presenter:        Haomian Zheng Loa Andersson: Does the title refer to
transport networks and or transport? the term transport is confusing. Gert
Grammel: This is a complete view of the transport. Look exactly at what you
want to abstract. Daniele Ceccarelli: We are focusing on the access link. Gert
Grammel: then, you don't need to describe a hierarchy of controllers. Why would
you need the controllers? Michael Scharf: Be careful with the term transport,
it has many meanings in IETF. Dieter Beller: it addresses how transport network
signals are mapped into tunnels. This draft is focused on describing how to
adapt the CE to the PE, and the tunnels. If the understanding is right, this
should be reflected on the title. Haomian Zheng: It's true, client-facing is a
part of topology model, the information is useful for the controller to
understand what types of client signals can be supported and adapted to the
right PE. Gert Grammel: the abstraction presented on (p.4 ?) isn't really an
abstraction but an architectural concept. For such cases it should be stated
what exactly is supposed to be abstracted between controllers. Seemingly there
is no abstraction between subnet-controllers and network controller.
  Poll: how many people are interested in this topic? Lot of hands raised
  Poll: how many people think this work is a good starting point? almost the
  same.

6                 10:05        10        Title:        A Yang Data Model for
Optical Impairment-aware Topology Draft:       
https://tools.ietf.org/id/draft-lee-ccamp-optical-impairment-topology-yang-01.txt
Presenter:        Young Lee Young Lee: G.872 defines ROADM and ROADM function
together with Media link which is used to model ROADM and Optical Amplifiers
OMS starts right after the ROADM function inside the ROADM node. Igor Bryskin:
Clarification question. What about a transponder separated from the ROADM?
Young Lee: the model in this work considers the Transponder in the ROADM. Igor
Bryskin: Does this work focus on telemetry? Young Lee: no, actually if you look
into the node, you cannot directly get any impairment information. Igor
Bryskin: why is it call "impairments model"? Dieter Beller: in previous calls,
we focused on modeling the OMS link like fiber spans, amplifiers, and so on. It
does not talk too much about how to model the optical impairment are imposed by
the ROADM. I think that should be some future work. (Young: yes, correct.)
Aihua Guo: have you considered the Add/Drop amplifier? Young Lee: currently
not. Gabriele Galimberti: not yet, it's just a sub-case, in the ROADM degree.
Dieter Beller: it depends on the ROADM architecture. The architecture here is a
starting point, we have not touched that yet. Igor Bryskin: still missing the
focus of this work, is it a general one? Young Lee: this is optical-impairment,
started from OMS, and take the parameters on the optical layer into account. We
won't duplicate what has been done in WSON and flexi-grid. Igor Bryskin: is it
a network-wide model? Young Lee: Yes, network-wide model. Julien Meuric: we
have done more than what is shown in the slides (reference architecture page,
page 4) Oscar González de Dios: asks if it is possible to focus on the value of
the model (the model of the OMS) and augment existing optical yang models.
Aihua Guo: augmenting to TE links, with an assumption from ROADM to ROADM. how
about if TE links is on OMS? Young Lee: we need to discuss and augment, on
which TE links are not covered today. Aihua Guo: implementations from different
companies are not the same, some are only focusing on the TE links on OTS link.
Young Lee: right, your contribution would be appreciated. Julien Meuric: we
discussed and agreed OMS on TE links is the right thing. OTS is the OMS ends on
the amplifier instead of ROADMs, so if you would like to consider amplifier as
a ROADM, there won't be contradiction. Young Lee: As an operator, this use case
make sense to you, right? Julien Meuric: Yes. We need the parameters described
in your work, whether impairment parameters come from OMS or elsewhere is a
detail. I suggest WG to take a look at this and send feedback. Igor Bryskin:
amplifiers can either be a part of a link, or a part of the ROADM. Julien
Meuric: agree to be a part of link. Conclusion? Daniele Ceccarelli: regarding
the question on WG adoption, we will discuss.

7                 10:15        13        Title:        Analysis and YANG model
for FlexE Draft:       
https://tools.ietf.org/id/draft-wang-ccamp-flexe-control-analysis-00.txt Draft:
       https://tools.ietf.org/id/draft-xiaobn-ccamp-flexe-yang-mod-00.txt
Presenter:        Qilei Wang

Daniele Ceccarelli: what is the relationship between the control analysis draft
and the framework draft? Loa Andersson: currently it's not clear. We requested
a slot for framework but did not get. Daniele Ceccarelli: it was not on the
tool. Loa Andersson: (regarding slides p5/6) is that true Even if there are
different parameters for flexE? The TE parameters for ethernet and flexE are
not the same, can you just use it anyway? Qilei Wang: Yes, I think they can be
used in the same way. Loa Andersson: the concern is to use them in the same way
does not make sense. Deborah Brungard: Are you going to define a flexE
switching interface? Qilei Wang: No. Deborah Brungard: it's just a link and you
could define a switching type if needed. Deborah Brungard: considering the
framework, it specified the multiple-layer control plane. The inter-op between
the GMPLS control plane and the control plane of the clients should not be the
same. I am not sure the GMPLS control plane would need to interwork with MPLS
control plane. Qilei Wang: I just don't want to involve GMPLS. Deborah
Brungard: then it's very important on how you define that? It's similar as the
client. In your YANG document, you scope it just in the layer of FlexE. You did
not talk about multi-layer. Qilei Wang: No, it's separate. Deborah Brungard:
but as soon as you want to discuss about MPLS client, that would be needed.
It's very confusing that the description of how the control plane is interact,
and in requirement you have flexE control plane should support the LSP
establishement of FlexE, not the reverse, on the MPLS control plane. Yuanlong:
you claimed to have an interface flexE module, but in the model we did not find
it. What is the relationship between your model and the interface? How to use
this model in your mind? Qilei Wang: we just first construct the flexE and then
adapt it into... Yuanlong: How? You need a device so that you have an
interface. What you need to configure? Fatai Zhang: Let's discuss after
Yuanlong's session.

8                 10:28        10        Title:        YANG Data Model for
FlexE Interface Management Draft:       
https://tools.ietf.org/id/draft-jiang-ccamp-flexe-yang-00.txt Presenter:       
Yuanlong Jiang Daniele Ceccarelli: What is the relation with the previous yang
model? Yuanlong Jiang: They are independent Qilei Wang: This draft is to
allocate the slot to the client, the previous one can be perform by the
equipment itself. Fatai Zhang: His one is for interface model, what about
yours? Qilei Wang: it's also interface model. Fatai Zhang: They are same topic,
but different approach. . Daniele Ceccarelli: either progress both with VERY
clear scopes (with no overlapping), or merge them. Fatai Zhang: flexE is a new
topic. We need to decide if we start from the framework or we discard it.
Deborah Brungard: have a framework would be helpful, but not necessary to
publish. Currently we may continue working on converged approach. Yuanlong
Jiang: The framework document is about control, not configuration. Deborah
Brungard: the framework is showing a routing, that has an interface. So it's
not necessarily a specific framework for flexE. It's an informational document
for multi-layer. John Messenger: the real question behind the debate is whether
the flexE to be the switching layer or not. Fatai Zhang: want to emphasize
FlexE here is an interface technology, without switching capability; This is
different with SPN in ITU-T SG15. Yuanlong Jiang: Yes, just focus on interface,
nothing to do with switching. Loa Andersson: We have to construct multiple
layers as flexE is not switchable. MPLS-TE need to be involved for LSP
establishment. (to Deborah) Given the fact that people may be confused about
the scope, the framework document may be necessary to publish. Deborah
Brungard: on the perspective of IESG, the requirements / use cases/ examples
can be put as appendix for publications. We will discuss it later. (Regarding
the draft) I don't think the current configuration is supported by the hardware
in the physical network, say request explicit slots for flexE. Your idea to
configure via YANG (to request slot) is not there. There is a protocol there,
to notify the other side on which slot to be used, and may not be YANG. You can
work it out together. Yuanlong Jiang: yeah, the details will be proceeded
offline.

9                 10:38        12        Title:        LMP extensions, YANG
models and signaling extensions for SSON and Impairment  Aware RWA Draft:      
 https://tools.ietf.org/id/draft-ggalimbe-ccamp-flex-if-lmp-07.txt Draft:      
 https://tools.ietf.org/id/draft-galimbe-ccamp-iv-yang-08.txt Draft:       
https://tools.ietf.org/id/draft-ggalimbe-ccamp-flexigrid-carrier-label-06.txt
Presenter:        Gabriele Galimberti Gabriele Galimberti: good discussions
about the OTSi and OTSiG. It is important to complete the work on the
flexi-grid spectrum. Daniele Ceccarelli: (about the IA part) are you planning
to write the text of the liaison (to ITU-T)? Gabriele Galimberti: I think we
can write the liaison, we know very well what we have discussed, it's just a
matter to write down the text. Daniele Ceccarelli: Just send it to the list so
the WG can review together. Gabriele Galimberti: Actually in the draft there is
already some text. Italo Busi: Do we need to really write a liaison? or the
companies who are working on this can contribute to ITU-T? Daniele Ceccarelli:
we cannot force people to write a contribution. Italo Busi: No, but people are
interested in solving the problem, and we have noticed the gap, why not write a
contribution? Gabriele Galimberti: I think we can do both.