Minutes IETF105: ccamp
minutes-105-ccamp-00

Agenda
Thursday, July 25, 2019 (EDT)    13:30-15:30   Thursday Afternoon session I
Room: Van Horne

13:30
Title:Administrivia - WG Status - Reporting on WG drafts not being presented
Presenter:Chairs
Haomian Zheng: (draft-ietf-ccamp-client-signal-yang) the model and open issue
is being tracked on the github, and will update to address the issue. Gabriele
Galimberti: (draft-ietf-ccamp-dwdm-if-lmp) no update on the draft. We assume
they are quite stable. Haomian Zheng: (draft-ietf-ccamp-l1csm-yang) L1CSM need
to be updated and import the new Layer1-types. Gabriele Galimberti:
(draft-ietf-ccamp-flexigrid-yang and
draft-ietf-ccamp-flexigrid-media-channel-yang)flexi-grid need to be checked to
better align with ITU-T work. Dieter Beller: (draft-ietf-ccamp-layer0-types)
layer0 type files are also available on the github. May need to add reference.
Italo Busi: (draft-ietf-ccamp-transport-nbi-app-statement) T-NBI design team is
ready for final round of review (thanks to Dieter and Micheal for the valid
review comments); it is planned to be finished in August and then we are ready
for WG LC. Only issue is that the normative references are mainly in WG status
with one document still individual. Daniele Ceccarelli: This is not a blocking
issue for WG LC, we can do the last call and move the procedural processing to
RFC editor.

13:44
Title:A Yang Data Model for Optical Impairment-aware Topology
Draft:https://tools.ietf.org/html/draft-ietf-ccamp-optical-impairment-topology-yang-01
Presenter: Dieter Beller

Gabriele Galimberti: Actually this is not a question, but it is a
recommendation. When introduce, for example, 3R generator, the layer 0 type
draft should be applicable. And then we are working together to keep this
document in sync with our draft. Dieter Beller: we have general strategy to
have common types yang module for the layer 0, including topology and interface
model. Need better coordination between this work, layer0-types and
draft-ietf-ccamp-dwdm-if-param-yang. Gabriele Galimberti: just reinforced again
the message, on the github there are all these documents and then you can see
how they are aligned and then keep all these jobs synchronized together. Fatai
Zhang: (clarification) assumptions on P7; I think actually the three
assumptions are correct. But based on the ITU-T recommendations, it says that
OTSI may consist of one single carrier or a group of carriers or sub-carriers.
Dieter Beller: Yes, we deliberately did not want to have that because we
believe that it's not likely to have an OTSiG that can contain multiple OTSIs
and so on, to have a second level of inverse multiplexing. And that was the
message of the proposal in the ITU-T contribution. (C1505) We believe that this
overcomplicates the management of the WDM network. Fatai Zhang: Yes, the
purpose of the ITU-T contribution is clear but the contribution and the
proposal were rejected by ITU-T. In IETF we don't define specific technologies,
usually from the control plane perspective. We should follow the ITU-T
recommendations. In this case, if it's not consistent with ITU-T
recommendation, how can we handle the issue? ITU-T is not going to modify the
definition of OTSi based on your proposal. Dieter Beller: Good question, if you
look at the optical transponder today, all the vendors are using single carrier
that is modulated to carry digital information. The Liaison from ITU-T
indicated that 'in future there MAY be multiple carriers carried by OTSi' but
today I think such modulation schemes do not exist in the real network. Julien
Meuric: it is a terminology issue. ITU-T and IETF have separate terminology
systems. We may have alternative terminologies if ITU-T has any restriction.
Daniele Ceccarelli: Moreover, we are not defining the concept of OTSi, it can
be composed by one or multiple carriers. We just support the configuration with
a single carrier. Dieter Beller: Exactly. Gabriele Galimberti: Even if we
decide to model multi-carrier inside an OTSi, we don't know how to do. There is
no existing implementation, Daniele Ceccarelli: Probably be careful when
writing the documents, don't write "we only assume single carrier" but instead
"OTSi can carry one or multiple, but within the scope of document, we just
assume a single carrier. Sergio Belotti: the mangement/control in ITU-T is
single entity, so the number of carriers in the OTSi won't impact much on the
control/management.

14:11
Title:A YANG model to manage the optical interface parameters for an external
transponder in a WDM network
Draft:https://tools.ietf.org/html/draft-ietf-ccamp-dwdm-if-param-yang-01
Presenter:Gabriele Galimberti

