## IETF 115 LSR Minutes {#ietf-115-lsr-minutes} Chairs: Acee Lindem (acee@cisco.com) Chris Hopps (chopps@chopps.org) Secretary: Yingzhen Qu (yingzhen.ietf@gmail.com) WG Page: http://tools.ietf.org/wg/lsr/ Materials: https://datatracker.ietf.org/meeting/115/session/lsr ## 1. 9:30 Meeting Administrivia and WG Update {#1--930-meeting-administrivia-and-wg-update} Chairs (10 mins) \*\*Comments from Tony Li in chat: Tony Li 00:09:59 Extended hierarchy should just die. Area Proxy should move to experimental and do WG last call. ## 2. 9:40 LSR YANG Update {#2--940-lsr-yang-update} Yingzhen Qu (10 mins) * Chirs Hopps: It took us three years to publish those models, do you think it was our fault? * Yingzhen: Both OSPF and ISIS models have a dependency on the BFD YANG module. After the BFD module was published, we found some issues, so it had to do a BIS version. Three years later, we're here. * Acee: There is an guy doing an open source implementation of the OSPF model, and he sent us a lot of comments late. When he's done, we'll invite him to give us a presentation. * Jeff Hass: Yes, we found a bug, and it took us 8 months to fix that, but you also have lots of fixes after the LC. We need to figure out a way to work faster. * Acee: These SR two models are the last WG documents before we merged the OSPF and ISIS WGs. After these two, you will be able to search "-lsr-" to find all the WG docs and drafts. * Chirs Hopps: I'm a big fan of this model (admin-tags: protocol extension and YANG module together), but I couldn't get everyone to sign up for it. If we have dual documents, no one will pay attention to the YANG doc. * Acee: OSPF and ISIS YANG models are both bulk, after we have this, it will be easier for people to know how to do YANG, xpath, etc. * Yingzhen: If you want to add YANG module into your draft and you need help, please let us know and we'd be happy to help. * Chris Hopps: Does the extension cover all the published RFCs? * Yingzhen: We went over the RFCs published but not included in the base module, we did skip a few unpopular ones though. * Acee: We need to check the protocol extension modules, such as BIER, they have their standalone model * Yingzhen: I'll check. * Chris Hopps: Now the base models are published, it will be better if we have YANG in the protocol extension drafts. * Yingzhen: In v1 of the IGP augmentations, most of these RFCs were published before YANG started. * Acee: We also skipped experimental RFCs, such as OSPF TTZ. ## 3. 9:50 OSPF-GT (Generalized Transport) {#3--950-ospf-gt-generalized-transport} Acee Lindem (10 mins) https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/ * Aijun: For non-routing information, we don't need flooding, only the reliable mechanism. There are many reliable protocols, by using OSPF you put the complexity to the operators if you consider the interactions between the two instances. There is no deployment of gen-app IS-IS. * Acee: The draft will have management considerations added, it definitely has more configuration than you just put all information into the base OSPF instance. * Aijun: One of your use cases is the MEC, and we expect to combine the network info and the server info for routing. * Acee: I have to look at the application. if it's impacting routing, it should be in the base OSPF. ## 4. 10:00 IGP Unreachable Prefix Announcement {#4--1000-igp-unreachable-prefix-announcement} Peter Psenak (10 mins) https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-ureach-prefix-announce/ * Chris: Are the implementations from the same vendor? * Peter: Single one for now, and there is one coming from a different vendor. * Aijun: Firstly, from the definition of related RFC, LSInfinity just indicated that the LSA that associated with LSInfinity shouldn't be included in the SPF algorithm. That is to say, there will be no specified Prefixes in the FIB, but that does not mean this prefix is not reachable, because there may be other summary address covering it that exists. Secondly, there are already several usages of LSInifinity, we should not complicate the situation again. Thirdly, for OSPFv3, it is not appropriate to use the LSInifinity value, or the metric of Summary LSA can easily exceed the value of LSInifity, but the prefixes associated with the Summary LSA are definetly reachable. Then depending solely on the LSInifity will limit the operator for the setting of prefixes metric value. We should take the explicit notification approach, as that defined in PUA draft. * Peter: It's inifinity, and it means unreachable. In terms of using it for other purposes you're probably referring to flex-algo, and we have explicitly defined that these metrics are infinity metrics. I don't see complexity, and we can argue forever. Please let other people speak up. * Chris Hopps: We should get other people's opinions and we should make a call. * Acee: Speaking as wg member, it needs to be standard track because the ABRs need to have different behavior. This is the best from backward compatible POV. The notification is ephemeral. Also from deployment point, you only need to upgrade the router that needs to act upon it. * John Scudder: Speaking as a contributor, isn't this a potential application of OSPF-GT? * Peter: This is directly related to routing. You're right, not every router needs it, the processing is up to the receiver. * Qiangzhou: There might be old devices in the network which don't know what to do with LSinfinity. * Peter: You can only use it for unreachable, you can't use it for anything else. * Qiangzhou: Huawei and Cisco devices have max-metric. * Peter: max-metric has different value. They basically do the same thing. There is no conflict, but we can talk about it. * Ketan: LSinfinity has been in the protocol for decades, nothing changes. What is added is the processing at the receiver to treat it as an indication. * Huaimo: This is a hot topic. This is also used for aging out LSAs. * Peter: Aging out LSAs is done differently. * Huaimo: For metric close to infinity, is it reachable? * Peter: RFC says you can use LSinfinity or max-metric as max-age, but the LSA itself is not max-aged. Any metric is valid and LSinfinity has special meaning. * Tony Przygienda: we're solving the problem in the wrong protocol. For all the solutions for this problem, this is the best. I will keep this Informational, fundamental is that it doesn't scale. If we push Standards Track, we may have to implement it and we need operation considerations. * Peter: Agree with what you said. In terms of Standards Track, there is some normative language. I hope we can keep it Informational. * Tony P: We're not changing the ABR behavior. The only thing we mandate is the behavior of nodes on the wire. The idea of interoperability means we define the observable behavior on the wire as long as you comply with the specifications. * Peter: I'd like to make it informational if possible. I will let the WG decide. * Acee: As chair, we can also do experimental. * Aijun: If the ABR wants to withdraw the specified prefix, but keep the summary address that covers the specified prefix, it will send the LSA with the metric of the specified prefix set to LSInifinity. In such situation, the specified prefix is still reachable via the summary address, then it can't trigger the switchover of BGP, or some tunnel services. * Peter: Please describe the scenario. * Shraddha: When we summarize, we lose some information, like reachability and metric. One common technique is to set the node overload, and then advertise high metric so the PE can switch, however this is lost when we summarize. We should look at these in general instead of one by one. * Peter: Fair comment. Do you see the mechanism can be used? * Shraddha: Planned maintenance is different from unreachable. * Peter: If you have an idea, please propose. * David Lamparter: The behavior for very high metrics is not the same for OSPF and IS-IS. The draft is accidently changing the behavior for IS-IS with this high metric. * Peter: No, there is a section in the draft about this. The link metrics are different, but this is prefix metric. * Dan Voyer: My comment, for the queue, as an operator or someone that would use UPA, I prefer to be either "informational" (preference) or track-ID (lease preferred) but definitely not "experimental" ## 5. 10:10 IGP Flexible Algorithms Reverse Affinity Constraint {#5--1010-igp-flexible-algorithms-reverse-affinity-constraint} Peter Psenak (5 mins) https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-flex-algo-reverse-affinity/ No questions asked. ## 6. 10:15 Loop detection for imported routes {#6--1015-loop-detection-for-imported-routes} Zhuo Yue (10 mins) https://datatracker.ietf.org/doc/draft-yue-lsr-loop-detection-for-imported-routes/ * Tony P: We should definitely not do it. * Chris: Les made the same comment. * Tony P: This is bad network design. You should do hierarchical IGP, when you run out of hierarchy, you run BGP in 0.01% case. Well, otherwise you start to build a distance vector protocol on top of this whole thing. * Chris: In 0.01% case, you also have to config router wrong. This is protecting misconfiguration. * Tony P: We're adding complexity to cover misconfiguration, and the solution is not backward compatible. * Acee: Agreed with Tony. Routers don't work that way. You can use tags for mutual redistribution. Tt works between different protocols or same protocols. Don't waste time on OSPF extensions similar to IS-IS ones. * Zhuo Yue: What we're trying to do is when routing loops happen, we can use this to solve it. * Peter: Redistribution happens. The problem is valid, but not the solution. We have existing mechanisms, and I don't think we need this draft. ## 7. 10:25 Advertising Unreachable Links in OSPF {#7--1025-advertising-unreachable-links-in-ospf} Liyang Gong (10 mins) https://datatracker.ietf.org/doc/draft-gong-lsr-ospf-unreachable-link/ * Acee: Speaking as working group member, I thought about this and I guess either solution would work as long as we have the capability. If you didn't have the capability, you can't just start using it because many implementations use the reference bandwidth to compute the interface cost so if there's an outlier link that's very slow, it's going to have max-metric and all of a sudden these links would be unreachable. Actually that's a reason not to use it even if the capability is supported, because these links are going to be auto-configured to max-metric. I think if we were to use max-metric, we need to put a note in there that you should not ever use max-metric when using reference bandwidth. I'll send my comments to the list. * John Scudder: Solution #2 seems less a pain. * Ketan: I'd suggest authors to look at RFC 8770. The draft needs some work in that direction. * Shraddha: I think this should be something done locally. If you don't want to use a link in the default topo you advertise max-metric for it, so alternate paths will be used. I don't understand why you didn't think that is a solution. * Liyang: From our scenario, the link is newly added, if the cost is smaller than other paths, it will draw traffic which is not what we want. * Shraddha: I get your case. You should keep IGP metric high. To use this, you will have to upgrade all routers. It's much easier just use a different metric type. ## 8. 10:35 OSPF and IS-IS Extensions for Flow Specification {#8--1035-ospf-and-is-is-extensions-for-flow-specification} Qiangzhou Gao (10 mins) https://datatracker.ietf.org/doc/draft-liang-lsr-ospf-flowspec-extensions/ https://datatracker.ietf.org/doc/draft-liang-lsr-isis-flowspec-extensions/ * Chris: You're configuring FW using IGPs. I understand BGP is a dump truck, there might be case you need the info to be sent to a different domain, it's not the case here. The CE1 to CE2 case is crazy, you don't have Microsoft to config Google routers. * Les: I agree with Chris, it doesn't belong in the IGP. If you're going to put this into IGP at all, OSPF-GT or ISIS gen-app is the way to do it. * Jeff Haas: Agree with that this should be in OSPF-GT. I looked at the encoding, it's clean. Are you comfortable with very large LSAs going into IGP? BGP can have 4k in one PDU, I've seen the size of 2-3K flow spec filters. My impression is you don't want to put 2-3K into an LSA. * Acee: If we were to do this in OSPF-GT, could we get away to not redefine the flow-spec encoding and just use BGP encoding? If you cannot, it's ok. * Jeff Hass: PCEP uses very similar to flowspec rules to carry it in PCEP. There are bugs in the existing RFC. Please pay attention to flowspec v2. * John Scudder: Thank you Jeff for mentioning PCEP option. We don't want to put this into IGP. ## 9. Closing Comments {#9--closing-comments} * Chris Hopps: We'll do an interim on multi-TLVs. I hope the vendors who implemented it could speak up. ============================================================= ## Chat History {#chat-history} Tony Li 00:09:59 Extended hierarchy should just die. Area Proxy should move to experimental and do WG last call. John Scudder 00:49:25 I put myself back in the queue as a proxy for Tony P. Ketan Talaulikar 00:52:27 LSInfinity is not for aging out. Please recheck RFC2328 Ketan Talaulikar 00:52:55 It is just taking the prefix out of consideration. The LSA needs to remain. Ketan Talaulikar 00:53:28 Also, I see MAX METRIC for a link (0xFFFF) is being confused by LSInfinity for a prefix? Bruno Decraene 01:01:37 "out of consideration" and "unreachable" seems two different semantics to me. IOW "out of consideration" does not seem to imply "unreachable" Les Ginsberg 01:03:17 @Ketan +1 in regards to link metric vs prefix metric Dan Voyer 01:03:51 my comment, for the queue, as an operator or someone that would use UPA, I prefer to be either "informational" (preference) or track-ID (lease preferred) but deffinitly not "experimental" Christian Hopps 01:09:55 Thanks Dan, let's make sure that comment gets into the minutes Tony Przygienda 01:15:26 yeah, one tag is a cheap hack for one hop Tony Przygienda 01:15:40 if you have 2 hops you *really* have a problem because your chain is looped Louis Chan 01:17:04 If metric is advertised correctly across instances, metric value will be high enough to avoid real looping. Tony Przygienda 01:19:22 +1 Bruno: yes, the draft is swaying the meaning of "unreachable" from "not advertised" to "advertised with infinite metric". Based on protocol spec this is a distinction without behavior difference and this fact is played cleverly Martin Horneffer 01:19:25 BTW, I agree 100% to Peter. And I’m one of those who use tags and route policies for this purpose. Tony Przygienda 01:20:37 so kuddos to the sophists who found and use it ;-) The only problem is really scalability AFAIS (I skip the double-clever flex-algo stuff doing it as well and then using the "context", i.e. semiotics to actually differentiate). If your head didn't explod yet I recommend some de Saussure ;-) Dan Voyer 01:22:50 @Martin H., yes, same here - we use tags and route-policies for this as well Tony Przygienda 01:25:08 @Louis: and your protocol preferences are hacked correctly and, and, and. There is tons of broken glass you have to carefully step around when you're doing this kind of stuff and 99.9% of customers are better served by either hiearchical IGP or BGP'ing the whole thing. Julien Meuric 01:43:52 PCE chair hat on: nicely put, @Jeffrey Haas Jeffrey Haas 01:44:43 @Julien Meuric I'm still not sure the use case presented in LSR is a good fit for pcep, but it's a good example of flowspec being used for encoding support of the use cases.