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