Gert Grammel: (as co-author) to clarify, in this draft the proposed interface
model is applicable to different carriers Fatai Zhang: does this draft need to
be reviewed by YANG doctors? Gabriele Galimberti: Yes but not now. Dieter
Beller: did you say you have a github? we should share them in the same github
(as impairment-topology-yang), to ensure that they are consistent and reviewed
by the people who are contributing to the project. Gabriele Galimberti:
Absolutely, it's a good suggestion.

14:10
Title:Yang Models for OTN and Layer 1 Types
Draft:https://tools.ietf.org/html/draft-ietf-ccamp-otn-topo-yang-07
Draft:https://tools.ietf.org/html/draft-ietf-ccamp-otn-tunnel-model-07
Draft:https://tools.ietf.org/html/draft-ietf-ccamp-layer1-types-01
Presenter:Haomian Zheng

Daniele Ceccarelli: process thing - the order for progressing the documents
should be types, topology and tunnel. Layer 0 and Layer 1 types are the next
ones to be moved forward. Haomian Zheng: Right. Daniele Ceccarelli: the yang
doctors are overloaded on reviews. Could we skip the yang doctor review for the
types draft as it's relatively simple? Haomian Zheng: I'm not sure if I'm the
right person to answer. Loa Andersson: do the yang doctors need to see these to
reveiw the others? Haomian Zheng: it'd be efficient to have the same yang
doctor review all three. Daniele Ceccarelli: Sure, I'll see if that's possible
to have a 'cluster review'. Italo Busi: L1 types are used by OTN topology and
tunnels and need to be understood to review them. I don't know if yang doctor
review needs to be done before publishing an RFC Michael Wang: Yang doctors
will want to review the types modules. Igor Bryskin: we've been through this
many times already with other modules. I'd suggest we do the yang doctor review
as early as possible as we get a lot of good feedback from it. If you don't get
it right then many models that depend on the types module will also be affected
by changes. Loa Andersson: a cluster review is possible, but you have to talk
to the people running the yang doctor process. And then request the reveiws
immediately after each other.

14:31
Title:Yang Models for Ethernet TE Topology
Draft:https://tools.ietf.org/html/draft-zheng-ccamp-client-topo-yang-06
Presenter: Italo Busi

Daniele Ceccarelli: why TE topology and not just topology?
Italo Busi: Because we are re-using some of the generic TE constructs such as:
    - inter-layer lock for inter-layer relationship between access link and
    server TTP - plug-id for inter-domain discovery of access links -
    client-id/provider-id to report who is providing the abstract topology
Tarek Saad: so ethernet is a service layer and the underlay is something else?
Italo Busi: yes
Tarek Saad: When you are modeling L2, how is it different with other L2
topology, L2VPN as a service topology? It's not TE constraint but it's still
L2. Igor Bryskin: no, it's only TE. Italo Busi: the problem we solve in this
draft is the client signal over TE tunnels. So when you set up a signal and you
want to see what traffic is on that. You may need a particular signal to go
over a particular tunnel. Tarek Saad: so it is not L2 topology. Italo Busi:
Agree. What we want to say is just the traffic that enters the network from
this access link with VLAN=10, I want this traffic to be carried by this TE
tunnel, and this access link with VLAN=20. Tarek Saad: so the draft links the
service and the tunnel. Daniele Ceccarelli: there is a service and there is a
tunnel, so you said there is no swithching. Tarek Saad: Maybe they should be
divided into a service model and a transport model, where the service is the
access link and the tunnel is the PHY number. Italo Busi: Yes, this is an
Ethernet signal that is basically accessing, that is also clarifying how the
traffic is here, and which tunnel you are using. Tarek Saad: for L2VPN, they
have L2VPN service model, and then they have the tunnel model. Italo Busi: it's
different with L2VPN, the client signal goes over the TE (e.g. OTN) tunnel. But
you have to reference the TE tunnel between the two client points, you have to
model which traffic goes to here (tunnel start), and that's the client signal,
and reference the right link. If you find a link that is not capable to carry
this client signal, you cannot use it. Igor Bryskin: when talking about layer 2
service per se, we are talking about TE Layer 2 service. For example, if you
have L2VPN with some kind of TE constraints or optimizations you will do that.
So it's not about reachability but about traffic engineering. (Yes by Italo)
Igor Bryskin: Second thing, you can think about this is basically an Ethernet
link which is supported by E2E tunnel in the pseudowire. There is also
important use cases, when it's not one E2E tunnel, but multiple tunnels.
(Italo: Yes. ) Italo Busi: There are two scenarios: one is to discover the
access links and another is to support ETH TE Tunnel/LSP path computation&setup
Igor Bryskin: What I understand from you is in most cases you can specify which
tunnel the service is from; but in more general case, it may not from a single
tunnel, but can be two or three with a node in between that can terminate the
tunnel and service. In this scenario, it looks the service is switchable.

