TEAS Agenda For IETF 102 Version: Jul 17, 2018 Wednesday, July 18th 2018 09:30 - 12:00 - Wednesday Morning Session I Location: Centre Ville Slides: https://datatracker.ietf.org/meeting/102/session/teas Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-102-teas?useMonospaceFont=true Meetecho: http://www.meetecho.com/ietf102/teas Audio stream: http://ietf102streaming.dnsalias.net/ietf/ietf1021.m3u Jabber: xmpp:teas@jabber.ietf.org?join Available post session: Recording: https://www.ietf.org/audio/ietf102/ YouTube: https://www.youtube.com/watch?v=340B3qS1pDc 0:00:00 0 9:30 10 Title: Administrivia & WG Status Presenter: Chairs Deborah Brungard: re ACTN: the framework has surpassed the requirements and provides much more detail, so we need to figure out whether or not we need to publish the requirements separately. The AD watch list is a way to let the requirements doc die if need be. Lou Berger: if you think there's important text there please lift it and put it in other documents. 0:07:20 1 9:40 10 Title: WG Draft updates Draft: Many Presenter: Chairs Pavan Beeram: We (Chairs) are considering the need for a document giving an overview of the IP MPLS-TE networking landscape. Currently we refer people to RFCs 3272 and 7926. If anyone's interested in contributing, please get in touch. Dhruv Dhody: I'll be taking on the editor role for PCECC use cases to progress the draft Adrian Farrel: the use cases was to support RFC8283 and the IESG doesn't really like use-case documents. I'd prefer to let it die and remain as an archival record Lou Berger: there are various ways of creating an archival record. Why stop the work? Why not take it to WG LC and see what happens there? Adrian Farrel: OK. I was just trying to save Dhruv some work Lou Berger: use-cases are a good way for people to contribute to the WG, and we're always trying to get people to contribute. I don't think we should devalue that work. Deborah Brungard: ensure the doc is strong and has support from the WG and Chairs, and I'll do my best to take it through the IESG. But the IESG will push back. Make sure it isn't something that will be irrelevant in five years. Dhruv Dhody: my immediate goal is to just correct and update the doc, and then we can discuss what to do with it. Igor Bryskin: I agree with Adrian. A use-case doc helps to understand the requirements, which help the framework... but by the time you have a solution the use-cases aren't much help except as an aid to understanding the work. Deborah Brungard: one aspect from the IESG's point of view is that they see use-case docs as delaying solution work. Make it clear that the solution work is in progress when the use-case doc is submitted to them. 0:17:40 2 9:50 15 Title: Yang Data Model - Traffic Engineering Tunnels and Interfaces Draft: https://tools.ietf.org/html/draft-ietf-teas-yang-te-16 Presenter: Tarek Saad Lou Berger: RFC process question: if we extract the types module, can we just change the name of a document that's in refwait state? Deborah Brungard: talk to the RFC editor about that. Loa Andersson: is it the yang naming or the datatracking naming that's a problem? Lou Berger: datatracking Loa Andersson: you can sort that out with a "replaced by" Lou Berger: the problem is that the new doc has the same name. Other problem is that there's a doc in refwait in the RFC editor queue that will need a change to reference the new types doc we're going to create. I'm not sure if we can do that. Loa Andersson: I think we've done that before Lou Berger: that's good to know Dhruv Dhody: You only discuss the association types defined in RSVP. What's the plan for the association types defined in PCEP? I'd prefer they all be in one place Tarek Saad: there are additional association objects in drafts at the moment and we haven't defined those yet. For the PCE ones in RFCs we will look into it. Or another module could extend this one and add those. Julien Meuric (Meetecho): The association mechanism in PCEP passed PCE WG LC. It will soon move. Dhruv Dhody: why define two lists for basic and extended Associations? With YANG you could have only one list making the Extended Association ID optional. Tarek Saad: we have the problem of having unique keys so we decided to split into two lists. We are open to consider better alternatives. Lou Berger: the yang doctors will help with encoding things in the right way. 0:31:00 3 10:05 10 Title: TE Topology and Tunnel Modeling for Transport Networks Draft: https://tools.ietf.org/html/draft-ietf-teas-te-topo-and-tunnel-modeling-02 Presenter: Igor Bryskin Daniele Ceccarelli: do we need multi-domain TE tunnels? Isn't it a P2P virtual network? Igor Bryskin: no, a single tunnel could go through several domains, so if you have a super-controller overseeing the entire network it treats it as a tunnel, but the domain controllers need to be told what to do. Daniele Ceccarelli: how is it different from stitched tunnels? Igor Bryskin: the tunnel looks very different in different domains, e.g. in a transit domain it just has labels at each end. Daniele Ceccarelli: but this is just implementation Igor Bryskin: that depends on how you look at it from the client's point of view. It looks different to the super-controller vs the individual domain controllers. Italo Busi: I think you're missing the difference between CMI and MPI. VN (type 1) is the request at the CMI from the customer. Multi-domain TE tunnel is the way MDSC should implement the request at the MPIs toward different PNCs. Daniele Ceccarelli: why do you need this concept at the mpi level? why can't you just ask for an intra-domain tunnel from teh domain controller? Igor Bryskin: we're talking about inter-domain tunnels Lou Berger: we're providing a toolbox here with the tools that operators can use to do what they want. Daniele Ceccarelli: I think you do not need the multi-domain TE Tunnel since there is another solution Igor Bryskin: the confusion is the level at which you control tunnels. We use the same model for all levels. Lou Berger: vendors implement things differently and carriers use things differently, so we should support both ways of doing things Lou Berger: something we did in TE topology because of its complexity is that we added a section on how it should be augmented in future (e.g. for technology-specific extensions), which is already being used in other WGs. Should we do that here too? And in Tarek's documents, or this one? Igor Bryskin: any model could be augmented, so if we need this section then all models should have it. I think this document is the right place for it if we do Tarek Saad: we're defining a technology-agnostic model, so we need to say how to augment it for different technologies Lou Berger: we're defining very complex modules in this group. The fact that we need this guidance and other modules don't is OK (and that's speaking with any hat on, including Netmod Chair). Which document we do it in is up to the authors. Igor Bryskin: We have sections on how we do abstraction of the topology model. How you do augmentation comes under the same category. Lou Berger: I think Tarek said this should go with the document that defines the module, and that sounds reasonable. 0:46:30 4 10:15 10 Title: Yang model for requesting Path Computation Draft: https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation-02 Presenter: Sergio Belotti Igor Bryskin: I do not advocate this approach (dropping configuration parameters from path computation request). The logic is when you ask for a path with contraints the tunnel will take the path returned by the computation. But there are use cases where local policy is then applied. If we drop this from the path computation request there's a chance the tunnel could use a different path to that returned. So we don't lose anything by keeping things like tunnel name in the request, but we allow the server to do the same thing for the tunnel as the client would. Dieter Beller: I don't understand why we need specific parameters to support policy- or constraint-based path computation without modeling it explicitly. I'd prefer clearly defined policy rules and a path computation request can include an identifier for the policy to apply. Using input parameters that aren't obviously related to policy isn't a good approach Italo Busi: the user may not use the policy and even if you add these attributes you get the same problem. If the server has the atribute and the user doesn't provide it you get false results. We need a very clean design and specify that these attributes are required. The risk is that the user will use the model in the wrong way if it isn't clear. Igor Bryskin: this is the point. The client isn't supposed to know the local policies in the operator networks. The idea is to get the same path for the same tunnel/path computation request each time Lou Berger: are you asking for these parameters to be required or optional? Igor Bryskin: all parameters are optional, but I want an option to be able to specify everything Dhruv Dhody: in PCEP you can include the LSP identifier if you want, and when you do that you identify the path calculation as being for a specific LSP or tunnel. We can do similar here. Sergio Belotti: but it's explicit there, not hidden Lou Berger: should we do a straw poll of the room on this? who would like to go with the authors' recommendation? A few who would like to go with Igor's approach and include these as optional params? More Lou Berger: so more for the optional params, but it's not overwhelming. We should take it to the list. Sergio Belotti: we should discuss on the list, and also talk about use cases for each option. Lou Berger: reminder - the editor of a WG document is responsible for reflecting the WG consensus, even if it isn't their own opinion. You're welcome to argue your case as a contributor Italo Busi: we need to provide good guidelines on how to use the model so people don't do it wrong. 1:04:15 5 10:25 10 Title: Yang Data Models - L3 TE Topology / SR TE Topology Draft: https://tools.ietf.org/html/draft-ietf-teas-yang-l3-te-topo-02 Draft: https://tools.ietf.org/html/draft-ietf-teas-yang-sr-te-topo-02 Presenter: Xufeng Liu Lou Berger: as you update the SR documents, please send updates to SPRING to tell them the work is progressing Xia Chen: will the SR draft include multi-domain scenarios? How do we include cross-domain information? Xufeng Liu: TE handles multi-domain, so it will be similar in SR. Igor Bryskin: do we need a section on how to augment this? Lou Berger: I'd expect this to follow the TE topology augmentation guidelines. If you think this will be augmented a lot, then yes, add guidelines. Igor: how would we know? Lou Berger: use your best judgement as technology experts Xia Chen: I think the SR is different from RSVP-TE multi-domain, so you need to handle that. Xufeng Liu: we should discuss why the base topology model can't handle that 1:13:50 6 10:35 10 Title: SF Aware TE Topology Model - Use-Cases / Yang Model Draft: https://tools.ietf.org/html/draft-ietf-teas-use-cases-sf-aware-topo-model-00 Draft: https://tools.ietf.org/html/draft-ietf-teas-sf-aware-topo-model-01 Presenter: Young Lee Lou Berger: if the documents are ready at the same time putting the use cases as an appendix in the solution may be a good idea. But don't hold anything up. Igor Bryskin: question for Chairs/AD: we have a challenge here. We don't want to overstep the tools that describe Service Function types, etc so we're hoping we can identify the SFs by global IDs that define what a SF is doing and how close in functionality it is to others. Do we wait until the necessary work is done elsewhere or repeat what they're doing and throw the work away when it's not needed any more? Adrian Farrel: this isn't the first time this question has been asked at the IETF. Other WGs are also working on SF chaining. What we did in BESS was to have a single integer identifier of the type of the SF and apply no interpretation of that in anything we touch, so then you can use other mechanisms to describe the SF and index that to your identifier. Young Lee: that's already iin the model Igor Bryskin: the problem is if we want to replace one SF with another, what's the extent to which it could be done? Lou Berger: from a Chair perspective, what you're doing goes beyond this WG's scope. I'm not sure if it goes beyond the IETF's scope or not - could talk to ADs about that. Maybe this is where you put augmentation guidelines in. Pavan Beeram: keep the SFC WG in the loop on this. 1:26:00 7 10:45 15 Title: RSVP Extensions for RMR Draft: https://tools.ietf.org/html/draft-ietf-teas-rsvp-rmr-extension-01 Presenter: Abhishek Deshmukh Lou Berger: rings seem to be hot at the moment - we had presentations on them in DETNET and MPLS too. We should see if there's overlap and make sure we aren't stepping on each others' toes. 1:36:45 8 11:00 10 Title: PCE in Native IP Network Draft: https://tools.ietf.org/html/draft-ietf-teas-pce-native-ip-01 Draft: https://tools.ietf.org/html/draft-ietf-teas-native-ip-scenarios-01 Presenter: Aijun Wang Lou Berger: have you considered the work in DETNET on IP TE flows? Aijun Wang: DETNET work needs a forwarding plane change, and we want to use our existing devices in our network. We'd prefer to just have a control plane change as it's easier to deploy. Lou Berger: from the WG standpoint you should consider it as it'll be coming in. And current forwarding planes support policy-based routing mechanisms. 1:45:50 9 11:10 10 Title: ACTN VN YANG Draft: https://tools.ietf.org/html/draft-ietf-teas-actn-vn-yang-01 Presenter: Dhruv Dhody (no questions) 1:48:10 10 11:20 10 Title: ACTN TE Service Mapping Draft: https://tools.ietf.org/html/draft-lee-teas-te-service-mapping-yang-09 Presenter: Daniele Ceccarelli Igor Bryskin: Same point as I raised in CCAMP: we need a generic framework for this binding relationship between services and tunnels. There should be a framework that describes how we bind services to tunnels, either specifically or based on policy or preferences. Daniele Ceccarelli: I think this is already partially described. We had a previous discussion on whether to do this per service model or something more generic. Igor Bryskin: You're describing bindings at the interface between client and network. I'm looking at something more generic that coudl happen at any node in the operator network. Lou Berger: we're rehashing a debate we had at the last meeting. There was supposed to be offline discussion about this. Young Lee: this is different - we're talking about CMI Lou Berger: It sounds like that discussion didn't happen, so please spend time with the people who made comments last time and this time and sort it out. If you decide you're talking about different things, that's OK. We should not have the same comments over and over again. Adrian Farrel: Lou has asked me to look at this as Techincal Advisor. I think we've dropped the ball on this discussion so we (authors and other participants) need to sort that out. I think something that's missing from this document is to understand the flow of information between different components. We need a description of where this new model fits. Daniele Ceccarelli: this fits at the CMI. Adrian Farrel: that will help decide whether this is an augmentation of the service models or not. Lou Berger: please continue the discussion offline 1:58:00 11 11:30 10 Title: YANG models for ACTN TE Performance Monitoring Telemetry and Network Autonomics Draft: https://tools.ietf.org/html/draft-lee-teas-actn-pm-telemetry-autonomics-07 Presenter: Young Lee Greg Mirsky, via jabber: what's the difference between TE KPI telemetry and PM OAM? Young Lee: we're not talking about OAM here. We're talking about unidirectinal delay here, from the customer perspective. Lou Berger: so it's the difference between collecting the information (OAM) and reporting it? Young Lee: yes Greg Mirsky: have you looked at the STAMP data model? Young Lee: we're not reinventing the wheel here - we're just referencing performance attributes from TE types (link, tunnel, LSP). MSDC has to concatenate all this data from the lower level. If Greg can point out the exact reference I can take a look and give him a reply Greg Mirsky: I think the STAMP module contains all PM metrics and more. [https://tools.ietf.org/html/draft-ietf-ippm-stamp-yang] Young Lee: OK, but this is a customer subscribing to it Lou Berger: did you look at it? Young Lee: yes, in the past. If they have a yang model we can import then we can do that. Lou Berger: how many people think we should be doing this and are interested in this work? Reasonable number how many have read this doc? About the same how many think this is a reasonable starting point for the WG? More than have read it :) Igor Bryskin: we should look at what Greg pointed to as TE types don't exist in a bubble. Lou Berger: yes, please look at the document Greg referenced and report back to the list and will decide how to proceed from there. 2:06:40 12 11:40 10 Title: Applicability of ACTN to Network Slicing Draft: https://tools.ietf.org/html/draft-king-teas-applicability-actn-slicing-03 Presenter: Young Lee Igor: I think it's good work. You mentioned that client-driven automation is missing. I'd encourage you to look at the work in NETMOD for the generic network automation as it's indended for this. Young Lee: Thanks - please send a reference to it. 2:15:00 13 11:50 10 Title: Enhanced Virtual Private Networks (VPN+) Draft: https://tools.ietf.org/html/draft-dong-teas-enhanced-vpn-00 Presenter: Stewart Bryant Lou Berger: do you cover the case where the current toolset does allow mapping VPNs to RSVP-TE? This is deployed. Stewart Bryant: RSVP is clearly a candidate technology to use, but we don't cover that explicitly Lou Berger: it's deployed in the real world. Not widely because of scale issues, but it exists. Greg Mirsky: Would physical isolation e.g. TDM be a strong isolation example? Stewart Bryant: TDM is a good example of strong isolation, yes Greg Mirsky: Do you think that DETNET can be scaled to Internel level? Stewart Bryant: I don't think you can do anything at the Internet level like this. We're only looking at provider networks Andy Malis: there's a draft in DETNET for large-scale networks (as defined by Stewart, not the Internet) Stewart Bryant: we're talking about mobile phone ares, not something where anyone can connect anywhere. Lou Berger: as you move forward, try to clean up the separation between control plane and data plane. RSVP-TE is control plane, not network layer. Dongjie (jimmy): we do want to mention TE LSPs here? Stewart Bryant: we do need to talk about whether resources are bound to the path or the packet. I've been thinking with my lower-layer hat on. Daniele Ceccarelli: a service operator will have VPNS and VPN+. What's the scalabilty? Stewart Bryant: I don't think we'll have one application per service, but considering the resource binding you'll have to do it will look like a lot more compared to a classic VPN where you only have 8 classes of service. Daniele Ceccarelli: so there's still a scalability issue Stewart Bryant: yes. With mobile operators you're sharing the same infrastructure. I think we're talkign more than ten, but not millions. Adrian Farrel: the document is in the right place in my opinion, and is going the right way. I think we need more of a framework to point at things and identify gaps Dean Bogdanovic: I have a concern about the underlying hardware capabilities, but I'll take that to the list Lou Berger: how many people are interested in this work and want to hear more about it? Lots Lou Berger: That's all. See you all in Bangkok Adjourn 12:00