IETF 101 - CCAMP WG minutes Session I – Joint CCAMP-MANET Monday, March 19, 2018 (GMT) 17:40-18:40 Monday Afternoon session II 0 17:40 10 Title: Administrivia - WG Status - Reporting on WG drafts not being presented Presenter: Chairs 1 17:50 20 Title: Introduction to DLEP (Dynamic Link Exchange Protocol) and applicability to CCAMP Draft: https://tools.ietf.org/html/rfc8175 Presenter: Stanley Ratliff, Justin Dean, Rick Taylor Fatai Zhang: Happy to see bringing this topic to CCAMP. DLEP is similar to LMP (defined in CCAMP), which can be used to exchange information between a pair of nodes. But there are some differences between them. Firstly, DLEP is only used for one-hop, and DLEP signals are run over TCP (except DLEP discovery signals are run over UDP), but LMP messages are run over UDP. Secondly, LMP is called Link Management Protocol, so it can be used for link information exchange but also for managing TE links. Lastly, CCAMP defines protocols for TE. Is DLEP used to address non TE or TE problems? Rick Taylor: DLEP is designed to run only across the local link rather than across the network. We were given very strong push back from the industry, they don’t want to be told what to run over the air because there is very limited resource sometimes. Lou Berger: There are a couple of questions. MANET is talking about things like LMP defined in CCAMP. MANET is looking DLEP, basically it is doing a function as we did for LMP, but for different types of network. Maybe there are some opportunities to some common control here, this is more from TE perspective. DLEP gives you metrics and the destination, so you actually get a whole set of parameters and end points, this is not quite normal TE we are looking at, we understand getting resource availability, ports, lambdas, they have different bandwidth availability, different quality, so there are some scenarios. There might be some opportunities to leverage the knowledge from CCAMP. Daniele Ceccarelli: what kind of parameters can be carried in DLEP? Stan Ratliff: The parameters that can be specified are data rates, maximum data rate, the current date rate, latency on the link, radio metric, radio link quality. Rick Taylor: You missed two. One of the metrics called the resource could be power and how much work the unit is doing. Daniele Ceccarelli: This is TE. Deborah Brungard: the current CCAMP charter says TE protocols but if there is interested in this work we can re-charter later. Amy Ye: it is true that there are commonality between microwave and this radio, but they have different requirements. The microwave is mainly for the mobile backhaul and the equipments are fixed. For example we don’t have the requirement to have a fast discovery in a short time. We are asked by some operators to support some popular protocols such as Netconf. ITU-T already defined some solutions to exchange the radio bandwidth. Rick Taylor: This is great if other SDO already defined, I think they are compatible rather than competing protocols. Amy Ye: Yes, we use different protocols, but for different requirements. David Sinicrope: the worst thing in ITU-T is, how to do the recovery? What to do with that information? Some contributions brought to ITU-T have tried to do this in Layer 2. You don’t have enough features in Layer 2 to do something meaningful. This might be a good mechanism to have more holistic view about what to do. Stan Ratliff: When we defined DLEP, we tried to be very careful about defining what data traverse the link from the protocol perspective. In the DLEP implementations I have seen there is signaling and the DLEP process picks up the data and signals it to layer 3. David Sinicrope: Some mechanisms have been discussed there like triggering G.8032 Ring protection. It seems something more sophisticated is needed to take more intelligent decisions. Lou Berger: DLEP is always about discovery of Ethernet endpoints. For me, Ethernet endpoints discovery is more interesting than IP reachability discovery. Daniele Ceccarelli: What is the scope? Make CCAMP aware and do things in MANET? Ask CCAMP to go to MANET to provide their expertise? Alvaro Retana: Yes, either way is OK. It depends on whether there are interests here. More discussion is needed to figure out where is the better place. 2 18:10 15 Title: DLEP DiffServ Aware Credit Window and Control Plane Based Pause Extension Draft: https://tools.ietf.org/html/draft-ietf-manet-dlep-da-credit-extension-04.html Draft: https://tools.ietf.org/html/draft-ietf-manet-dlep-pause-extension-03.html Presenter: Lou Berger Lou Berger: We will go for 3 documents for split and we hope we will go for LC before the next meeting or maybe immediately after the next meeting. 3 18:25 15 Title: Moving Traffic class ID to a new draft Draft: https://tools.ietf.org/html/draft-ietf-manet-dlep-da-credit-extension-04.html Presenter: Rick Taylor Justin Dean: I think going for last call is a reasonable thing to do. Adjourn 18:40 ----------------------------------------------- Session II Wednesday, March 21, 2018 (GMT) 9:30-12:00 Monday Morning session I 1                 9:40        10        Title: Transport Northbound Interface Applicability Statement Draft: https://tools.ietf.org/html/draft-ietf-ccamp-transport-nbi-app-statement-01 Presenter:        Italo Busi                                         Daniele Ceccarelli: (regarding the issue "do we need to coordinate with other open source projects?") in an ideal world, “yes”, but it is almost impossible to do everything. Try to focus on our original scope, which was our major activity. Italo Busi: yes, we focus on the use cases. The question is, do we want to look at all the SDOs? Daniele Ceccarelli: If you have time, you could do that, but I am not asking you to do it. Regarding the liaisons, IETF has formal liaison relationship with some SDOs, but not all. If you want to prepare a liaison, we can discuss it.  2                 9:50        10        Title: A YANG Data Model for Microwave Radio Link                                         Draft: https://tools.ietf.org/html/draft-ietf-ccamp-mw-yang-04 Presenter:        Jonas Ahlberg                                          Amy Ye: (on the proposal to break the model into two parts) I would like to break it out, so it can make the models clear, and it is easy to upgrade each individual model, it won’t affect another one.  Tom Petch: it's better to split the models, since they may have different lifecycles. But if you can make sure it won't change in a few years, you may keep them together.  Daniele Ceccarelli: when you talk about life cycle, are you suggesting splitting two models into two different drafts?  Tom Petch: It could separate the modules in the same draft. It depends on what will happen to the list. Amy Ye: Tom suggested to keep them together if they don't change for “a few years”, I would like to understand how long would that be, 3 years or 5 years or longer than that?  Tom Petch: I don’t know what likely the lifecycle would be. If it will be stable for 10 years that’s fine, otherwise splitting would give more flexibility.   Jonas Ahlberg: technically it is stable, but we cannot guarantee 10 years without changing.  Amy Ye: yes, 10 years is too far to anticipate. But I expect that it would be kept unchanged at least 3 years for the microwave types.  Daniele Ceccarelli: we have been working on YANG models for a while, I would like to see something published. This is the most appropriate module for publication as it is stable and not dependent on any on-going drafts and this one is based on published RFCs. So, this is the one we can progress. If you feel there is a number of parameters of a portion of the models that are stable and would not be changed, we can split the document and progress just that one. If the split makes sense, we can progress the document. If it does not make sense, we can discuss. But I am personally trying to progress the document before the next meeting. It's the authors decision whether to split the stable part out, or keep everything together.  Jonas Ahlberg: I don’t believe it is possible to split into two parts, one part is stable, and one part is more likely to change. The parameters we are talking about are the key to the modules, and we cannot break out and say we take care of them later on, they are core for the models. Secondly, we have defined identities for the purpose to make it easy to extend them if it is needed. Daniele Ceccarelli: So the model is quite future-proof, which means keep everything together should not be a problem? Jonas Ahlberg: Yes. Amy Ye: Split is not introducing technical changes, more structure arrangement. Personally I am fine to either way, either split into two models, or keep in one draft and move together, but I would like see to progress it. Tom Petch: My suggestion is still to split into separate modules in the same draft/RFC.  3                 10:00        10        Title: A YANG Data Model for Microwave Topology Draft: https://tools.ietf.org/id/draft-ye-ccamp-mw-topo-yang-00.txt Presenter:        Amy Ye                                         Luis Miguel Contreras Murillo: Is this model also applicable to configure the device? Is it possible to use a different model at the SBI? Amy Ye: I think so. It would be the input to PNC and used to configure the device. Fatai Zhang: in the 2+0 example, why the two individual component links cannot be treated as two bundled links?  Amy Ye: Discussed with TE topo experts, we are discussing whether those links are TE links. If it's not a TE link, it should be shown. This should be generic problem, ETH also have ETH LAG, but how to model the ETH LAG is not discussed yet. Here we present one way to model radio LAG, if there's better idea, we could update.   4                 10:10        15        Title: GMPLS Routing and Signaling Framework for Flexible Ethernet (FlexE) Draft: https://tools.ietf.org/id/draft-izh-ccamp-flexe-fwk-05.txt Presenter:        Mach Chen                                         Daniele Ceccarelli: which option you are suggesting now (among the ones presented in the slides)? Mach Chen: we don't have any preference so far.  Daniele Ceccarelli: I prefer the 3rd option (option-12).  Dieter Beller: we did provide comments in both Singapore and on the mailing list, I don't see them fixed in this version. What are the next steps regarding the comments? Mach Chen: we may handle it in later version. This version just added a new section summarizing the open issue.  Daniele Ceccarelli: is there already an agreement?  Dieter Beller: no.  Daniele Ceccarelli: please resume the discussion on the list. (will do that) Fatai Zhang: why 3 options for the multi-layer? does it imply that existing mechanism is not sufficient? Mach Chen: This is just for information in the framework.  Fatai Zhang: if you pick one of these options, do you need different protocol extensions? Mach Chen: no 5                 10:25        10        Title: GMPLS Routing and Signaling Framework for B100G & GMPLS Signaling Extensions for B100G Draft: https://tools.ietf.org/html/draft-merge-ccamp-otn-b100g-fwk-03 Presenter:        Qilei Wang                                         Iftekhar Hussain: the conclusion is based on the current scope, is it correct to conclude no signaling and routing extension? Is there an email available?   Qilei Wang; Yes. An email was sent to the author list to report the discussion with ITU-T expert. Daniele Ceccarelli: we can liaise once the WG adopts this work;  Fatai Zhang: (to confirm) is there conclusion that no extension is necessary?  Qilei Wang: confirmed based on current scope.  Fatai Zhang: so it's like RFC7139 to be fully reused. What would be the value of this work if there is nothing new needed? Qilei Wang: some new stuff emerge, we need such a document to evaluate whether there are some new extensions needed. Eric Gray: usually we take a framework and wait for solution. Unfortunately there is no solution yet, what is the point to have this work?  Daniele Ceccarelli: the applicability with the latest G.709 is necessary, but we need to change it to applicability.  Eric Gray: it would make sense if there is applicability statement.  6                 10:35        10        Title: YANG data model for Flexi-Grid media-channels Draft: https://tools.ietf.org/id/draft-vergara-ccamp-flexigrid-media-channel-yang-01.txt Presenter: Young Lee                                         Daniele Ceccarelli:[poll] How many people have read the draft? Quite a lot [poll] How many think it's a good starting point for a WG document. Less than previous People that didn’t raise hand please come to the mic and share concern. Tom Petch: Administrative comment. I don’t see compliance with the YANG model guidelines. Each YANG model should look at the guidelines. Igor Bryskin: You augment the base TE tunnel. Wouldn’t it be better to augment the WSON YANG instead of the base TE tunnel? Young Lee: Discussed before for topology. The WG decided to keep WSON and flexigrid as separate models augmenting the base TE tunnel. It’s a question for the chairs. Igor Bryskin.: Separating tunnel from topology is ok, but if you augment flexi grid and WSON independently you risk repeating a lot of semantics.   Young Lee: Didn’t fully get Tom’s comment. Tom Petch: My question is how much the module is complaint with the YANG guidelines which is recently published as RFC?  Young Lee: understood, will look into that.  7                 10:45        15        Title: A YANG Data Model for Client-layer Topology Client-layer Tunnel and Optical Transport Network Client Signals Draft: https://tools.ietf.org/html/draft-zheng-ccamp-otn-client-signal-yang-02 Draft: https://tools.ietf.org/html/draft-zheng-ccamp-client-topo-yang-02 Draft: https://tools.ietf.org/html/draft-zheng-ccamp-client-tunnel-yang-02 Presenter:        Haomian Zheng            Igor Bryskin: We have the service mapping discussion in TEAS. Please be careful in separating service mapping and adaptation functions (the latter can be already done with topology model). Haomian Zheng: will work offline to find a balance. Dieter Beller: Question for clarifcation. You are saying that there are some differences between the ETH client signal and other client signals. Can you explain what are these differences which make it so difficult to have a common model? Haomian Zheng: You can see in the ETH client a lot of parameters very technology-specific, that are not applicable to the other client signal. There were common parameters, but most are defined in TE generic models. We are augmenting TE models so that won't have much in common between ETH and other client signal models.  Glenn Parssons: Why are you creating a ETH YANG model? There is already one in IEEE, MEF and ITU. There are also other activities in IETF. I don’t understand why we need an ETH-OTN YANG model. Haomian Zheng: This specifies how to configure an ETH service given there is a transport network that is carrying the ETH service and configured the ETH link after the transport network is setup. Glenn Parssons: MEF defines the ETH service model. IEEE is working, ITU-T model  Amy Yee: There's also a ETH PHY models in ONF. MEF model is different the model defined here, MEF models is a customer service model.  Italo Busi: IEEE is more 802.1 bridge model, a device model. That is different from these drafts. These drafts are applicable at the controller's NBI where TE Topology and TE Tunnel models are used and provide technology-specific augmentations to the TEAS YANG models and how to map client services (ETH and others) to the OTN Tunnel. Daniele Ceccarelli: Let’s try to focus on what is missing. Igor Bryskin: Different SDOs define different part of ETH. Here in CCAMP we are mostly focusing on TE.   8                 11:00        10        Title: Interworking of GMPLS Control and Centralized Controller System Draft: https://tools.ietf.org/id/draft-zheng-ccamp-gmpls-controller-inter-work-01.txt Presenter: Haomian Zheng                                         Dieter Beller: The resource update could also be done by NETCONF updated. Dieter Beller: What's conclusion from the Chair regarding the draft? Daniele: WG adaptation is deferred to the mailing list 9                 11:10        10        Title: A Yang Data Model for L1 Connectivity Service Model (L1CSM) Draft: https://tools.ietf.org/id/draft-fioccola-ccamp-l1csm-yang-01.txt Presenter: Giuseppe Fioccola                                         Fatai Zhang: Good support in last meeting, this is a useful draft for the industry. [poll] how many people has read the draft? a reasonable number [poll] how many think it's a good foundation? A little bit less  Discussion moved to the list 10                 11:20        15        Title: Signaling extensions for Media Channel sub-carriers configuration in Spectrum Switched Optical Networks (SSON) in Lambda Switch Capable (LSC) Optical Line Systems.                                         Draft: https://tools.ietf.org/html/draft-ggalimbe-ccamp-flexigrid-carrier-label-03 Draft: https://tools.ietf.org/id/draft-ggalimbe-ccamp-flex-if-lmp-04.txt Presenter: Gabriele Galimberti                                         First draft: Dieter Beller: Are you aware of the latest ITU-T work on inverse multiplexing an OTSiG? They are going in the same direction. They are addressing a service with large data rate, looking at subcarriers with granularity of 12.5GHz. This is suitable for this kind of application. Gabriele Galimberti: What is missing here is the link between ETH and OTN on the router. Dieter Beller: Regaridng the grandlarity, this goes beyond G.709 Second draft: Fatai Zhang: Is it possbile to use OSPF-TE to advertise the link capabilities? Each end to the other. Gabriele Galimberti: Yes. Daniele Ceccarelli: Probably this is one of the most mature draft.  Gabriele Galimberti: There is an implementation running. Can be improved. Daniele Ceccarelli: [poll] How many people have read the draft? Some [poll] How many support adoption? Just two (less than the people that have read it). Need to discuss more.  11                 11:35        10        Title: Optical Interface management                                         Draft: https://tools.ietf.org/id/draft-dharini-ccamp-dwdm-if-param-yang-04.txt Draft: https://tools.ietf.org/id/draft-dharinigert-ccamp-dwdm-if-lmp-06.txt Presenter: Gabriele Galimberti Daniele Ceccarelli: Time to take a decision on progressing the drafts or stop working on them. What do you believe is more urgent? The YANG model or the LMP extensions? Gabriele Galimberti: In my opinion the LMP is more urgent since there are interop tests between different vendors. Daniele Ceccarelli: [poll] How many have read the LMP draft? Two. Do not take any decision.  12                 11:45        5        Title: YANG models for WSON IV                                         Draft: https://tools.ietf.org/id/draft-galimbe-ccamp-iv-yang-05.txt Presenter: Ruediger Kunze                                         Dieter Beller: My comments to the mailing list regarding the IV GMPLS apply also to this draft 13                 11:50        10        Title: Finite state machine YANG model augmentation for Transponder Reconfiguration Draft: https://tools.ietf.org/id/draft-sambo-ccamp-yang-fsm-transponder-reconf-00.txt Presenter: Nicola Sambo                                                 Igor Bryskin: Distinguish from soft and hard failure. If it's soft there is no hurry and the SDN controller can be notified and take consequent actions. If it’s hard there is no time for communication between nodes and controller. Where do you see the real in pre-programming the configuration on the nodes? Nicola Sambo: More scalability for the controller and faster reaction. This can be installed also in the SDN controller. Igor Bryskin: You assume a device has a scripting environment, this would contribute to the latency of the restoration.  Daniele Ceccarelli:  Failures is just a minor subset of things you can do with FSM. Moreover this is just the technology specific extensions of a generic word done in Netmod. Your comments should go also to Netmod. Igor Bryskin: Then there is no rush. Adjourn                 12:00