14:40
Title:Applicability of GMPLS for B100G Optical Transport Network
Draft:https://tools.ietf.org/html/draft-ietf-ccamp-gmpls-otn-b100g-applicability-01
Presenter:Qilei Wang

No Comments/Discussions.

14:46
Title:Framework for FlexE
Draft: https://tools.ietf.org/html/draft-izh-ccamp-flexe-fwk-07
Presenter: Loa Andersson

Daniele Ceccarelli: (clarification on P8) is it a FlexE link or a collection of
FlexE links, from ingress to egress? Loa Andersson: the FlexE link(s) between
two boxes have to be terminated. But in the control plane you can see which box
has flexE links attached to which box. So you can pick the interfaces. You say
you want to have an Ethernet link with the following characteristics and then
sharing accross toghether with the other side. Each node should have the
capability to select where the flow should go. Qilei Want: can flexE client be
defined as a network layer? Loa Andersson: I don't really think so. Qilei Wang:
I think you use RSVP to set up flexE client connection. Loa Andersson: Sure,
and same way to set up another link. Qilei Wang: If you do this, it makes FlexE
as a network layer. Loa Andersson: the thing I think we can model as a a
network layer is the collection of existing FlexE client in the network, not in
the single link. Qilei Wang: Let me ask in another way, so far according to the
flexE standard, there is no information on the source/dest node address.
without such information how you can set up a FlexE client connection? Loa
Andersson: I don't clearly get the question, how do you do is model driven.
Qilei Wang: I think there is no essential information like source/destination
address, then it's not a layer. Loa Andersson: So you think you can do
something with the same link to the same (like 5 in the example). But you
cannot do it with the control plane. Qilei Wang: We want to set up the
connection with RSVP, that is switchable; Loa Andersson: Then we should start
working on signaling and routing part, it has been done before, and why cannot
be done here? Julien Meuric: as an operator, why do I care the link is flexE or
not? For example we are having a 200G Ethernet service, what we care is only
the bandwidth, but not whether the link is flexE capable or not. I don't see
the value on setting up FlexE LSPs on FlexE-capable links. Loa Andersson: The
assumption here is that FlexE has a bandwidth that is much bigger. Julien
Meuric: Sometimes the path selection can be FlexE capable when do path
computation. But it's always the 'boss order' to decide whether to take it. Loa
Andersson: it's way bigger in bandwidth, and it is possible to split them up in
granularity. So you can actually allocate bandwidth on a flexE client for a
specific purpose. You cannot allocate explicit bandwidth on normal Ethernet,
but can do it via FlexE. On a particular FlexE group, you have a flexE client
that has a certain bandwidth. We can give you all that bandwidth, to you ONLY.
And there's no way of doing that on the regular Ethernet. And that's the point
with FlexE here. Julien Meuric:  IT's just me that unifying FlexE as a kind of
'what will you use, a little stitching or kind of connection really Ethernet,
which is not the way I understand FlexE today. So that's my problem to choose.
David Sinicrope: I am kind of with Julien on this, I mean how is this any
different than what we have with GELS on the Ethernet today? Loa Andersson: We
don't have GELS. David Sinicrope: my understanding of the FlexE links is not
visible to anything above the Ethernet.64/66B right? So how does any kind of
control protocol know that it's even talking about FlexE links? Loa Andersson:
we not use OIF. David Sinicrope: FlexE is hidden underneath and it looks like
Ethernet to the upper layers. So you are saying it's not quite flex. Loa
Andersson: in FlexE you define a flexE client over a FlexE group. That flexE
client is visible to the control plane. David Sinicrope: So when you have an
Ethernet client, they use a flexE link. No FlexE client, FlexE is configured
underneath it. And it's done on a very coarse granular basis by configuration.
So the idea that it's dynamic and we can switch the bandwidth down, you know
with the control protocol to Qilei's point which I think I understood there is
no handle for the control protocol get hold of unless you're exposing it out of
the 64/66B layer, FlexE here may violate IEEE 802.3. Loa Andersson: So what do
you use if you use it from a YANG model? David Sinicrope: Like the static
configuration, I would forget the YANG model. I use the proprietary data model
works the same way, but there's no control for us all to do. Igor Bryskin: Let
me try to help. I think you are talking about different levels. it's true that
in the upper layer it's not just Ethernet, but there can be a different story
that requires different orchestration or control mechanism, think about L2VPN
cases. Is my understanding correct? Loa Andersson: I think so. Igor Bryskin: it
requires different models for different control mechanisms. Deborah Brungard
(no hats): (P8) people are concerned on whether it's switching, the
understanding is no.  As Julien said, we would not look as necessarily having
to prefer FlexE capable, so when advertising flexE, you are advertising how
much bandwidth can be supported on that link. Loa Andersson: So you are saying
that based on a FlexE client, you can advertise bandwith? David Sinicrope: The
way I understand this is you wouldn't advertise it as a FlexE client, but would
advertise it as an Ethernet link with very good QoS characteristics. There's
nothing exposed to advertise in routing.  I can't send it in signaling
protocol. To Igor's point, your distraction would be different. Why? Because
it's in the interface configuration that I can figure the FlexE groups and the
channels and associate them together not in the control protocol and not in the
routing. It can be changed. And then that can be reflected into routing and
into the control protocol.

