# IETF 116 LSR Minutes {#ietf-116-lsr-minutes} Chairs: Acee Lindem (acee.ietf@gmail.com) Chris Hopps (chopps@chopps.org) Secretary: Yingzhen Qu (yingzhen.ietf@gmail.com) WG Page: https://datatracker.ietf.org/group/lsr/about/ Materials: https://datatracker.ietf.org/meeting/116/session/lsr ### 1. Meeting Administrivia and WG Update {#1--meeting-administrivia-and-wg-update} Chairs (10 mins) ### 2. IS-IS Fast Flooding {#2--is-is-fast-flooding} https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/ Bruno Decraene (5 mins) * Chris H: Any objection? No objection seen in the room. * Acee: I’d encourage people to read the draft. There has been significant updates, please review before WGLC. ### 3. 9:45-9:55 IGP extensions for Advertising Offset for Flex-Algorithm {#3--945-955-igp-extensions-for-advertising-offset-for-flex-algorithm} https://datatracker.ietf.org/doc/draft-chan-lsr-igp-adv-offset/ Louis Chan (10 mins) * Weiqiang Cheng: We had a similar draft in SRv6. It's necessary to reduce the advertisement load to use flex-algo a in large network, so I support this proposal. Do you have running code for it? * Louis: Not yet, but it's not complicated. * Acee: I read the draft and I didn't know what virtual flex-algo is. It was not explained in the draft. I think you got the term wrong, it's another level of hierarchy, not flex-algo. It's all implementation on the node. * Louis: It's not really vlan. Looking forward to a new name. * Chris: The VLAN example helped me understand what "Virtual Flex-Algo" meant at least. * Peter Psenak: I'm not sure how real the problem is unless you have lots of flex-algos. Flex-algo is not a VPN technology, and the number of flex-algos is expected to be a single digit. I don't think it's needed, using two methods to advertise the same info. Also agree with Acee, please change the name. * Louis: If there are 240 ports on a box, with vlans, it's a lot. We do have customers fanning out at the aggregation layer, that would be a lot. * Peter: But you don't run out of LSP space because of this. What's the problem you're referring to? Running out of LSP space? * Louis: It's about scaling. Let's discuss offline. * Peter: Typically we don't have two ways to do the same thing unless it's a real problem. * Fang Gao: Question about load-balance between multiple algos and protection is only for one algo. Can I use virtual flex-algo for that? * Louis: Your question is about load-balancing, and this draft doesn't solve that problem. The reason is like VLAN, it's not about load-balancing. This draft is about QoS in one flex-algo. * Jie Dong: I'm trying to understand the problem. You want to have more flex-algos or more links in one flex-algo? * Louis: Traditionally you advertise a label once per link, now once for all links. The 2nd purpose is to have a single flex-algo but subdivde it, just like a VLAN. * Jie Dong: This is different from flex-algo. We have a proposal for scalability to use a shared topology. I will share the link. * Les Ginsberg: This draft skipped a few steps. It looks good from an academic view, but it's not practical from an OPS POV. The virtual flex-algo needs more discussions, which you introduced in a couple sentences. That's my concern. * Louis: It's not a big trouble if you do careful planning. ### 4. IS-IS Traffic Engineering (TE) Metric LAN Extensions {#4--is-is-traffic-engineering-te-metric-lan-extensions} https://datatracker.ietf.org/doc/draft-li-lsr-isis-te-metric-lan-extensions/ Chenxi Li (10 mins) * Acee: How are you going to do bandwidth in a shared LAN? Why not use a P2MP topology in IS-IS? * Chris: I have the same question. The routers are already treating the interface as P2P, why not just use IGP P2P interfaces and you don't need this extension? * Acee: If you do TE on a LAN, how to do bandwidth management? * Chenxi: Later we may extend BGP-LS to report this info to NCE. * Chris: Yes, but a BGP-LS extension draft and an IGP extension draft can't justify each other's existence. BGP-LS and IGP both work by simply modeling the network as P2P links, so we don't need this extension. Let's take it to the list. ### 5. 10:24 IGP Unreachable Prefix Announcement {#5--1024-igp-unreachable-prefix-announcement} https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce Peter Psenak (10 mins) * Aijung Wang: Now Peter switched to explicit notification. in last IETF, we have pointed out implicit is not sufficient, better use explicit. We talked about merging, but we had different opinions about which draft to be the base one. You acknowledge we found the problem first, so we'd like to invite Peter to join our draft. * Chris: With chair hat on. Once it's a WG doc, it belongs to the WG. We'd take the closest to the solution we want, not hang up on which draft as the base. In the end we can have a single editor, not like we're going to do that, just keep in mind it's not owned by a person after it becomes adopted. * Peter: There are technical differences between the drafts. I fully agreed it should be based on the solution, not who wrote it or who started it. * Acee: As a chair, agreed with Chris. As a participant, consider OSPFv3, using no unicast bit like flex-algo, then you'd have complete backward compatibility and incremental deployment. * Peter: We can use existing mechanisms to make sure that nobody interprets it as a reachable prefix, and we can use a new bit. * Acee: For the two proposals, that would give this one a clear advantage. * Les: Between the planned and unplanned event, it's not clear to me what the use case for this. If you have a planned event, you should move all your traffic away from the destination before you take the node out. Could you clarify what the use case for distinguishing these two types of events? * Peter: This was proposed by Shraddha, maybe she can answer it. * Shraddha: If it's a single domain, planned or unplanned events. For planned, we can use overload, so traffic can move away. Similar use case in multi-domain where summarization is in place, so traffic can't be moved away based on metric. The new bit is to indicate it's a planned event. * Bruno: Thank you for adding the flags to signal explicitly, however the flags are informative. I think we need 3 scenarios: 1. explicit prefix advertisement. 2. No reachability, or 3. Prefix with 1 metric. So far, you signal with max-metric, which is the same as no advertisement. I think we have an issue with backward compatibility because we have the same signal for two states. * Peter: I don't understand. We're not introducing new treatment. We're adding a reason when sending max-metric. The draft says the prefix can't be used for routing. I don't see backward compatibility issue. * Bruno: Today I can advertise a prefix with max-metric, that doesn't mean unreachable. * Peter: The draft clearly says if you advertise that specific metric, then the prefix can't be used for routing. If you're advertising for some other reason, my question would be if I have two implementations sending max-metric for private reasons, how would they interoperate? they wouldn't. * Chris: You're highlighting only one use case of "max metric". The non-routing case for max-metric was not specified (on-purpose) there may be other uses, right? * Peter: We're the first one. * Chris: Should we leave room for a type to allow other uses of max metric? * Chris: Bruno, your question would be this might be still reachable? * Bruno: The way I read it, it will have reachability for the less-specific prefix advertised. if I have reachability with /24, and advertise unreachable for /32, I still have reachability for the /32. * Chris: Some hardware doesn't support blackhole routes. This would be so that BGP looks at it and picks a new next-hop. It's not really in the forwarding plane. It's not intended to be. * Peter: Agree. It is not in the forwarding plane. * ### 6. 10:45 Prefix Unreachable Announcement {#6--1045-prefix-unreachable-announcement} https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ Aijun Wang (10 mins) * Chris: We should continue with a merged solution. * Acee: We should move on. The first proposal doesn't need all routers to support it, the second does. You guys should talk and merge the drafts. * Aijun: In PUA, we need capability negotiation, while UPA not. * ### 7. 11:05 OSPF Adjacency Suppression {#7--1105-ospf-adjacency-suppression} 7\.1 https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency-suppress/ Liyan Gong / Weiqiang Cheng (10 mins) 7\.2 11:10 Alternative solution Acee Lindem (5 mins) * Liyan: I'm glad you agreed that it's a problem in OSPF. Two questions about your proposal. First it's not only router-lsa, but other types as well. Your solution doesn't work with other types of LSAs. * Acee: yes, it does. Because you have the bidirectional link between the routers, so you really only need to do router LSAs. Let's take this to the list. ### 9. 11:14 IGP Extensions for Link MTU {#9--1114-igp-extensions-for-link-mtu} https://datatracker.ietf.org/doc/draft-hu-lsr-igp-link-mtu/ Zhibo Hu (5 mins) * Tony P: It's a self-inflicted problem, but I think the solution is reasonable. * Louis Chan: How to guarantee the TI-LFA path also works? MTU may change in this case. The second is that you need to signal the client to lower the MTU before this one. * Zhibo: When calculating the TI-LFA path, the MTU is also considered. * Louis: It's the transit, not the headend node, so you don't know. * Chris: Let's discuss more on the list. ### 10. 11:20 IS-IS Extension for Big TLV {#10-1120-is-is-extension-for-big-tlv} https://datatracker.ietf.org/doc/draft-chen-lsr-isis-big-tlv/ Huaimo Chen (5 minutes) * Tony P: If we had green field protocol, this is possible solution. However we have lots of stuff deployed in the wild. There is a multi-TLV proposal, and we already have implementations. Also you can't break in the middle of traffic engineering TLVs. If you have an old router, the length field will be off. * Huaimo: For the length field, we'll need to adjust it. Regarding implementation, we may have multiple solutions. * Chris: I think your solution would have made sense if it was green field development, but probably doesn't work now. Let's take it to the list. ### 11. 11:25 Advertising Service Functions Using IS-IS and OSPF {#11-1125-advertising-service-functions-using-is-is-and-ospf} https://datatracker.ietf.org/doc/draft-xu-lsr-isis-service-function-adv/ https://datatracker.ietf.org/doc/draft-xu-lsr-ospf-service-function-adv/ Hongyi Huang (5 mins) * Fang Gao: Do you need an ID for normal SF or SR policy, or is it identified by the SID? * Hongyi: What you said is feasible. * Andrew: Why not we look at some shim to transport IGP data directly there? * Ketan: It's already in BGP-LS. * Chris: That's a big topic. * * * * Acee: we may consider an interim. * Chris: yes, we'll consider an interim. #### The following presentations didn't happen. {#the-following-presentations-didnt-happen} 1. Route Redistribution Credibility ID for Avoiding Routing Loop https://datatracker.ietf.org/doc/draft-wang-lsr-redistribution-credibility-id/ Qiang Wang (5 mins) ================================================ ### If time permitting ================================================ 1. Stub Link Attributes https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/ Aijun Wang (10 mins) Total: 120 mins ## Chat History {#chat-history} * Ketan Talaulikar 00:39:39 There is a WG draft for per-algo adj-sid : https://datatracker.ietf.org/doc/draft-ietf-lsr-algorithm-related-adjacency-sid/ If we have large number of links, we are advertising many other attributes per link - so I am also missing the point of "compressing" only the adj-sid advertisement. * Weiqiang Cheng 00:41:58 The similar solution for SRv6 is on the link: https://datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/ * Jie Dong 00:49:16 The draft I mentioned which provide better scalability for this use case is: https://datatracker.ietf.org/doc/html/draft-dong-lsr-sr-enhanced-vpn-08 * John Scudder 00:51:24 Why even have a DIS, in other words, right? * Jeff Tantsura 00:52:03 +1 * Tony Li 00:52:05 The only case would be a true L2 switch. * Tony Li 00:52:25 And you can have a switch with dissimilar port bandwidths. * Les Ginsberg 01:11:52 @Shraddha. Sorry - I do not understand your point. If I am an ABR in another domain, when I receive the UPA - why would I treat it differently if it was planned vs unplanned. Can you clarify the practical use case? * Ketan Talaulikar 01:12:34 @Shraddha Hegde For multi-domain scenario, I would expect that for BGP services on top, the operator would switch to the redundant peer using BGP attributes for planned events? So is there really the need for an indication between planned/unplanned within the IGP? * Ketan Talaulikar 01:14:17 s/indication/ indication between planned/unplanned * Les Ginsberg 01:14:45 @Ketan. Yes - this is exactly my point. * Jeffrey Haas 01:15:58 BGP largely just wants to know "is this nexthop reachable". * Ketan Talaulikar 01:21:18 @Jeffrey Haas , correct. So if I am doing maintenance on a router, I would do like to indicate this to other BGP speakers using some BGP attribute (e.g. local pref). Similar to OVL for ISIS. My point is that using this IGP spec for indication of planned events is does not seem like a good idea to me. * Shraddha Hegde 01:21:28 @Ketan In MPLS deployments people use underlying igp metric to shift the traffic away. With introduction of UP indication, the same mechanism can be used where summarization is in place. * Tony Li 01:24:39 TVR WG is going to be working on a way of distributing planned topology changes. It is my hope that we find a better mechanism than IGP flooding for this information. * Les Ginsberg 01:25:00 @Shraddha - I am not objecting to using the IGP for UPA - I am asking for clarification on the practical use case for differentiating between planned/unplanned on the remote ABR. Can you please provide a real deployment case? * Jeff Tantsura 01:26:59 @tony - we already have BGP for that :) * Ketan Talaulikar 01:27:18 @Shraddha Hegde , sure and I understand. However, I would recommend a more robust BGP based mechanism for indication of planned event for BGP services. Especially in this specific scenario. We should remember that given BGP scale, a BGP based mechanism done before the actual maintenance would be far better. Putting such things in this IGP spec might give a false/wrong (?) impression to some ... UPA is best used for failures (unplanned) and not for planned events. * Tony Li 01:27:36 @Jeff BGP is not a dump truck. * Jeffrey Haas 01:29:15 TVR is the new dump truck? * Tony Li 01:30:10 TVR will be using the new dump truck, I hope. * Shraddha Hegde 01:31:47 @Ketan Is there a existing BGP mechansim that you propose people to use? Can you specify the draft/RFC * Jeff Tantsura 01:31:50 @ketan - what if you need to drain a P/transport router? * Jeff Tantsura 01:32:28 @shrada GSHUT * Shraddha Hegde 01:32:40 @Les Are you asking how does the ABR differentiate whether it should generate U bit or UP bit? * Ketan Talaulikar 01:33:36 @Jeff Tantsura , the P/transport router is doing forwarding based on summary. So it does not need to perform any action on the UPA - at least not in the forwarding. * Aijun Wang 01:33:46 @peter, the final solution should depend on the LSInfinity. The usage of LSInifinity should be temporary. * Jeffrey Haas 01:34:16 Ketan Talaulikar said: Jeffrey Haas , correct. So if I am doing maintenance on a router, I would do like to indicate this to other BGP speakers using some BGP attribute (e.g. local pref). Similar to OVL for ISIS. My point is that using this IGP spec for indication of planned events is does not seem like a good idea to me. I've not been strongly following the UPA work so I don't have well considered opinions on it at this point. That said, methodologies to shift traffic from a nexthop in a network-wide graceful mechanism with a small number of events are appreciated. Doing similar via locally attached attributes in BGP ("drain procedures" or similar) is certainly current practice. However, so is dealing with potentially long convergence times when this is done. * Les Ginsberg 01:34:17 @Shraddha, No. I am asking what the ABR would do differently based on the state advertised. If it was a planned event and the ABR already knew about it from some other TBD means, it would not matter of the ABR reacted to the received UPA since it would have already moved traffic away from that host anyway. * Aijun Wang 01:35:52 @Acee, PUA soultion prefer to all routers to support such capabilities, but it can also be deployed incrementally, with the help of LSInfinity, or other mechanism. * Peter Psenak 01:37:57 you are contradicting yourself Aijun. You are saying you do not want to use unreachable metric, but then you use it to suppress the capability. * Ketan Talaulikar 01:38:20 @Jeffrey Haas , precisely due to the long convergence time, this should be done using BGP based indication well before the actual maintenance work is done. UPA is a trigger after failure. More specifically, my concern with the explicit indication of UPA for planned events is that it would seem to recommend this kind of usage while in fact BGP based mechanism is desirable. * Peter Psenak 01:38:27 we want backward compatible solution and that can only be done with unreachable metric * Peter Psenak 01:38:36 and we do not want capability at all * Peter Psenak 01:38:58 it's very simple if you thing about it * Shraddha Hegde 01:39:10 @Les Its the PE that would process the notification (U bit or UP bit)differently. The difference in processing is control plane vs data plane. * Les Ginsberg 01:40:41 @Shraddha I understand the intent of the signalling. What I am asking for is a practical use case. * Aijun Wang 01:40:57 @peter, The usage of LSInfinity should be removed from the network, not to enhance it. Relying on the capabilities negotiation, the operator can know the support status of routers within the area * Jeffrey Haas 01:41:45 * Ketan Talaulikar said: Jeffrey Haas , precisely due to the long convergence time, this should be done using BGP based indication well before the actual maintenance work is done. UPA is a trigger after failure. More specifically, my concern with the explicit indication of UPA for planned events is that it would seem to recommend this kind of usage while in fact BGP based mechanism is desirable. If the network is told "this bgp nexthop is unusable", routers across the network can converge more quickly because each router will locally find alternate paths, if available. If you source this solely at the point of "maintenance", you rely on full path hunting across the AS to finish. * Aijun Wang 01:42:29 Anyway, for the perfect effect of solution, all the routers within the area should support such capabilities. * Peter Psenak 01:42:36 @Aijun, usage of LSInfinity is allowed by the protocol spec * Aijun Wang 01:43:03 I think it is just one placeholder function * Peter Psenak 01:43:03 @Aijun, I d not agree on that requirement * Aijun Wang 01:44:27 we can rely on it temporarily, not definitely. we should not enhance its usage * Peter Psenak 01:44:57 UPA is temporary by definition * Aijun Wang 01:45:34 the signaling function will be used definitely in future * Peter Psenak 01:45:47 Who said that> * Aijun Wang 01:47:03 there may be other usage of LSInfinity, we shouldn't mix such function with it. The sooner to detach from the LSInfinity, the better * Tony Li 01:47:11 If you're not going to somehow get the Path MTU to the end host, I don't see the point. * Peter Psenak 01:47:25 Usage of LSInfinity is clearly defined and can not chnage * Jeffrey Haas 01:47:42 Tony Li said: If you're not going to somehow get the Path MTU to the end host, I don't see the point. it's for ingress steered tunnels that need to calculate path mtu. * Aijun Wang 01:48:32 No, currently, the spec only states that the associated LSA shouldn't be used in SPF calculation * Jeffrey Haas 01:49:02 FWIW, there's work in BFD to help test mtu end to end. https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ * Peter Psenak 01:49:14 That's exactly what we need * Weiqiang Cheng 01:50:25 @Acee Two questions: 1) For other type of LSA such as Type 5 LSA, How your solution works? 2) Your solution is the second solution in Liyan's presentation. As Liyan mentioned, it will cause statemachine changed. Is that more complicated solution than Liyan's solution, right? * Les Ginsberg 01:50:26 @Jeff I think the purpose of the BFD draft is different. It is to test whether the link works. It is not for "MTU discovery". * Ketan Talaulikar 01:53:57 Regd https://datatracker.ietf.org/doc/draft-hu-lsr-igp-link-mtu/ ... there is value for this information to be advertised as part of the topology information. Like TonyP said, there are cases of such "self inflicted wounds" out there. However, I don't think the IGP spec should go beyond that advertisement part. Path MTU and other aspects related to the usage of this link MTU info are better discussed separately. * Liyan Gong 01:54:26 @Acee, About the question 1), i give you an example. there is a external lsa which has not been re-originated, and the router-lsa has been re-originated（both sides are full）, the result is that the external route is still wrong although the spf is right.... the blackhole still occurs. * QIANG Wang 01:54:36 bypass my TTR topic ？@Christian * Les Ginsberg 01:55:25 Huaimo - what you propose on slides 5/6 does not work since it does not support parallel links between neighbors. * Aijun Wang 01:56:10 if all the routers support such capabilities, we don't rely on it anymore * Jeffrey Haas 01:57:43 Les Ginsberg said: @Jeff I think the purpose of the BFD draft is different. It is to test whether the link works. It is not for "MTU discovery". Agreed. I did say "test", not "determine". Part of the headache for these MTU mismatch headaches is thinking you've done the right thing to get a particular path mtu... then finding out it doesn't actually work. The motivation for the bfd large feature are things where the path is expected to work and doesn't, especially in wan environments. * Liyan Gong 01:59:09 @ Acee，about the problem 2), it is equivalent to abandon the action of the DD exchange, huge midification to the basic ospf protocol, and may cause extremely pressure and risk to all the routers in the network. * Les Ginsberg 01:59:14 @Jeff - I have very limited enthusiasm for the MTU extensions because I think the use cases typically prove not of practical value. * Tony Li 02:01:15 Once more, with feeling: the IGP is not a dump truck. Services should be advertised in the management plane. * Jeffrey Haas 02:02:08 Les Ginsberg said: @Jeff - I have very limited enthusiasm for the MTU extensions because I think the use cases typically prove not of practical value. I'm sympathetic. But MTU issues exist and some networks can't use the one MTU to rule them all. (And in the outage find them...) * Liu Yao 02:02:48 @Hongyi Huang We also have a IGP service function draft trying to be consistent with BGP-LS by advertising the SF function info as the property of SIDs instead of routers * Liu Yao 02:02:57 draft-lz-lsr-igp-sr-service-segments Les Ginsberg 02:03:28 @Jeff I don't object to the MTU draft - I just don;t have much enthusiasm for it. * Tony Li 02:05:04 @Andrew Alston That would be called a tunnel and making the controller an IGP speaker. Done. * Jeffrey Haas 02:05:08 Thank you, @Andrew Alston to lob that bgp-ls bomb at end of session. * Ketan Talaulikar 02:06:29 https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc7752bis#section-5.3.1.5 And similar for link and prefix attributes ... to put IGP info "opaquely" into BGP-LS.