IETF 110 LSR Meeting Minutes Chairs: Acee Lindem Chris Hopps Secretary: Yingzhen Qu Date: Monday, 8th March 2020 Time: 17:00 – 19:00 UTC+1 0 17:00 15m WG update Acee/Chris Xuesong: For "authors believe it's ready for WG LC", does it mean there is no WG consensus yet? Acee: The consensus will be determined during WG LC. Chris H: The authors believe a draft is ready, if someone doesn't think so, they can comment. Tony Li: draft-ietf-lsr-dynamic-flooding implemented, but there is no interoperability yet. Chris B: Dynamic flooding on Dense topo, is it Alvaro's comments on adding OSPF? Acee: No, it's SRv6 extension. Chris: For flooding parameters, Bruno has asked WG adoption, but there are two drafts and there are still tests going on. The work is progressing. There is no rush on adoption. Speaking as WG member, we may need to think out of the box. Xuesong: I have seen OSPF/ISIS SRv6 YANG adoption call in the queue for long time, just wondering when it will happen? Acee: There is nothing controversial about these two drafts, should happen soon. Alvaro: Welcome John Scudder as new LSR AD. He's taking over LSR from me. Thank you for the WG, after merging OSPF and ISIS, it's been working great. All the things done in last 3-4 years, it's lot of work. It's great to see the two protocols progress together. Chris H: Thank you for all your hard work Alvaro. 1 17:15 10m OSPF Transport Instance https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/ Yingzhen Qu Linda What's the application ID here? It it a network application or Dunbar: end-user application? Yingzhen: It can be any application that wants to use OSPF transport instance to disseminate application-specific information. Linda: If I'm an application attached to a router, can I create my own sub-tlv to be attached? Yingzhen: Yes. Linda: How do I tell router I need this information? Yingzhen: That's out of scope for this document. Acee: It's meant for non-routing information. So I guess you don't mean a prefix, you mean an end-point for an application. Uma The MEC computing use case in the draft is not correct, Chunduri: There is no way for a UE to communicate with the network directly. Yingzhen: OSPF transport instance can only disseminate non-routing information inside ospf network, how UPF communicate with ospf network is out of scope of this draft. UPF can run an OSPF transport instance, or use other ways to communicate. Chris H: Worst case just pull the use case out of the draft. Tony Li: "Routing protocols are not dump trucks", this will impede the operation of the protocol. Yingzhen: That's why we're using a transport instance. It's for non-routing information, not route calculation. Tony Li: We should design a different protocol for doing this. Chris: Did you not like genapp for ISIS either? Tony Li: Yes, it's not OSPF specific. Acee: Let's move this to the list. Aijun Wang: What's sparse topology? Yingzhen: An OSPF transport instance can run on a different topology from the routing instance. Let's discuss more on the list. 2 17:25 10m IGP Flex Algorithm https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/ Peter Psenak Alvaro: I'm glad you guys caught that as this was next in my queue. Since we're going to go for another last call, and this seems to be significant change, I'm going to bump the document back to the WG. Please put it on John's queue. 3 17:35 15m Flexible Algorithms Bandwidth Constraints https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/ William Britto Acee: Speaking as WG member. This is a good example how flex-algo can be used. Whatever we talk about the measurement of the delay, jitter, etc, there are questions as to how it is done. I know it's out of scope, but it will be helpful to provide guidance on frequency of updating such info. William: Thanks. Gyan Misha: Just wondering, how to avoid instability? William: We expect operators use with caution. If you want to bring down a link, you have to define the threshold and make sure it's safe. For dynamic bandwidth, it only changes when members change. Uma: Useful draft. I'd like to see the impacts to packet reordering. Jie: The bandwidth metric, is it tightly coupled with flex-algo? William: It's generic, can be used in any application. Jie: please clarify it. In this draft, latency is on a particular link instead of end-to-end, what's the use case? William: You may want to exclude a particular link. Shraddha: Just clarifications. it's basically to dynamically exclude some links when the bandwidth or latency change. The measurement and how often to update the parameters is out of scope. We will add text about area partitions. 4 17:50 10m Using Flex-Algo for Segment Routing based VTN https://datatracker.ietf.org/doc/draft-zhu-lsr-isis-sr-vtn-flexalgo/ Yongqing Zhu/ Jie Dong Tarek Saad: Flex-algo has overhead of advertising the definition, nodes consuming it, and doing SPF with the respective algorithm. You'll soon realize you can't do as many flex-algos as you'd want. Any consideration for this limitation? Jie: Regarding scalability, we do have a section on scalability in the draft. We also have other drafts that support multiple VTNs sharing the same topology, it requires more extensions to the control-plane though. Tarek: Why would we standardize something we know is unscalable? Jie: we have another draft in TEAS. Each mechanism has different pros and cons, scalability is one aspect. Chris: We should discuss this on the list before we get into an adoption discussion. Peter What you're trying to do here is advertise VTN specific info Psenak: about the link. The way you're trying to do this is by hijacking the bundle advertisement, pretending it's specific to the VTN. I'm not sure that's the right approach. There's no direct info about the VTN for which you advertise the information, too error-prone. If you want to advertise VTN-specific stuff, define your own VTN-specific information, don't use hijacking and mapping. Chris H: As a WG member, when I saw admin color, I was hoping this would just be an informational draft. Jie: to Peter's comment, we reused admin group to correlate with flex-algo ID, is based on existing flex-algo idioms. Introducing a dedicated identifier would be a different approach that would require more extensions. Chris H: Again, this is good for discussion on the list. 5 18:00 8m IGP Flexible Algorithm with L2bundles https://tools.ietf.org/html/draft-peng-lsr-flex-algo-l2bundles-05 Ran Chen Peter P: As a flex-algo co-author, we never intended to use L2 links in the flex-algo calculations. Do we want to do this? Seems like the right solution is SR-TE. It's *possible* to do it inside flex-algo, but I'd prefer to keep it L3 specific. Ran: Thanks, we've discussed your mails, but we think the problem needs to be solved. See section 5. Chris: Would be helpful if more people would engage on the list. 6 18:08 8m Algorithm Related IGP-Adjacency SID Advertisement https://tools.ietf.org/html/draft-peng-lsr-algorithm-related-adjacency-sid-02 Ran Chen Tony Li: We already have ample mechanisms within flex-algo for doing this kind of thing, for example coloring. Why do we need this? Ran: that was in my motivation slide. Tony Li: I'm not following you but OK. Acee: Please post the question on the list so it can be discussed more. 7 18:16 10m IGP Extensions for SR Slice Aggregate SIDs https://tools.ietf.org/html/draft-bestbar-lsr-spring-sa-00 Tarek Saad Acee: As chair, I think the whole slice TE concept would needs to be adopted in TEAS first, and whether or not the concept of slice-aggregate is the right one, before we jump to encodings. Tarek: Sure. We are working on that in TEAS. Peter P: How many of these aggregates are we talking about. You just mentioned flex-algo doesn't scale to hundreds, and I agree. Tarek: Good question, I don't claim to have the final answer. We need to be realistic, shooting for the order of hundreds to a thousand. The point of our proposal is that we want to decouple topology and IGP path computation (primary and backup) from the number of forwarding treatments. Peter P: Hundreds or thousands of these? Could be a scalability issue. Tarek: Hundreds of SAIDs. Tarek: Our proposal in SPRING has two options. One is purely data-plane, but that has implications for hardware, so we also have this option. Jie: The drafts you mentioned in TEAS and SPRING have overlap/ conflict with (for example) enhanced VPNs. We need to resolve those first. Tarek: We're presenting at the TEAS meeting and we're open to discussion. Jie: For scalability, we also have a draft in TEAS. Let's also discuss that. Uma: For hundreds to thousands slice aggregates, why do you present SAID with 32 bits? Tarek: we'll think about it. we're open to reducing the field size if required. Acee: If field size is the only problem, there's no barrier! 8 18:26 10m OSPF Extension for 5G Edge Computing Service https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/ Linda Dunbar Chris H: As WG member, I don't have time for the philosophizing, but you're trying to push application load-balancing into routing and ask routing to do that. That is a big ask, a big change. You have to add the info because anycast solves the simple problem, very well. But not for you because you're trying to do more. You will get pushback on the whole idea from people who don't want routing to do this. You can do this in other ways. Linda: In 3gpp there's project called Edge Computing, and anycast is proposed as a way to do load-balanceing. We're not trying to replace application load-balancers. Chris: I get it, but you are not actually using anycast, you're expanding it. I'm not saying its good or bad I'm just saying it's a big ask. Acee: I'll take it to the list, but I'm happy you fixed the encodings. From the chat: Joel Halpern: This seems to be the same confusion of stuffing things into the routing system that parts of the dyncast documents have. Don't solve this problem in routing. Jeff Tantsura: +1 Tony Li: +1 Randy Bush: Where to solve it if not in routing? App layer? Tony Li: In the load balancer? Randy: L4 or L7? Jeff T: DNS + anycast works pretty well Gyan: +1 Joel: One approach I have discussed is a mapping system (LISP, ALTO, ...) Even better from my perspective is to teach the end-systems to ask an appropriate control component (not the routing) for the information it needs. DNS still claims not to give context-sensitive answers. If we ignore that, sure, DNS works. Randy: I assure you that there are context sensitive DNS deployments. Jeff T: IGP should be the last place where this kind of stuff is pushed to. Joel: @Randy - I hope I was careful on the phrasing. I am sure there are as many abuses of DNS as there are of the IGPs. Using DNS for the query protocol doesn't bother me. 9 18:36 10m Updates of PUA mechanism https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ Gyan Mishra(Verizon) Aijun Wang(China Telecom) Acee: As a WG member, two comments (made them last time but they were not taken). First, how do you know which holes you're protecting? Are they configured on the ABRs? How do you know a priori what the ABR is missing if it's not configured? Gyan: I don't know if I'm completely understand your question, but I would say if the prefix is missing within the range that notification happens from the... Acee: You're assuming you know about the prefix, and then it goes away. You won't protect anything you don't know about when you come up, because it's stateful. Gyan: Yes, anything that you know about. Acee: It's somewhat timing-based. It's kind of broken in that way. The other problem is the way you're doing it, if not everyone in the domain supports it, you'll attract traffic toward the black hole - the prefix originator T:V is the wrong method for this. Gyan: thanks for the comments, we'll take it to the list for more discussions. 10 18:46 10m IS-IS Multi-Flooding Instances https://datatracker.ietf.org/doc/draft-wang-lsr-isis-mfi/ Yali Wang Acee: As a WG member, you say it's easier to implement. Have you implemented it? Yali: this is the result of our analysis. Not from implementation results. Acee: I would disagree that it'll be easier to implement. We can discuss on the list.