Gert Grammel: (to Loa) did you intend to extend LMP? From my perspective adding
FlexE to LMP would be sufficient. David Sinicrope: there is work on
flexE-switch technology and switching sub-layer. That part would request the
control protocol in ccamp. It's called G.MTN and is progressing in ITU-T SG15
and we need to wait until it is complete to trigger protocol work. Daniele
Ceccarelli: but this is not the scope of this draft. Qilei Wang: in ITU-T the
FlexE is defined as a section layer of MTN. Daniele Ceccarelli: let the chairs
discuss, and then announce on the list.

15:15
Title:YANG Data Model for FlexEInterface Management
Draft: https://tools.ietf.org/html/draft-jiang-ccamp-flexe-yang-01
Presenter: Michael Wang

Qilei Wang: (P7) for the difference, (speaking on behalf of the other draft),
it would be useful to analyze the pros and cons.  I think we can check
something from Q11 in ITU-T SG15. Say ITU-T G.8023. That would be needed for
calendar reconfiguration. Michael Wang: are you tring to configure the calendar
A and B? Qilei Wang: it's reconfiguration. Michael Wang: First if your model
support NMDA architecture the YANG models and the architecture also can provide
the ability to help you to change the configuration transaction. NMDA can help
you do so via intent datastore. Yuanlong Jiang (Remote): Are such YANG module
itself already supporting multiple store capabilities such as the the
startup/candidate/running. so we don't need to repeat the configuration.
Another point is if you dynamically add a new client, usually it's done in
sequence. And the data plane can still regard the first previous communication
as Calendar A, and the newer configuration as Calendar B. So it doesn't matter.
We provided it in the communication module as a Calendar A or Calendar B. David
Sinicrope(speaking for BBF): there is ongoing works in BBF which is waiting for
YANG model about flexE representation and configuration.

15:25
Title:Analysis for FlexE control & YANG Model for FlexE
Draft:https://tools.ietf.org/html/draft-wang-ccamp-flexe-control-analysis-02
Draft:https://tools.ietf.org/html/draft-xiaobn-ccamp-flexe-yang-mod-02
Presenter:Qilei Wang

David Sinicrope: this model seems more consistent with my understanding of
FlexE. My question is have you confirmed this with OIF? Qilei Wang: No. Haomian
Zheng: (comments to both presentations) even if there is related work in
OIF/ITU-T, we should look into other IETF models, so far there is no clear
augmentation. David Sinicrope: it won't be possible to have ITU-T model
consistent with IETF model, they are mutually exclusive. Michael Wang: Received
an email from my colleague with a lot of open issues. For the model design,
there is still more discussions needed. Daniele Ceccarelli: there is no
agreement a common way forward for the two drafts. David Sinicrope: I think
it's a great place here (ccamp) to start the work.

Adjourn15:30