IETF 110 Routing Area Open Meeting (rtgarea) Joint with RTGWG ===================================================== Routing Area Directors: Deborah Brungard (db3546@att.com) Alvaro Retana (aretana@futurewei.com) John Scudder (jgs@juniper.net) Martin Vigoureux (martin.vigoureux@nokia.com) Web: https://datatracker.ietf.org/group/rtgarea/about/ RTGWG Chairs: Chris Bowers Jeff Tantsura WG Page: http://tools.ietf.org/wg/rtgwg/ Materials: https://datatracker.ietf.org/meeting/110/session/rtgwg Date: THURSDAY, March 11, 2021 Time: 1700-1900 Session III RTG AREA Meeting 1 17:00 15m Administrivia: - Note Well - Blue Sheets - Agenda Bashing - RTG Area Update Routing ADs 2 17:15 35m WG updates: • PALS • MPLS • SPRING • DETNET • RAW WG Chairs 3 17:50 10m Open Discussion / Any other business ****************************************************************** ****************************************************************** RTGWG Meeting 1 18:00 10m Challenges for the Internet Routing Infrastructure Introduced by Changes in Address Semantics https://datatracker.ietf.org/doc/draft-king-irtf-challenges-in-routing/ Adrian Farrel Linda: semantic address, what is it? is it still IPv4 or IPv6? Adrian: what we see is adding semantics to IPv6 address. we might see new address space run ships in the night, but not sure it's my focus beyond what happens beyond IP routing. Linda: what kind of semantics are you adding? Adrian: we're collecting proposals. we want to research around those rather than pushing individual proposal. 2 18:10 30m Application Aware Networking (APN) https://tools.ietf.org/html/draft-peng-apn-scope-gap-analysis Shuping Peng Linda: one comment, in MEF SDWan project, there's a section on application based segmentation. They have a use case of retail payment system, that payment system can only be mapped into certain topology, virtual topology, versus other application can be mapped to other topologies. I think that'll be very useful to use APN concepts. Shuping: would you please post it to mailing list? Uma: Thank you for the presentation. it's good to know that it starts from edge device, it's not limited to any data plane, correct? Shuping: Yes. Uma: multiple WGs are discussion slicing, are you touching slicing issue? or just general QoE? Shuping: it's a general solution. Network slicing could be integrated with a VPN, so mission critical traffic could be steered into the dedicated network slice. That could be one of the use cases of APN. Uma: if it's to be done in IPv6 data plane, is it going to be SRv6 or other extension header? Shuping: If it's IPv6, we could use hop-by-hop header, destination options head, SRH and SRH TLVs. All those cold be sued to encapsulate this information, not new hop-by-hop header. We want to make the hop-by-hop header really usable for the operator because it carries lots of key features and new services. After presenting in V6OPS, it has been agreed by the community and chairs. So the problem statement has been agreed upon. Zhenbin: People in the security area and APP area are not understanding the uses cases that always used in the routing area. The first question asked is how to map to app group or user group at a network edge? We can use five tuples. Second they don't understand why 5 tuples can be used directly? In transport network, there are SRv6 tunnel, MPLS tunnel, so the five tuples of the original packets is not visible in the network. Last question why not copy the five tuple information? Kausik Majumdar: I'm wondering how APN hdr would be integrated with MPLS or IPv4 data plane. Shuping: that's based on solution and we'll figure out later. Zhenbin: Just to add a point, for MPLS, there is extension header here. On Friday, there will be joint meeting to discuss extra information in MPLS data plane, and we might be able to use special purpose label to indicate extension information below the label stack. ----------------------------------------------------------------------- IETF 110 RTGWG Agenda – Session II Chairs: Chris Bowers Jeff Tantsura Secretary: Yingzhen Qu WG Page: http://tools.ietf.org/wg/rtgwg/ Materials: https://datatracker.ietf.org/meeting/110/session/rtgwg Date: Friday, March 12th , 2021 Time: 17:00 -19:00 UTC + 1 1 17:00 15m WG update Chris/Jeff 2 17:15 15m The Integrated OAM https://datatracker.ietf.org/doc/draft-mmm-rtgwg-integrated-oam/ Greg Mirsky Rakesh Gandhi: there is a similar draft in BFD, is it related? Greg: this one replaced that draft. Rakesh Gandhi: it was not clear combining RFC 6374 and BFD, what requirements are addressed. It was discussed in BFD WG. Greg: First to reduce number of OAM protocols need to be supported. Second is to make it light weight. BFD runs at hight interval rate, but the performance measurement doesn't need high rate. The draft has more details of motivations. Protocol like RIFT, already provides infra supports that continuity. It might be nice feature to complement it with the performance monitoring. Rakesh: there is work in SPRING going on. we need to compare with other work in other WGs. Greg: I know you're referring to SR PM work, it's too heavy for continuity. It was not designed at high rate, like 3.3 ms. We're proposing different approach to this problem. what we're doing is try to solve it differently. There is real need to have integrated OAM work. Let's discuss more on which approach is more realistic. Cheng Li: Do you want to extend BFD? Greg: what we're proposing here won't be on top of BFD, more for a new protocol inheriting the best features of BFD, like negotiation. This is not extended BFD, to remove confusions, we marked this draft as replacement of the extended BFD draft. The resulting protocol will be similar to BFD, but not extension to BFD. Cheng Li: we have another proposal that will be presented later. Ville Hallivuori: you have this algorithm of negotiation for security and that's about a decade old. The draft says you don't have authentication. Greg: we appreciate comments and open to suggestions. We can discuss more on the list. Different node can be upgraded at different level is more flexible approach. Your suggestion of mandatory security probably the right way. We need to understand more. Jeff Hass: as BFD chair, It's worth noting that we had long conversations with Greg, about could we put this inside of BFD. his slides makes a good point that what we're doing is we're leveraging BFD like mechanisms, the properties that are sort of liked BFD is being able to carry out information from one system to another in a periodic fashion. We do know that BFD is capable of doing that in terms of its protocol machinery, but we're sort of diluting the core mission of BFD in terms of providing continuity checks at speed. So we did suggest that Greg actually leverage the mechanisms from the BFD for those new mechanism. So, some extent to answer Fan/s question in the queue, we did discuss putting this in the BFD, it's not a great fit. At least in terms of the core protocol. but we're quite happy to see the mechanism that the BFD has popularized carried it to the rest IETF for other purposes. Fan Yang: I see you mention path MTU monitoring here, is it any use case for using OAM to do path MTU discover and monitoring? Greg: normally this is part of OAM functionality. For example, MTU discovery in BIER that uses LSP ping extension. it could be done on demand or periodically. in BFD, there is demand from operator to monitor MTU. I do believe MTU discovery is part of OAM responsibility. Fan: since you mentioned BIER, what data plane do you plan to use this integrated OAM? Greg: appreciate this question. our goal is first to define the protocol, then make it applicable to all data planes. Like BFD supports all sorts of data planes. Rakesh Gandhi: One comment is that with automation and controller, and SDN are fairly advanced these days. The we are doing less and less control plane tunneling and extensions to simplify the control plane. So I think the simple SDWAN is a perfect example of how controller can be used for such use cases. So here in this signaling extensions going in a different direction. Greg: I don't believe so. I don't see that there is anything precluding to have Yang data model for integrated OEM protocol, and then use a centralized controller to instantiate test sessions, whether pre active or on demand as operator desire. so I don't see any contradiction. Let's take it to the list. Jeff T: the questions, especially with regards to BFD extensions, please send to the list, and Greg would be addressing them. From Chat: Rakesh Gandhi Not sure how this draft: https://www.ietf.org/archive/id/draft-mmm-rtgwg-integrated-oam-00.txt -> relates to this draft in BFD WG. https://tools.ietf.org/html/draft-mirmin-bfd-extended-03 Fan Yang why not extension on BFD, I couldn't get it. Jeff Tantsura @Fan - please send your q to the list Jeffrey Haas Jeff T, I'd be speaking to that in my comments if I get mic time. Fan Yang I suppose we should have enough time in this session, so a little bit long q is OK :-) Rakesh Gandhi Seems like combine BFD and RFC6374 to create a new BFD+ protocol Jeff Tantsura Thanks Jeff Jeffrey Haas When protocols become popular, people want to extend them. Sometimes the extensions are good fits, sometimes not. But it's good to leverage ideas elsewhere even if you don't put it into the same protocol. See for example various efforts to put stuff in DNS, BGP, etc. Tony Przygienda Curse of success ;=) John Scudder There's always the tension between dump truck protocols vs cut-and-paste protocols. See also the microservices pendulum. Jeffrey Haas Indeed. Greg now perhaps inherits the dump truck keys. John Scudder Complexity will get its pound of flesh no matter what we do. Jeffrey Haas The question now moves from "what is so important that you want to hear every 3.3ms" to "here's interesting stuff in a periodic basis that you do want to hear - now how to do we pick our timers for that?" Jie Dong Comparing to existing BFD + RFC6374, what is the benefit of this? Jeff Tantsura Jie - please send to the list Tony Li @jgs No, we fight it. Forever. Jie Dong ok Jeffrey Haas Eternal disappointment Jeff Tantsura life isn't fair... John Scudder @tli, sorry for the defeatist formulation. There's probably a gif from Braveheart that would apply here. Russ White state, optimization, surfaces ... choose two 3 17:30 15m Data Discovery Use Cases https://datatracker.ietf.org/doc/draft-mcbride-data-discovery-use-cases/ Mike McBride Joel Halpern: This is confusing. There's already a proposal for how to do SFC service function discovery if you're using distributed system, but it's aimed at make sure that the classifier know where the SF are. Fundamentally SFC is designed for cases where the application, external for classifier function is not choosing the service function. And there are controllers can discover the service functions. This problem is well attacked, I have trouble with this example. Mike: you can have a controller taking care of it. If there is already solutions, that's great. Is that you're saying this particular application has already been solved. Joel Halpern: It doesn't need a whole new tack on the problem. Jim Guichard: I'm aware of the service function discovery document. This is just a example what kind of data we're talking about. SFC is obviously one of those, it gives a picture a particular data store and we'd like to be able to dynamically discover it. Joel Halpern: I get the general need to discover functions, whether that falls into IETF is a whole different debate. SFC is just a bad example, I'm not objecting the underlying problems that Mike is talking about. Jeff T: Speaking as WG chair. This seems to be ocean boiling. do you plan to narrow down your use cases to identify consumer, publishers and how it's relevant to routing in general. Mike: Yes, the next step is to consider the solution part of it, maybe a particular use case. at the end of this ietf we'll try to satisfy a particular problem that we've identified. Jeff T: You should narrow down your problem statement, and make it routing related. Mike: understood. we're gonna think about what solution might solve one of these problems and that will help us narrow down the scope. So yes, we'll narrow it down. Jeff Hass: this is boiling very large ocean. but the two general notions that I think are the interesting ones. you're looking at a general directory/Discovery Service to figure out what are the interesting things I want to get. And over your use cases you're getting the once I've decided that I'm interested in something, how do I actually get it in an efficient fashion that makes sense with the data. Is it something that needs to be reliable? Is it something that I'm willing to get periodic unreliable telemetry stream for, and certainly the second piece of things is for IETF has no good technologies for that sort of thing. We don't really have the sort of dump truck subscription directory. A thing from past history that I have exposure to is corba, where you have basically objects of the system that you may want to get state for and a directory mechanism was created to get to the stuff and published have such things. So I think that directory stuff may or may not itself be within the context of IETF. The other items you have to decide what the properties are you want and decide if you actually have good distribution mechanisms that are fits for technologies we already have. 4 17:45 15m Associated Channel over IPv6 https://tools.ietf.org/html/draft-yang-rtgwg-ipv6-associated-channel-00 Fan Yang Greg: it looks like a combination of two processes. one is error detection end to end, second is protection switchover coordination using remote defect indicator, this is not a new problem. This has been solved using combination BFD and protection control automation protocol. Another question, UDP is becoming predominant transport, why not use UDP? why IP? Fan: If it's only signal degradation, BFD can't detect it 100%. Greg: it's great you mention this scenario. You can look at drafts in IPPM that address your scenario, how network failure, packet loss and delay can be combined together. Fan: let's take it to the list and discuss more. From Chat: Tony Li And now... we recreate FTP! Cheng Li Hi Tony, can you explain more? why this is similar to FTP? Tony Li FTP has a separate control connection. It's a huge security problem. Cheng Li oh? any link? Tony Li Specifically for firewalls.... Cheng Li really good input, many thanks Tony Li https://tools.ietf.org/html/rfc959 Cheng Li thanks, will go to know what is the security issues and other issues of FTP Joel Halpern @ChengLi the short version is that in order to get FTP through a firewall (or any security appliance really) the firewall has to examine the FTP control protocol payload to be able to recognize the data payload and allow it. Jeffrey Haas Similar issues exist in VOIP land. Tony Li Out of band control and management is a fine idea, but how do you securely associate the control/management connection with the data flow? Jeffrey Haas Especially if you need the data and control channels to share forwarding fate Cheng Li cool. It seems like this is a common issue. It may be worthy to address Fan Yang would it be better if the control message is carried with the data? ACH is in the IPv6 header, user data is in the payload ? Tony Li That addresses the association issue, but adds a huge cost in overhead per packet. That does nothing for other forwarding planes, also. Tony Przygienda There is no such thing as packet tax anymore dr li. That was atm ,=) Tony Li There are vendors who seem to be telling their customers that. It's a strategy to waste bandwidth and sell more line cards. 5 18:00 15m IPv6-based Cloud-Oriented Networking (CON) https://datatracker.ietf.org/doc/draft-li-rtgwg-ipv6-based-con/ Cheng Li Linda: couple of comments. This draft covers lots of things. I feel it's too big, maybe break into several drafts. For example. public clouds have longer distance, and technology needed for that is different from edge computing which is local small domain. Cheng: excellent suggestion, we'll follow up with you. Ron Bonica: what's the ultimate goal of this draft? are you building a network architecture so network operators could implement. or are you suggesting the development of some new routing mechanism. if the former, is RTGWG the right forum? maybe ops area. Cheng: this is architecture draft. We're looking for gaps, we need more inputs, and get new mechanism to address these issues. Ron: question to chair or AD, is it like OPS thing? Chris B: we use RTGWG as open discussion platform. It has a low threshold for presentations, but a significantly higher threshold for adopting particular draft. Ron: Fair enough. Chris: we're not really in the context of adopting it yet. Jeff: try to narrow down the scope and not boil the ocean. From Chat: Tom Hill Didn't flannel already implement this with VXLAN? :) Tom Hill 'quick connect' VPNs over the Internet, between clouds Sorry the slides moved on I'm dual-wielding two WGs Flannel is quite commonly used already today, AFAIK Jeff Tantsura flannel (or any other VXLAN overlay) just provides an overlay encap, nothing more Tom Hill Indeed, but do you need any more? Flannel went out of its way to make that work, without the IETF porting a protocol to 'General'/cross-Internet usage. Fan Yang @Tom will look into flannel later. But flannel can only work for VXLAN, there are other more IP protocols, ACH can be used for any protocols on IP and native IP itself. Tom Hill I don't see the same effort to go further than the basic VXLAN featureset. Jeff Tantsura @tom VXLAN is a L2oL3 encap and perhaps the worse choice of all the encaps (generic ones) Jeffrey Haas RFC 2549 encapsulation is perhaps worse Cheng Li Hi @Tom，many thanks for your input. Do you have any link of Flannel? Interested in it :) Flannel is a simple and easy way to configure a layer 3 network fabric designed for Kubernetes. https://machinezone.github.io/resea…etworking-solutions-for-kubernetes/ get some info from google, really helpful, will dive into it later Tom Hill No problem It may not be perfect, but it is definitely in use :) Cheng Li https://msazure.club/flannel-networking-demystify/ 6 18:15 10m SRv6 Midpoint Protection https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/ Xuesong Geng Bruno: Speaking as spring WG chair. The scope and goal is very spring specific and the mechanism is a bit heavy on SRv6. In spring, we have a document with the same scope for SR MPLS, so I think this draft is better to be in SPRING. I didn't see any email in the mailing list at spring. Xuesong: we're confused where to put this draft. It's been presented several times, to this stage we prefer to stay in RTGWG, but we're willing to present in SPRING if necessary. Considering TI-LFA is here, this document is informational about the forwarding behavior. we'd like to hear chair's opinion. Jeff T: we had intentions to meet and discuss about six or seven different about protections discussed between SPRING and RTGWG. Let's postpone your question till we reach some agreements. Chris B: Your work so far is still useful since most people attending this meeting attending SPRING as well. It's positive to have SPRING chair say that he thinks it should be over in spring because at least he thinks it's important work. So I wouldn't be discouraged. Xuesong: Happy to know that. From Chat: Bruno Decraene https://tools.ietf.org/html/draft-i…g-segment-protection-sr-te-paths-00 Seem to have the same scope with the SR-MPLS data plane.