============================================================================== TEAS Session 2 -- Joint with CCAMP, MPLS, PCE ============================================================================== > > Thursday July 20th 2017 > 13:30 - 15:30 - Thursday Afternoon Session I > Room: Congress Hall I > Meetecho: http://www.meetecho.com/ietf99/teas > Audio stream http://ietf99streaming.dnsalias.net/ietf/ietf993.m3u > > Num Start #Min Information > 0 13:30 10 Title: Administrivia > Draft: > Presenter: Chairs > 1 13:40 15 Title: YANG Data Models - TE Topologies > Drafts: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/ > https://datatracker.ietf.org/doc/draft-liu-teas-yang-l3-te-topo/ > https://datatracker.ietf.org/doc/draft-liu-teas-yang-sr-te-topo/ > Presenter: Xufeng Liu Rob Wilton: It looks like you produced the -state models by hand and optimized the size of them, which is fine, but an easier way to create the -state model could be to just copy the NMDA model and change the name and namespace namespace with -state Xufeng Liu: size is a factor, and another motivation is that we don't want to have duplications as they create maintainability issues. We're looking for a tool to fully automate this. Rob Wilton: we will check the tools. Also, the state modules are intended to be temporary; once the NMDA models are ready the state modules will be deprecated as they'll no longer be required. Xufeng Liu: Yes. But some protocols may chose to use state models if they don't want to support multiple datastores. Tarek Saad: I have understood that the -state holds the applied configuration, do we need a -dynamic model for the dynamic data? And if future modules wish to augment this one, will they have to augment the model itself and the -state model, and maybe the -dynamic model too? Xufeng Liu: Yes Rob Wilton: -state model serves two purposes. One is to support the applied configuration value, and the other is allows you to report system created interfaces. There is no intention to have a -dynamic datastore; the intention is that you require a NMDA-compatible implementation to work with dynamic datastores. Tarek Saad: There are implementations that support dynamic creation of objects. How do these work until NMDA comes along? Rob Wilton: They stay in the -state tree. Tarek Saad: does -state hold applied but not dynamic config? Igor Bryskin: This is a good gernal discussin, but in TE topology model we do not consider dynamic datastores. Lou Berger: AD recommendation is that the -state model contains both applied and system-created information, so system-created could be dynamic for a particular model. If there is some other type of "dynamic" not covered by this then we should discuss that, but no-one has identified that yet. Sue Hares (I2RS Chair hat): The benefit of the topology model with NMDA is that it can be loaded in the dynamic ephemeral datastore without problems. I think you need to be careful to disambiguate between dynamically-created data and the dynamic datastore. Sue Hares: There is a deployed non-NMDA BGP model which is hopefully a basis for this SR addition. We are working rapidly on an NMDA model. Do you anticipate data coming from a BGP NMDA model plus an augmentation for serviced routing to be lent to your SR-TE toplogy model? Xufeng Liu: They are working on SR TE model to make it NMDA. Sue Hares: So as a guiding Chair I must make sure that all models align wrt NMDA. Pavan Beeram: The model we discuss does not cover SR-TE policy. Sue Hares: there are two types of policy: BGP policy relating to SR-TE, and basic SR policy. Which one were you talking about? Pavan Beeram: right now this is only SR-specific extensions to the TE topology. TE policy mapping is not covered here, but we can discuss where that needs to be modeled. > 2 13:55 15 Title: YANG Data Models - TE Tunnels and Interfaces, RSVP-TE > Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/ > https://datatracker.ietf.org/doc/draft-ietf-teas-yang-rsvp-te/ > Presenter: Tarek Saad YANG-TE Sue Hares: you said you had an update for stitching in tunnels. Did you ever look at points of encapsulation and decapsulation besides labels? Tarek Saad: our generic TE model is independent of the technology and labels can be packet or non-packet and there are other modules that are packet-specific. The label in the model is a generalized-label and doesn't use packet label types. YANG-RSVP-TE Rob Wilton: when you have a NMDA model, the operation datastore will contain the dynamic data. The -state can be thought as a pre-standard implementation of an operational datastore Tarek Saad: my understanding is that there's two datastores, applied and operational: will there be a dynamic datastore? Rob Wilton: potentially, for I2RS only. Tarek Saad: We have lots of dynamic state in this model Rob Wilton: all models have a lot of dynamic state (e.g. BGP peers). That isn't an issue. Rob Wilton: let's discuss offline Sue Hares: I2RS is creating a dynamic datastore, we can help on this. The folks who wrote NMDA made a datastore template. > 3 14:10 15 Title: Yang model for requesting Path Computation > Draft: https://datatracker.ietf.org/doc/draft-busibel-teas-yang-path-computation/ > Presenter: Sergio Belotti Igor Bryskin: There are some important and useful open issues, like the lack of order of relaxation of constraints, which are easy to address. Some are misunderstandings like the last one regarding local protection: we are not assuming the existance of signalling in the TE Tunnel model. Protection is important not just for provisioning tunnels but also path computation. Sergio Belotti: we're just missing LSP state. Sue Hares: the base topology model is going to WG LC. The base question from YANG doctor is whether we are doing just read/write operations, or RPC as well. Pavan Beeram: given the topic discussed in the draft, the RPC is what they are looking for Sue Hares: I agree RPC is what is needed here. Need to discuss if the TE Tunnel model needs to support all three Pavan Beeram: yes, well allow all three in the base model Sue Hares: will you allow edit-writes too? Pavan Beeram: we are not preculiding them at this point Pavan Beeram: we don't normally poll in the joint WG yang session, but given the overlap with PCE I'll make an exception. (poll) How many have read the latest version of this doc? A few. How many think it's ready for WG adoption? more Will take it to the list. Jeff Tantsura: It may be worth reviewing this with external folks (YANG-doctors, etc) while it's going through WG adoption. Pavan Beeram: we don't have a set policy on that, but yes, it makes sense. Jeff Tantsura: it makes the document quality better Lou Berger (TEAS chair hat): if you do it too early you're getting feedback on something that's immature, so the yang doctors should know that. Jeff Tantsura: there are other people who know yang besides the yang-doctors *volunteers to review the draft* Italo Busi: can we share the document with PCE, given that there's common ground? Lou Berger: we've had this before. Agreement with PCE is that TEAS will focus on the architecture side and PCE on the PCEP side, but this covers both. It's easy to keep both groups informed while we're running these joint meetings. Sergio Belotti: the authors sent all open issues to the list, so they can be discussed there. > 4 14:25 15 Title: A Yang Data Model for WSON Optical Networks and tunnels > Draft: https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-yang/ > https://datatracker.ietf.org/doc/draft-lee-ccamp-wson-tunnel-model/ > Presenter: Young Lee WSON Topology: Daniele Ceccarelli: once the TE topology model is approved, what's left to do on this draft? Young Lee: we do not have impairment validation here, although that exists in WSON GMPLS. If people feel we need to add here, we can do that or we can have a separated YANG model augmenting this one. WSON Tunnel: Dieter Beller: I have a question about CCAMP WSON YANG drafts defining the connectivity matrix, why not reusie the connectivity matrix defined in the TE Topology model? Young Lee: when I have started this one, it was a technology-specific connectivity matrix so we have sligthly different implications Dieter Beller: I think is quite the same as the TE Topology model Young Lee: Actually we augment the connectivity-matrix in TE Topology model, but we have to specify WSON references for interface types. Dieter Beller: I am asking why you need this augmentation at all, but we can take the question offline. Igor Bryskin: Agree with Dieter; in connectivity matrix we have all parameters that are sufficient for all layers across the technologies we use, so there is no need to augment this information. Young Lee: Abstract topology will have generic model, but over time you have included specific encoding. That is an issue for CCAMP to resolve. Your model was written after this work. Igor Bryskin: we started with the optical layer and then realized this wasn't specific to that layer, and applicable to abstract nodes an any layer. Young Lee: Charter for TEAS is to produce a generic model - you are violating the multilayer assumptions. Either way is fine but we need to decide as we have other technologies (e.g. OTN, flex-grid). Igor Bryskin: if flex-grid needed more imformation they could augment the topology model, but so far nobody sees the need for this. Lou Berger: this is a classic discussion for CCAMP, where we start with something technology-specific and once we have a solution we had to take a step back and see what is generic and should belong to the generic capabilities. After the specific is done, it is the right time to step back and look at what aspects can be abstracted to be generic. It's always tough for the people who have done the work on their technology as they feel like they're finished and want to ship the draft, and we have to respect that... but if we don't do it we don't end up with generic and re-usable capabilities. Dieter Beller: regarding the connectivity matrix, it may indicate limitations such as switching capabilities, should it be a read-only parameter? Young Lee: yes, should be read-only for topology, and configurable for tunnel model. Igor Bryskin: for physical ROADM this is probably true but if you see the node as an abstract representation of a domain, you can configure the desired connectivity matrix. e.g. you can add path setups to provide optimization. For this reason in the base topology model we have made it configurable but for physical ROADM it is only reporting what is feasible and what is not. > 5 14:40 15 Title: OTN Topology YANG model and OTN tunnel model > Draft: https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-topo-yang/ > https://datatracker.ietf.org/doc/draft-sharma-ccamp-otn-tunnel-model/ > Presenter: Zheyu Fan Daniele Ceccarelli: just a correction to the agenda, the OTN Tunnel model is now a WG document: it became a WG document right before the start of the meeting Igor Bryskin: when we have started working on the TE Topology and Tunnel models we adopted the strategy to produce technology-specific augmentations but more recently we've found that this works well for TE Tunnel but not well for TE Topology. One reason for this is that in the topology, links could belong to different layers, and it is not clear which augmentation to use in case of multi-layer topology as well as in case of multi-functional links. We came to the conclusion that it might be better to introduct layer-specific types rather than layer-specific augmentations. It is a very important question to know how to go about that Young Lee: That's very useful. Where do you take these types? In a separated YANG module? Igor Bryskin: yes Young Lee: that makes sense Haomian Zheng: we are looking for a stable TE generic models from which to generate layer-specific models Igor Bryskin: it is fine to have layer-specific augmentation if you have more constructs, but if you have layer-specific attributes, it is better to define layer-specific types rather than augmentation. Example: FRR applies to the packet layer but not to others, but if you want to have layer-specific parameters for link, you need layer-specific types. This is similar to what we used to do in GMPLS where we defined layer-specific TLVs. Haomian Zheng: I think almost all the parameters here are from existing RFCs. We aren't creating anything new. > 6 14:55 15 Title: Extending YANG for events, actions, and finite state machine > Draft: https://datatracker.ietf.org/doc/draft-sambo-opsawg-ccamp-supa-ext-yang-fsm/ > Presenter: Nicola Sambo (remote) Daniele Ceccarelli: this draft was linked to CCAMP, OPSAWG and SUPA. To CCAMP because it started with an optical use case but it could be generalized: CCAMP can do the technology-specific extensions but the base work should be done in other places, not clear where. Haomian Zheng: considering the use case, it seems you are trying to trying to optimize the message flow in order to improve the performance. Are you introducing additional functions? Nicola Sambo: It is not to optimize performance; we have some performance parameters to monitor which have to stay inside an acceptable range. It is enough that it is in the aceptable range. If outside the range and becoming critical, creating problems to the service, we then take some action. Our use case is more related to maintenance of the service. Greg Mirsky: I agree with your statement about generalization of this work. A couple of pointers: work in LMAP that defined their framework and data model for a controller that performs performance measurement and passes the information to a collector which can then monitor quality of service and uses a new performance-measurement registry. Secondly, if we talk about packet networks, then there will be more than one metric that will be monitored, so the mechanism should be extended to combine multiple metrics and then allws an ability to define when something goes in and out of a degraded state. Nicola Sambo: Our work started with optics but we tried to make it generic. We should think about packet networks. It can be a use case; any discussion on use-cases on the list is welcome. Regarding performance monitoring, the work you cited can stay parallel to this work because we are not defining any way of monitoring, but our system will exploit some monitoring system. Dieter Beller: I have a question about the use case that's used as the major motivation for this. I have understood that the optical transponder can autonomously change its mode of operation depending on the signal quality. Typically when the signal degrades you have to switch to a modulation scheme that also has an impact on the service datarate, which is typically reduced. That means that if a transponder that can carry 2x100GigE degrades, it will only be able to carry 100GigE. This has an impact on the services that have to be dropped and I have doubts about whether this should occur autonomously. I would prefer that an SDN controller or NMS subscribes to receive telemetry data from this transponder and that an alarm be raised, and then the controller can take action e..g, re-routing some services, or the operator can do something, rather than letting the transponder autonomously take actions that may impact traffic. I do not expect these events to happen very often. Nicola Sambo: the use cases come from the Orchestra project with services that admits the reduction of the rate under some conditions. Amy: if you wish to speed up the rate reconfiguration this could be done by the data plane without involving the control or management plane. Secondly, the work is generic: we have a similar feature in microwave networks. Nicola Sambo: regarding the first comment, I do not see another way to re-adapt the transmission parameters without going to a centralized controller with the current state of the art and this is time consuming Amy: you can make the decision on the node itself Nicola Sambo: maybe you can do that in a single-vendor scenario while it not easy in a multi-vendor case without going through a centralized controller Amy: this is already done in microwave systems, we can discuss offline Jeff Tantsura: a few comments on extendability. Splitting your use cases might make it easier for people to consume, especially as you go to the packet layer. Secondly, your conditions are binary at the moment, and in the packet layer they won't be. Thirdly, usually there's a number of conditions on which you'd want to perform logical operations in order to come to a conclusion. Pavan Beeram: further discussion on the technology specific use case to continue on the CCAMP mailing list 7 15:10 15 Title: BBF Yang Update Draft: Presenter: William Lupton (BBF Liaison Manager) Lou Berger: Are you aware that ietf-interfaces will be revved? William Lupton: Yes Lou Berger: It is good for this group to know that - please see the netmod list for information. William Lupton: several of the drafts presented today have had a section on NMDA, and that will impact us too. Lou Berger: I wanted to make sure BBF was aware of it. William Lupton: We are now :) We will be impacted both by the updates to the interfaces and entity models. I think our reaction is likely be in line with the IETF's own WGs. So you will delete the state tree, rather than deprecate it? Lou Berger: I am just saying that the update is half-way done. William Lupton: We are interested in having the alarm management draft updated in CCAMP. Daniele Ceccarelli: It is an individual draft so we have no power over it - please contact the authors. William Lupton: I have done so. Hopefully there will be progress before the next meeting. We haven't decided to what extent we'd like to augment this draft vs bringing some proposals back to the IETF. Lou Berger: You can submit an alternate individual draft. William Lupton: We'd prefer to work with the authors. We do understand that our members have to bring proposals into the IETF rather than make demands. Jeff Tantsura: We started a discussion a few IETFs ago about SD1 data models. I heard BBF are working on that so we would like to cooperate. William Lupton: Hopefully there will be some projects where non-members can contribute, but we do recognise the problem of some work being done in a closed environment. Pavan Beeram: that's all: see you all in Singapore. > Adjourn 15:25 Minutes by Haomian Zheng, Italo Busi, Matt Hartley