Chairs: Jeff Tantsura (jefftant.ietf@gmail.com) Chris Bowers (cbowers@juniper.net) Secretary: Yingzhen Qu (yingzhen.ietf@gmail.com) Monday, November 13, 2017 9:30-12:00 Monday Morning session I ; Canning RTG rtgwg Routing Area Working Group Chairs: Jeff Tantsura, Chris Bowers 1) 09:30-09:40 - WG Status Update Jeff Tantsura (JT), Chris Bowers(CB) 10 minutes CB: note well, IPR disclose, administration. thanks to note takers, and we'd like someone to help with Jabber. we have two sessions, Mon and Thur. More core items on Monday, possible intake areas on Thursday. We may move a few things around. there is a BOF on Wed, DCrouting, lot of iscussions in RTGWG will happen in BOF. Docs that passed WGLC: ready to be published. RIP and VRRP need to be updated to be NMDA compatible. LNE and NI Yang are in WGLC. these were done by design team. existing WG documents: draft-ietf-rtg-dt-encap expired, but still useful, so plan to publish it. it still needs more work on MPLS. 2) 09:40-09:50 - draft-mirsky-bfd-p2mp-vrrp-use-case Greg Mirsky 10 minutes Greg presenting. next steps: comments are welcome. we're not channging anything in BFD. CB: it will be good to get some clarification on the IPR. Greg: my personal opinion with this change there is a way to implement without affecting the IPR. CB: the IPR needs to be disclosed, so the WG can decide whether the work around is enough. Greg: I could possibly reach out to reach out to IPR holder. CB: the IPR was disclosed for draft-nitish-vrrp-bfd. greg: we have another draft, bfd multipoint which had IPR disclosure. cb: so the IPR disclosed was for the other draft. we'll take it offline and get this ironed out before we put this up for WG adoption. 3) 09:50-10:00 - draft-adubey-bfd-service-redundancy Ankur Dubey 10 minutes Ankur presenting. Jeff: general comments: the presentation should have more details with use cases. Please include BFD wg, and perhaps that is the right place to do this work. 4) 10:00-10:20 - draft-ietf-rtgwg-enterprise-pa-multihoming Jen Linkova 20 minutes JT: Is there a need to solicit comments in v6ops or other WGs? Jen: No, this is purely related to router behavior, it has nothing changing in scope for v6ops. Indded, all comments are welcome. JT: please ask for comments on mailing list. Jen: I posted on the mailing list. Any comments are appreciated. 5) 10:20-10:35 - Requirements of the protocols between CP and UP and CU-separated BNG device deployment model draft-cuspdt-rtgwg-cusp-requirements draft-cuspdt-rtgwg-cu-separation-bng-deployment Shujun Hu 15 minutes Shujun presenting. Jeff: any question? please go to slide 5. this could work with Geneve instead. 6) 10:35-11:20 - RTG-DT-YANG-Arch YANG drafts updates and discussion RTG-DT-YANG-Arch team 45 minutes Lou presenting. Plan is to close disband this design team before IETF 101, since main goals have been achieved. Lou: Question to shepherd - do we need to have both non-NMDA and NMDA examples? Yingzhen: The document currently has only non-NMDA examples, would be good to have both. Sue Hares: IDR chair in this case. I have some issues in revision in IDR bgp model has a non-nmda model. Lou: the current guidance: if you make a change that's not backward compatible, you have to change the model name. if I do routing-config-2, how do I know it replace routing-config? the document header is not shown in yang model. I'm more focused on the solution. if you're not talking about version of drafts, it's different. Sue: I'm considering the implementation phase. Alia: how do we as routing area continue to update and extend yang models? that piece is not nailed down yet. we need to talk about it. Benoit: I have 30 mins in Netmod talk about it. Dean: IETF should consider what models should be done. so it might be faster. Benoit: it's not routing issue. it's industry/yang issue. Lou: we should inform Netmod ow to handle it. Benoit: there are different areas dealing with yang models. there should be common requirement. Lou: I am not certain that this WG will worry about other areas requirements. Dean presenting implementation examples. Lou: for operations, how many of you are using LNEs? what's the main use case for logical router? Rick Taylor: LNE is to reduce complexity. it's easy to use. Stephane: we're not using LNE now. we're only separating the routing part, but we're looking at full separation. Running lots of services on the same device are complicated, so maybe in future. Dean: it simplifies configuration. Stephane L: not just configuration. one particular feature may prevent you from using a version or upgrade. Jeff: thanks for sharing the experience. Lou presenting. Jeff: thanks for the DT for doing the work. Lou: we have talked to people doing LNE and NI implementations. Once we have more implementations, we will have more experience. Wrap up: See you on Thursday. Thursday, November 16, 2017 13:30-15:30 Thursday Afternoon session I RTG rtgwg Routing Area Working Group ; Canning Chairs: Jeff Tantsura, Chris Bowers JT: Welcome to second RTGWG session. Please note an updated Note Well. Any contribution is covered by it. JT: Before we start - we need to make a decision. CB: There is one document that we reviewed on Monday - it has been dormant for several months. This is policy routing model that originally was produced a couple of years ago that uses Openconfig paradigm. This model is not in NMDA compatible, it is not the direction that the IETF is going. It is still a useful model. It does not show under the documents of RTGWG, it is still there and is still a WG document. We have several options that we can go here. Option 1 is that we do nothing. If we do not think that this work is useful. Second - to use this existing draft as a starting point and evolve it into NMDA model. The third option is to create a new draft in a NMDA compatible option. There is a similar issue that occurred with one of the BGP models. If we find a space for this we need to figure out how to move forward. Sue: I would speak against option 1. I would speak for option 2 or 3. Acee: We need this to be deployable solution in all routing protocols. As somebody who has implemented policy - I would like to work on this. CB: Sue, to clarify - you said 1 and 2 but meant 2 and 3? ?: Does somebody deploy routing protocols without policy? Option 2 and 3 is a question of politics. We can reuse many things in current document, we can make in NMDA compatible. JT: To explain - it is not compatible with our advise on how to do datastore model. Sue: IDR BGP model is holding on this. I have solicited on moving this. We hope to get BGP model that depends on this in 2 weeks. Please move fast. We have a prototype one. JT: The plan is to contact the authors of original draft and ask whether they want to make a version 2 IETF document. If they say no we will move to option 3 acknowledging their work. Sue: Is that []? JT: What I said is that we are going to contact the authors. Rob Wilton: The actual convergence is actually done. The actual pushback is option 3. JT: We fully acknowledge the work that the authors did. We would like to use approach 2 before approach 3. 1) 13:30-14:10 - IETF technologies supporting virtualization and slicing Jari Arkko 40 minutes Jari presenting, [presentation] The background for this work is the growth of work on virtualized network solutions and data models. We are frustrated of discussion around Netslices. It is a nice concept but not precisely defined, does not look at what is existing. Existing technologies could be reused - we need to understand that. Terminology is important but it should not drive the technical means. There is a big role for software too. What is the role of protocols and standards and software. Possible new work - what should IETF be working in this space? Greg Mirsky: One of the NS use cases is ultra reliable and low latency services and that is where PM and SLA assurance is a critical thing. We do have some PM protocols here at IETF, it would be interesting how that works end to end. Where do you think it belongs? Maybe we do not need new protocols but we need to see how it works. Services are so critical that we cannot operate the network in a way that the service is not available. Jari: You bring up a very good point. It will require new work on special requirements. [discussion] Dean: When you mention SLAs - that is a slippery slope. You have packet SLAs and business SLAs. Which ones do you want to discuss? This is one thing that we would need much more input, reach on NANOG, RIPE and get the input on this aspect. Create new liaisons to exchange that information. Jari: When I mentioned SLAs I was meaning the context of aligning industry and terminology. ?/UCL: I have some confusions brought up with your slides - you mentioned virtualization, VPN, NS quite a lot - do you see those as interchangeable or separate concepts? You say there is frustration that people are not building on what is existing. Jari: The terms that I used have many possible meanings, I cannot say that they are the same thing. I try to speak on the general topic area that is network virtualization, but it also covers resource reservations and service guarantees. ?: Second one was on cross domain issue. Jari: I think there are many people that think that cross domain is the right thing to do. I do not say that we should not do it but it is demanding. Or maybe I am wrong and it is easy. Adrian: The third bullet - the ability to specify the underlying VPN - do you mean specifying this at service level or network level? JT: Interdomain in general is not an issue for IETF, we have been doing it for many years. We haven’t been doing interdomain connectivity across services. Maybe service level API would be the right level to interwork. Adrian: Work out the right level of abstraction and then specify. JT: There is service level work at IETF interacting with [] well established []. For this particular use case []. It is much more complicated [] [audio unusable] Adrian: Terminology - I would like to see short concise definition of NS. It may be a target trying to define NS. Jari: I was thinking of more fundamental pieces of terminology. It would be difficult to find it. CB: Cutting the mike line. Georg Mayer: I am 3GPP liaison to IETF. Discussing it this way is a very good approach, it allows us a possibility to bring things in. We have a tight schedule at 3GPP, we see NS affecting us, it affects CN and Radio part, it also affects the management part. We need to sort the internal communication needs, how much can we participate in that work soon I am unable to answer. Jie Dong: There are some emerging services that require guaranteed performance together with existing services. Tailored network. Another point - consider NS in different layers of the network. What existing network technology can provide and not the layers match together. Georgios Karagiannis: I assume the alignment of the concepts and technologies - it is also the case? Looking to 3GPP that is focusing on NS - there are some concepts that are already similar. 3GPP has work that is somehow similar to what you plan to do. How to ensure that we are not competing? JT: I would not say that their template are a data model. There is work to be done to align. They are not the same things. We need to speak the same language, and the idea of this draft is to provide enough thinking to people who understand the technologies on what can be done. Jari: It is important that we can point people to the future revisions. JT: We expect a lot of inter-SDO management. Alex Galis: I am very encouraged by this presentation. Jari: []. Alex: Virtualizing systems. IETF FORCES WG has shown that it is possible to partition the resources for a purpose. SDN allows for partitioning the resources of the network dynamically and managing flows. [audio unusable]. I would like to highlight differences where slices are substantial. Slices are driven by services. For a slice you need specialized infrastructure to support that service well. CB: We need to wrap up. Complete your question. Alex: Where do you see this additional work, not only partition the resources but also services, as a package. Jari: That is a good point. I do not have an answer at this time. Alex: More discussion offline. Jari: We will discuss this further on the list. JT: This is work in progress. This is work to help other people to understand what the IETF is doing. 2) 14:10-14:20 - draft-ding-netmod-arp-yang-model Xiaojian Ding (remote) 10 minutes Xiaojian presenting. [presentation] CB: I am not sure we understood which model this is conflicting with? You mentioned the specific model. Xiaojian: []. CB: It is not sure that it is clear for people. Acee: Interface model. CB: I want to jump in - this model is pretty good fit for RTGWG. Technically when I think of ARP it is not RTG but INT area, but in this draft you are talking about ARP functionality on routers. It is a good fit to consider for adoption in RTGWG. You have brought it to the right place and presented it here. I would suggest to change the name of the draft, to add -rtgwg- into it. Xiaojian: []. CB: Out of time for this presentation. Would be good to take the comments and responses. Make the changes, post that draft, and describe the comments that you are addressing. JT: Please make sure that you draft complies to NMDA. Alia: ARP is INT area and not RTG, I would like to verify this with INT ADs. 3) 14:20-14:30 - Fast failure detection in VRRP with Point to Point BFD draft-nitish-vrrp-bfd-p2p Aditya Dogra 10 minutes Aditya presenting. [presentation] [discussion] CB: We have reached the point of WG adoption and the consensus was to adopt the other draft except the IPR issues. We will do a quick evaluation and then poll the WG for consensus for WG adoption. Greg: I appreciate your consideration. I know that IPR is very sensitive in IETF, and would like to reiterate what was said in the first session - authors believe to the best of their knowledge that the state of the disclosed IPR does not cover the version. CB: This is a new draft, part of the adoption poll - we will separate the adoption poll and IPR poll. If there is any IPR that applies to p-t-p draft we expect that to be disclosed already. Greg: It was stated in the presentation that the drafts are now split again. CB: I understand that. Now that the drafts are split, I expect that the p-t-p draft will not have any IPR disclosed on it. Aditya: []. CB: If that was the point of separating the drafts - if that is not the case please disclose the IPR on this draft if it exists. Greg: There is one problem with once the IPR is disclosed and it is no longer applicable to the draft, there is no mechanism to withdraw the IPR disclosure. CB: Lou, our IPR consultant will give a comment. Lou: It is my understanding if you create a draft [] as soon as you make a derivative you have inherited the IPR. CB: We haven’t done anything to do that. Stewart: []. CB: []. Lou: I think you can say that IPR does not apply. CB: I disagree with that. CB: We can look at how [] we can write an explanation what the WG understands. Lou: This is a WG document, how to progress. Document WG decision on IPR decision. CB: We agree. Donald: [audio unusable]. CB: It is quite complicated. We will discuss and figure out the path forward. 4) 14:30-15:00 - draft-bryant-rtgwg-enhanced-vpn Stewart Bryant 30 minutes Stewart presenting. [presentation] Greg: We had very interesting discussion - I want to point that traffic engineering does not necessary have to deliver low latency. It can be provided by the physical layer - FlexE for example. Stewart: FlexE is one candidate solution, it is over-allocating bandwidth. We need solution in packet space too - Detnet. Greg: We should try to look for the solution that is good, if there is not solution we need to solve it other way. JT: A question on terminology - you call it virtual network a point to point service. It has to be point to point if it is segment routing driven. Stewart: More generic name for the technology would be useful. Ahmed: Let’s take the blue slice – []. Stewart: You need to reserve resources first. Ahmed: []. Stewart: It depends whether there is enough of resources to do it. Ahmed: You are defeating the purpose of SR. Suppose you have 100 services - then I need to create 100 slices. Stewart: []. Ahmed: It does not have state. Stewart: I do not commit the state until I actually use it. It needs to provide signals to the ingress. Ahmed: If I need to have 1000 services, I need 1000 colors. It is not clear how you are integrating them. Jie Dong: This is for emerging services that require high bandwidth guarantee. This is a mechanism to provide resource mechanism, and you can do aggregation. Stewart: RSVP requires a single label end to end, this allow us to have fewer as you have an ability to share. Lou: What is the new work here? It is really good stuff, but what new is needed? Stewart: This is a different view to what Jari is doing - see what the technologies are. Lou: There was TE WG for that. There is a document in MPLS WG on that too. It is not clear where this should be discussed. You want to use the stuff that MPLS uses. JT: It is an attempt to derive particular behavior. ?/Cisco: I have presented SR for SFC, I have the same comment as Lou. What is new here instead of taking the new ideas and creating the state in the network that we do not need. You take all the ideas of SFC, slicing. Stewart: We try to show how we put components together. Tal: Bandwidth resource reservation is not enough - what is missing? Stewart: You have services competing for it in order not to affect latency. Maybe we could do better flow filtering, but without that we need to have some separation of traffic. This is about isolation. Greg: I think that it would be helpful if we set common dictionary that is already is being used in other areas that work on NS. With SDN there is LSO. It is a part of lifecycle. You do not throw and hope that it works. You have a certain process that you need to follow. Part of that is service activation testing. In Detnet, in some scenarios there are very stringent requirements on bandwidth and latency, I would like to understand that NS itself does set stringent requirements. There are best effort requirements mostly. Stewart: I agree with you. Focusing on stuff that needs to be added in. Greg: This is only part of NS use cases. Stewart: It is not necessary NS at all. Greg: Stringent requirements are part of use cases. ?: This is traffic engineering, discussing this would be appropriate. There is a work that tries to find a general approach for this approach. Should be independent from what underlay is. Stewart: Building models and configuring - yes, it has to be independent, but the underlay is relevant to the design. ?: If you keep the traffic that you allocate for different services. Stewart: Only if you have right properties and even then not certainly as it is statistical. ?: []. Stewart: It depends on various uses. Stewart: It depends on isolation requirements. ?: If you have excess bandwidth reserved and there is no other traffic but no congestion. Stewart: That is not good enough as that is statistical. Wim: There are two purposes of this draft - one is to put everything together. Second is how you do the resource allocation. That is a new work potentially. If you have virtual link that has specific resources, you have the semantics of SR today to allocate specific resources. What you do not have today is a mechanism to allocate SIDs related to queues and link properties. That is a potential new work. My suggestion would be to have focus on signaling in MPLS or SPRING WGs for signaling JT: It is to show that a label can be used as a metadata. It does not introduce new functionality. It is useful work but at this point you do not try to define new protocols. Stewart: I am trying to show what is missing for this solution. Ahmed: You want to guarantee service for traffic that has burstiness in it. It has nothing to do with SR, it is not specific to VPN or SFC. We should focus on specific problem. Jie: This draft is an architecture of the whole solution. Gunter: The missing requirement - some of physical resources cannot be separated from L3 perspective. Is there a reason why this was left out? There is not requirement to take into account different physical resources in the network. 5) 15:00-15:15 - draft-wcg-i2rs-cu-separation-infor-model Ariel Gu 15 minutes Ariel presenting, [presentation] Rob Wilton: You are talking about the information model or YANG model? Ariel: []. [audio unusable] Sue: I2RS WG chair - the reason why we encouraged them to do information model - this is not configuration based. I2RS is completing the work and is trying to send the completing work elsewhere. Dean: What you say control plane separation - are you also saying for separation of PPPeE or management functions as RADIUS and DHCP pools? Ariel: []. Dean: It would be good to clarify which functions you are referring to. Ariel: We have another draft related to architecture. ?: DMM WG is working on separation of mobile gateways. CB: Could you post that to RTGWG list? [discussion] JT: Looking forward for your hackathon project. Wrap Up: Jeff, Chris JT: See you all in London.