RTGWG Agenda IETF 106 Chairs: Chris Bowers             Jeff Tantsura Secretary: Yingzhen Qu   WG Status Web Page: http://tools.ietf.org/wg/rtgwg/ Jabber room: rtgwg@jabber.ietf.org   RTGWG Session 1  Wednesday, 20 Nov 2019, Afternoon Session I 13:30-15:00 Room Name: Padang   13:30 5m Administrivia Jeff/Chris 13:35 10m WG Status Update Jeff/Chris draft-ietf-rtgwg-bgp-pic has changed shepherd, and Yingzhen will take over. Regarding expired draft: Draft-ietf-rtgwg-segment-routing-ti-lfa: Stephane: we’re in the process of updating it, but it will take more time. Yingzhen: both RIB extension model and routing policy model have been stable, will request last call after this IETF. 13:45 15m Dynamic Networks to Hybrid Cloud DCs  https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/ https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/ Linda Dunbar Stewart: I don’t understand what you’re proposing. You’re talking about proprietary cloud designs which are within the scope of the provider to define and modify APIs, we don’t have standard solutions. You can design a sim layer that they have to map to, but we can’t map proprietary systems. Linda: I’m not proposing a solution. I’m just saying it’s a problem, which might be out of the scope of IETF. It’s just a problem. Wim: you start from problem statement, then you’re mixing SDWAN with net2cloud. You’re putting too much content. You should focus on cloud interconnection or SDWAN. From reading the document personally I don’t do where you want to go. Linda: good suggestion. we’ll focus on net2cloud, taking out SDWAN. Wim: focus on two requirements: internet facing services, and private VPN use cases. Focus on these two areas and make it clear what needs to be done. Jeff T: maybe you can consider separating SDWAN work if you consider it’s valuable. You’ve put lots of efforts writing it. Linda: I’ll write a short draft focusing on problems with net2cloud, not SDWAN. If I found some of valuable parts, I will create a separate document. 14:00 10m Application-aware IPv6 Networking (APN6) Problem statement & usecases and Framework https://tools.ietf.org/html/draft-li-apn6-problem-statement-usecases-01 https://tools.ietf.org/html/draft-li-apn6-framework-00 Shuping Peng Wim: why contain to IPv6 only? Shuping: it doesn’t have to be. We will have to do with extensions for MPLS/IPv4. Wim: SR has both MPLS and IPv6. is it possible to do with MPLS? Shuping: yes, we acknowledge that and we’ve done some analysis. We’d like to carry not only ID but also meta data. Wim: you can do meta data in SFC. Robin: regarding data plane, it’s open. IPv6 seems to be simplest because of SRv6, but MPLS and VxLAN based are possible. For SFC, we don’t think it’s enough. Meta data is not standardized well. Wim： you should make it open although I believe IPv6 is the future. Erik Kline: I’d suggest removing the revenue related part from the document. This has network neutrality issue. In the framework, you have application sending metadata that has some serious privacy issues. You could end up forcing devices in a large network to DPI their traffic, and I don’t see the issues being discussed in these documents. It’s a huge problem. Shuping: we acknowledge the security and privacy issue, and that’s documented in the draft. Some mechanisms such as access control and authentications are needed. Erik Kline: the potential for abuse is not discussed. Jeff T: looking at 6man SRH discussion, they’re focusing on a single domain. You’re proposing Internet wide? Shuping: we could start from a single domain. We discussed with operators and they own their networks as well as the applications. Jeff T: my point is privacy should be a center work. if you can’t provide privacy, technology is not usable. Shuping: my understanding of privacy is information exposed by applications, and the information can be encrypted, also the applications should be authenticated. Jeff T: I’d like you make this the center of your work and make it clear how you’re going to do it. Aijun Wang: I think this is useful, and we want to make sure to make the applications SLA insurance. there are so many applications, if you use application ID and the router may not be able to hold so much information. How do you consider this problem? Shuping: it depends on the device capability. First, not all applications are process this way, only for demanding applications with special needs. Aijung Wang: for traditional network, we classify applications into several categories, and it can be easily deployed. it’s not possible to deploy these many different applications. Shuping: that’s about how to design the application ID. Currently we have segment, and could somehow to categorize traffic into groups. Doc Montcomery: why can’t you achieve with existing solutions like QoS, is it in the draft? Robin: yes. There is problem statement in the draft. Doc: is your ID global unique? Shuping: that depends. It needs to be unique in one domain. And we will need to consider multi domain case. Linda: I found it’s very useful. Even people are concerned with security reasons, we can do something to hide user information. Bring the application information into the network is very helpful, and this has been discussed in other SDOs. Customers want application based forwarding not based on IP address but application ID. 14:10 10m SRv6 Path Egress Protection  https://datatracker.ietf.org/doc/draft-hu-rtgwg-srv6-egress-protection/ Huaimo Chen Kereeti: do you think it will work with SRv6+? Huaimo: if SRv6+ progress, we will consider adding support for it. ChenWeiQiang from China mobile: This is useful. For 4G, China Mobile deployed dual home for protection. I think this can be used in future. Can it be configured more than more back up? Huaimo: we need to consider it. Aijun: can the mapping be done automatically? Currently it’s configured. Huaimo: it can be manually configured. right now it’s controller environment and can be done through controller. Aijun: if this can be deployed automatically it can ease the management of vpn protection. Huaimo: this draft is about basic solution. Based on this, we can extend the automatic solution. Shraddha Hedge: you could use any cast locator, why is it not used here? Huaimo: the locator here provides the association of egress node. Shraddha: just same locator on both PE3 and PE4, and it will be the same SID. Anycast locator. You think it works? Huaimo: yes. Jeff T: for my understanding, you’re providing back up. Unless your primary is down, traffic is send to the primary. For anycast, traffic is sent to any node. Huaimo: I don’t know the exact semantics. Jeff T: you’re proposing backup while Shraddha is proposing any cast, and there is difference. Louis Chan: if you want to protect VPN, do you need to look deep into the packet? How many labels do you need to read into the stack? Huaimo: for vpn, we need more information and the details are in the draft. Stewart: we’re not ready. You need to consider whether any cast is better solution, and whether you’re compliant with architecture design. Jeff T: please use the list to discuss the issues. 14:20 10m Architecture for Use of BGP as Central Controller https://datatracker.ietf.org/doc/draft-cth-rtgwg-bgp-control/ Huaimo Chen John Scudder: why do we need to work on this? People already have been doing for some years and seems like we could do just fine without any RFC. I would discourage the working group to take it. We don’t need an RFC. If you have any convincing reason, please go ahead. Huaimo: we’ve been using this for some time. And some document as informational might be helpful. Stephane: I don’t like you use BGP as a controller, it’s a protocol and south interface, but not a controller. BGP is just an interface so controller could use to program a path, and we already have extensions to do so. Huaimo: you think we should generalize it? Stephane: no, we already have controller architecture in IETF. 14:30 30m I2RS: Mistake or Solution Dean Bogdanovic Jeff Hass: former chair of I2RS. this is the undead coming back to haunt you. The presentation has lots of excellent points. I2RS failed what we want ed to accomplish and end up with models. But we helped NETCONF and NETMOD, and lots of work were pushed by I2RS. RIB model got upgrade. There are lots of inputs that this failed experiment had in terms of pushing on the rest IETF ecosystem to develop good stuff. If we don’t solve problem in IETF and vendors will fork off and do their own things, and the most successful is Google. Walking dead SNMP is returning in many aspects. People are solving exactly the same problem as we did in I2RS. Dean: I agree with your comments. This slides shows the value coming out of I2RS (Initial Services Included in I2RS). I still see controller agent, and I’d say let’s remove that and put in appropriate layers and decide whoever framework we want to support. Jeff Hass: I tend agree and I think those things are necessary. My prediction as long as we force this work to touch NETCONF it shall fail. People in that group do not have an agenda that align with us. Rob Wilton: we got in NETMOD with Andy and NMDA architecture was we almost got to the point of defining what you’d need for I2RS and we didn’t do this the small bit at the very end, so the architecture talks about how you would do a dynamic datastore but doesn’t define one. I still think there’s a small step fro that point of view to enable that functionality because the data models have already been written. Whether that’s the right thing to do is a very different question. Dean: I’ll resist my comment on NMDA architecture. Jeff T: what’s your position? Dean: we have some models and people are not implementing because some models are too big, too complicated. Instead of putting everything under the sun, what framework we need to or API, we should be flexible. Why can’t we have a FIB model and RIB model and understand how the RIB to FIB translation has been done and just compare them and know what is my actual state. I have to know may RIB models and FIB models from vendors to do things like that to give me a much better overview, and what’s actually really on the wire versus some other groups are doing. I’m also worried that we’re pushing too much a 20 year old technology that was first proposed in November 2002. It’s not the friendliest programing tool. Moving forward I’d like to see us being more flexible to those new tools and new frameworks. Decouple NETCONF from YANG, don’t keep them connected. Jeff T: anything actionable for the WG? Dean: I’ll write a draft, set of requirements and action items before next IETF. Jeff T: that would be great. Thank you for your presentation. RTGWG Session 2 Friday, 22 Nov 2019, Morning Session I 10:00-12:00 Room Name: Padang 10:00 15m Extended BFD https://datatracker.ietf.org/doc/draft-mirmin-bfd-extended/  Greg Mirsky Andrew Gray: how’s micro BFD play into this? Greg I don’t know about micro BFD. I know about S-BFD. Jeff T: it’s BFD over LAG. Greg: BFD LAG spans cross a singe hop session. This extension allows you to go over one session. I haven’t thought about it, but I’ll. Andrew Gray: From our perspective, there would be a fair amount of interest in having that either in the negotiation, or the capability negotiation. Greg: basically the RFC as I remember it create only single hop BFD session over constituents session and it has no difference from a single BFD session. Andrew Gray: pretty much yes. But it’s a capability that needs to be enabled on both sides. Since we’re already negotiating all the other parameters we might be enabled as well. Greg: each individual session comes up individually. Jeff T: you need to configure it. Greg: we will work on it. Jeff: micro BFD is useful. You need to consider it. Tony Li: we’ve been trying to get BFD into hardware and this makes it harder. any other way to do it? Not BFD? Greg: I’d like to inherit some good features from BFD, like robustness. Louis Chan: you’re piggy backing all TLVs in BFD sessions. Greg: not all of them. I don’t see the real need for all of them. Louis Chan: if you separate different TLVs into different packets, it’s easy to implement. Greg: I want to stress there is no requirements to do it in a periodic message. 10:15 10m Gateway Function for Network Slicing https://www.ietf.org/internet-drafts/draft-homma-rtgwg-slice-gateway-01.txt Shunsuke Homma Jeff T: speaking as a design team member, step # 1 Ii’s better if we can align the terms. Shunsuke: This document is published in IETF so the terminologies should be idea friendly, I’ll do the modifications. David Allan: I’m trying to understand the relationship between the gateway and 5G network? How’s that related to various interfaces? Shunsuke: slice gateway is not a device but a definition providing a mapping function to 5G systems. David: is it in the draft? Shunsuke: yes Jie Dong: I think it’s useful to document the use cases.  10:25  15m ForCES-based BNG  https://tools.ietf.org/html/draft-haleplidis-forces-bng-00 Evangelos Haleplidis IETF/BBF liaison discussion Chris B: there is a liaison from IETF to BBF. Based on the IESG feedback, in the future we won’t be allocating time for BNG topic unless there is a request from BBF. Evangelos: This is an IETF solution that can actually support it. Chris B: Since you brought it up, let’s have a discussion about the liaison. Dave: Speaking as BBF liaison. We’re gonna suspend BNG topics here in IETF. For BBF activities, there has been a protocol selection done from control plane to user plane, which is PFCP. Topics like this are always welcome in that venue. Evangelos: the importance of this talk is having a data model along with the protocol is useful. David S: there is also work going on at BBF regarding data model and management plane. I can talk to you offline about some details. Dean B: I’d like to see a distributed architecture for BNG that should be implementation independent unless you really have an implementation that you can present the results. Diego Lopez: our intention was to explore unified access for BNG. Whether it’s cable, in genera it’s for the access side and it’s important. Greg: Concur with the previous statement. get the requirements whether it’s access network specifically. Jamel Had Salim: how’s the decision was made regarding the liaison? Chris B: the liaison is public. Jamel: what’s the process of BBF to do this liaison? Chris B: let’s take it offline. David S: BBF changed their bylaws such that everyone can pay a small fee and access the work in progress. Fengwei Qin: the solution from BBF is not covering our network situation. We can talk after the meeting. Evangelos: let’s talk after the meeting. David S: if there are requirements that’s missing in the BBF, you an still submit it there. Evangelos Presenting… Louis Chan: to standardize a protocol in between is a very big challenge. There are many different vendor implementations, only a small standard portion at IETF. There are different line cards, and how you send one message to control plane for those line cards? Evangelos: is the first question how do you standardize the connection to the radius server? Louis: it’s very vendor specific, and only a small portion is standardized, so it’s difficult to standardize the whole thing. Evangelos: it’s already an IETF standard. Louis: you need to translate all the radius from control plane to forwarding plane. Diego: there is no data path to control path using radius. Radius is a subscriber management. Louis: there is still enforcement in someway. Dean B: having a fixed set of basic primitives then have vendor augment it is very useful. Louis mentioned radius is a good example, I like the idea, the question is whether there is any implementation? If you could explain why this is better? There are other frameworks. I can use plenty ways to model it, why this? You need to do the comparison why you should use. Evangelos: ForCES is not only about serialization, it’s an architect that has already specific capabilities like HA etc. for other framework, you will have to develop these. Dean B: except being IETF protocol, I can use existing frameworks. Diego: they’re not IETF standard, and this has been deployed. 10:40 10m SRv6 Deployment Consideration https://datatracker.ietf.org/doc/draft-tian-spring-srv6-deployment-consideration/ Chongfeng Xie Dino: can you put some values about the switchover? How long does it take to make the switchover? In seconds or ms? Chongfeng: it’s in days to get the service up instead of months. Dino: did you do any measurement on the switchover time? Chongfeng: not yet. Tony Li: it’s more about VPN. Any real TE? Chongfeng: no TE yet. Tony LI; There are simpler solutions than SRv6. How much bandwidth have you wasted to get this VPN? Chongfeng: the bandwidth is from Gbits to 10Gbits. Tony Li: you could have done it with simpler solution. Did you consider how much bandwidth wasted? Robin: the benefit is to cross multiple domain. the backbone is pure IP and it’s difficult for VPN. Tony: you could run GRE tunnels. Robin: let’s take it offline. Dino: how many sids are used in each path? Robin: right now only on edge nodes, no SRH yet. In the future no more than 10. David Dai: for the incremental deployment slides, the first step is to upgrade ipv4 to ipv6, and step two is to upgrade edge devices. What if we only upgrade ipv6 in the core network, and edge networks are still ipv4, how does it work in this scenario? Chongfeng: in our case, IPv6 has been deployed everywhere, so we’re considering this is a better solution than SR-MPLS. For other operators, maybe SR-MPLS is a better choice. David Dai: maybe in some cases, we should update the edge devices first. Wim: you’re comparing with MPLS, there are other implementations in IP, then your comparisons are not always true. It’s not 100% accurate with the capabilities we have at IETF. Chongfeng: this is not an absolute comparison. In some cases, SR-MPLS has advantages. Wim: if you want to document how to migrate to SRv6, that’s ok. But if you want to do a comparison, better also consider other aspects. Saturo from SoftBank: thanks for sharing. I’m happy to see SRv6 deployed not from green field. In the future, it will be helpful if you include TE, or flex-algo that will reduce the SIDs field. Inter-domain flex-algo it possible. Chongfeng: it’s depending on the process of compressed sids. Saturo: it’s a bit scary you mentioned compressed SID. For me, 128bits is fine. Jeff T: it’s interesting to see the migration from RSVP-TE, and see how people resolve bandwidth reservation. 10:50 10m SR-TE Path Midpoint Protection  https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding Huaimo Chen Zibo Hu Louis chan: due to micro loop, there is still possible to drop traffic. We can talk offline. Huaimo: the problem you mentioned is invisible. When N fails, P start FRR before IGP convergence. Louis: during IGP reconvergence, there is insychronized state, there will be packet drops. Huaimo: there will be micron-loops but minimum. Martin: use any cast can solve the problem, maybe even faster? Huaimo: there are issues with any cast. Martin: what are the issues? Huaimo: we can talk offline with more details. Stephane: you can’t always any cast in some network design. Martin: any cast works will be useful in some cases. Huaimo: any cast might be a solution for egress, and harder for midpoint. Stephane: can’t you solve by delaying ? not about your solution. Just try to keep your forwarding in your hardware for a couple of seconds. Chris B: Stephane is asking why not just delay installing the blackhole? Keep the old entry. Huaimo: good question, so it’s to delay IP forwarding. Stephane: MPLS forwarding. If we just delay to change it, it works. Only keep the forwarding plane. Huaimo: we need to have some ways to keep the forwarding entry. Stephane: I’m not sure you need to keep the control plane. Huaimo: we need to let them know to keep the forwarding entry for some time. Stewart: presume if you use anycast in the end, all the fast reroute will resolve the issue. P discovers it can’t go to N, then it will go to N’, which is N1, then C. So any cast would work for a very common scenario. Huaimo: if you have details using any cast, please propose the details in the list. Dino: I’d support the idea because if if the SID is an any cast address with reroute, then the headend doesn’t have to change the SRH, and this is very useful. Huaimo: there might be routing loops with any cast and there are other issues. Stewart: in real networks with multiple hops, this solution may break down. If you use any cast at exits, then ordinary FRR could deal with any failure. Huaimo: in theory, and we have pictures showing issues. Dino: Please state the issues. Huaimo: for egress, I’ve sent those issues to the list. If you’re proposing a solution, please give details. Stewart: please state the issues related with any cast. Please specify detail issues. Huaimo: I’ve sent the issues to RTGWG and SPRING. Cendiz: wherever you go you will need an anycast and it doesn’t scale. Jeff T: the working group is demanding comparison with any cast. The best way to address it in the draft, not the list. At least a section with comparison and the benefits you’re proposing. Peter: just for the any cast. Anycast will protect the egress node, but not the node in the middle. If you do any cast, you will need any cast for every node. Dino: you have link-local to realize your IGP. Shraddha: I have a proposal in SPRING talking about using any cast as well as the delaying process that Stephane talked about. I’d like everyone to take a look. Louis: I think we need both solutions. Jeff T: we need to decide with SPRING where the work belongs to. We should be able to converge solutions. 11:00 5m YANG Data Model for ARP
https://tools.ietf.org/html/draft-ietf-rtgwg-arp-yang-model-03 Bo Wu Jeff Hass: I read several versions of this draft and I’d like to suggest to the chairs that this is ready to go three versions ago and WG LC will push the completion faster. Hamasu from Ciena: is static ARP covered? Bo: it’s covered. Jeff T: I will start the YANG doctor review and the process. Thank you for the good work.