IETF 114 LSR Meeting 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/114/session/lsr Meeting Administrivia and WG Update Chairs (10 mins) Les Ginsberg: No progress with documents after WGLC. Any comments? Many document pending AD review. John Scudder: I’ve communicated with the chairs, my queue is backlogged. trying to get through it faster, but it will take a while to see the results. in terms what you can do to help, I’ll let you know if I need your help. Acee Lindem: A timely review would be preferred to a more extensive review more than 4 months later. John Scudder: That’s fair. Quick and timely getting through is preferred than waiting forever. [CANCELED] The IDR Chairs discussion about BGP-LS Sue Hares. (10 mins) Application-Specific Link Attributes BIS Les Ginsberg (10 mins) The authors requested WG adoption of these two drafts. A “Show of Hands” is done, and there is no objection. Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network - (15 mins) Chongfeng Xie / Jie Dong https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-sr-vtn-mt/ Les Ginsberg: There was discussion when the draft was adopted that the draft didn’t have much content. The draft is only meaningful when we do VTN forwarding. I strongly object going to LC Acee: We will take it to the last call when the dependent TE draft goes to WGLC. We won’t jump because it’s a simple draft. Chris Hopps: We can wait. Acee: We will take it to the list. It’s like doing the BGP-LS extension before the base draft is done. Jie: This is informational. This doesn't rely on the VTN extension draft. Acee: What about the VTN draft in TEAS? Jie: The VPN+ framework in TEAS plan to go to LC after this IETF. Chris Hopps: Let’s do things in the right order. Ketan: There isn’t anything change IGP, only informational. There is similar draft in SPRING, why not move everything to SPRING? Jie: This is about IGP. Ketan: It’s more architecture. Acee: We can keep it in the LSR. Chris Hopps: There is a 2nd presentation, the first one doesn’t have extension. Using Flex-Algo for Segment Routing based VTN Jie Dong/Yongqing Zhu Joel Hapern: There are two different notions mixed up, we need to clarify. There is VTN, flex-algo, and in TEAS, Network Resource Partition (NRP). In TEAS, it was decided not to have different topologies for scalability reasons. It seems if the VTN needs different resources, it needs a separate topology. That’s painful. It’s not clear to me whether it’s supported by this. Jie Dong: This is applicable to networks with small number of VTNs, even if we use separate topology, the scalability is acceptable. Hope that clarifies. Peter Psenak: I found this solution hacky. You’re doing this for specific reasons and it’s not common. Jie: this is to minimize the change to the protocol. If there are other proposals, we can talk off line. Chris Hopps: If we can find a good solution that works for all cases let’s not have multiple bespoke solutions. Jie: I understand one solution is preferred, while they have some different functionality and characteristic, similar to MT vs Flex-Algo. Acee: That’s a circular argument. MT is much simpler, you need to justify why you need flex-algo after you answer Joel’s question. Jie: The same reason as I replied to Chris. MT and Flex-ALgo are similar while have some difference. People can choose to use either one of them. We can have more discussion on the list. [target 10:45] Multi-part TLVs in IS-IS Tony Li (10 mins) https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/ Ketan: Question about the capability. Is it informational or will cause action? Tony Li: There are concerns about issues with legacy routers. There will be different behaviors, even crashes. Just don’t advertise multi-part TLVs until you assure every one supports it. Ketan: There are already implementations doing multi-part TLVs, is there something seen or reported? Tony Li: There are implementations doing multi-part, and there are implementations that don’t do multi-part. There's known issues. Ketan: It might be problematic to have router change behavior. Tony Li: That’s why we’re discussing. Chris Hopps: I know you don’t want to do a TLV catalog, but have we gone through the existing RFCs with TLVs that utilize multi-part, but dont’t talk about it? Especially with the new capability, I'd think we would really want to go back through all the existing TLVs. Tony Li: We’re trying not to be a catalog, we’d rather people have intelligence. The capability should be a trigger to be able to advertise multi-part. Les: There are multiple opinions on this. We should wait until the next version. If the capability is still there then we discuss. We should table it for now. Tony Li: indeed. we’re trying to make everybody happy, if you have a suggestion please let us know. Acee: If not every router supports multi-part and you won’t advertise, then you have to decide what to do with the additional information. Tony: My thinking is you don’t advertise it. Ketan: How do routers decide which not to advertise? Lots of things will get broken. Tony: Should do the legacy way. Ketan: Then we’re down to cataloging, which is old or new. Huaimo: It’s not backward compatible. Tony: It is backward compatible, but it’s not forward compatible. Huaimo: If we have multi-part TLVs, then old routers won’t recognize them. Tony: Exactly why we have the capability. Huaimo: Maybe better to have a solution so old routers can ignore the multi-part TLVs. Tony: Old routers won’t just ignore, they may crash. We don’t advertise the new things until we know all routers can process it. Les: This discussion needs to wait until next version. [target 10:55] IS-IS Optimal Distributed Flooding for Dense Topologies Tony Przygienda (10 mins) https://datatracker.ietf.org/doc/draft-white-lsr-distoptflood/ Acee: I like this version. It is a lot like the MANET OSPF, such as the two-hop neighbor. One question, the OSPF MANET draft was trying to get two copies of LSPs, this is trying to get one. Tony P: When you sort these neighbors, also the hash of the LSPs and system IDs, you may start from the middle, when you have full coverage of these two hop neighbors, you’re done. If it’s covered twice, doesn’t matter. It’s in the draft, maybe not, but that’s how double or triple coverage would work. Acee: You’re doing PSNP for LSPs that didn’t flood. Tony: Correct. Acee: That’s almost a PSNP every two seconds, that’s a lot. Tony: I didn’t think that. Don’t forget you’re load-balancing. You will only do some fractions of the flooding, depending the hashing function. Acee: Oh, it’s the ones that changed and didn’t get flooded. Tony: Yes. Ben Maddison: It seems like there are topologies that will save you more work than others. Lots of server providers may not benefit much from all these computations, have you looked at how to make recommendations? Tony: Look at the average fan out of your network. if you have a CLOS, you save a lot, but not much for a sparse network. Ben: In the case you have to compute the load-balancing, what if the responsible node for flooding fails? Tony: PSNP covers that. If you see this happen excessively, you need to fix that. Les: I’m not convinced that you don’t need to advertise whether a node needs support this. If not, why not define this as an algorithm and use the dynamic flooding? Tony P: First bring me a case why we need to signal this. Les: If I’m not going to flood and I’m expecting someone else to flood, and I don’t know whether we’re in sync. Tony: Think it through, the mix with old nodes just fine. The old guy still do the full flooding and that’s fine. Les: You use the term up-to-date PSNP, I have no idea how you determine whether the PSNP is “up-to-date”? unlike CSNP, PSNP doesn’t have the info. Tony: You have to list all those things. Les: Let’s take it to the list. Chris: "OSPF is obvious", seems like a classic Tony P statement. However, OSPF doesn't have an lossy database exchange, the DB exchange is done once and then the expectation is that the DBs are synchronized. This is different from IS-IS CSNP/PSNP which you are using here. It's not obvious to me how this would work with OSPF. Acee: We have an experimental draft on this, and this draft can reference that. IGP Unreachable Prefix Announcement Peter Psenak (10 mins) https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-ureach-prefix-announce/ Tony P: The infinity may trigger interesting bugs. This violates standard protocols. If we want to do it this way, at least list all the evils. Peter: There is an implementation, and it was tested. Chris: Your comment is if we have to do unreachable, you like this one since it seems reasonable. Tony P: If you have five other things related with reachability, you killed the whole thing. Peter: This is what happens today if you don’t summarize. If you lose reachability to one box and whatever follows. Aijun: We need explicitly to say it’s unreachable. Peter: I haven’t heard a technical argument that’s convincing. Aijun: There might be other cases using infinity to indicate other things. Peter: Let’s move it to the list. I don’t see a problem as this can get lengthy. Jie Dong: I made similar comments as Aijun. Infinity means the receiving router should not install the route and this is a new meaning. There can also be other use cases of Infinity metric. An explicit and accurate indication of the semantics is needed in the message. Zhibo Hu: Is Infinity metric that is used in IP Flex-Algo also interpreted as prefix unreachable? Peter: For IP flex-algo, the advertisement of the base TLV with infinity metric has the metric of flex-algo, so the infinity was never really used. You have to look inside for the metric. Acee: The beauty of this is we use the same mechanism as we use for backward compatibility for the signaling. Only routers supporting this will react to the notification. Chris: As a WG member, I don’t like any of these. Peter: That is clear. There are multiple ways to do it, we were asked by customers to solve it in IGP. Chris: It would be great if those operators could show up here. Prefix Unreachable Announcement Aijun Wang (10 mins) https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ Chris: As a chair, comments from the list are trying to justify this is the correct solution only because this has been there longer, but that’s never a reason. It has to be technically the best solution. Also while, you recognizing the problem earlier which is important, doesn’t make yours the right solution. There are comments on the list that people don’t like it. Aijun: The usage of LSinfinity in PUA and UPA is different. For PUA, the LSInfinity is used to avoid the misbehavior of the unsupported node, which is conformed to related RFC. But for UPA, the LSInfinity is used to indicate the unreachability of prefixes, which is not described in the related RFCs. Chris: as WG member, your comment about Peter’s draft is that LSinfinity is not good enough, but then it’s good to have it in your draft. It doesn’t seem genuine. Peter: We expressed many times that the mechanism you use is broken. When we started the draft, we invited you, but you took the LSInfinity and added it to the draft. I don’t know where you’re heading. Aijun: We are open to the other explicit indication solution, for example, newly define some flag. But for OSPFv3, there is limited space for the Prefix Option Flag. If we relied on the flag to indicate the unreachability, we must first extend the Prefix Option flag first. Peter: All you need is to signal unreachability. Whether implicit or explicit is up to the WG. Then what is left in your draft? Aijun: We need to how to control the advertisement of such information. Peter: I don’t believe so. Acee: Circular argument about whether explicit is needed. Aijun said something wrong about OSPFv3, we won’t use LSA option flags, but some other flags. Advertisement of Stub Link Attributes Aijun Wang (5 mins) https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/ Les: Question to the wg chairs. The draft has been here a while and there was an adoption call and it failed, why are we still talking about it? Chris Hopps: What Les said is true. When the adoption call failed, I asked to be mindful before taking it back. The rough consensus was not to adopt. You published a new version, and there were more discussions on the list that still objected. When is enough is enough? Aijun: The failure of first adoption call is because there are some technical issues that needed to be solved, it is not because it is unnecessary. We have updated the draft to address the comments from the first call, and it is also common for a document have an adoption call again based on the comments from the previous adoption call. If you have any additional comments for the updated draft, you can raise them and we can discuss them on the list. If you don't have any, we should more forward with this draft adoption. Chris: Not sure I followed you, will take it to emails. I think we need to consider letting this go. We keep talking about it but people do not seem to think a new solution is needed. Aijun: The operator has the final choices or judgments on whether one technology/solution is necessary or not. Chris: You’re right to get SP’s opinions and that they are very important, but they still have to be justified based on technical merit. Acee: Let’s take the question why we need another adoption call on the list. ================================================================================= ############ The following drafts didn’t get a chance to present during the meeting. ############ The following are new drafts that haven’t been discussed much on the list, so if time permits we will have these presentations, otherwise we’ll move them to the interim (planning in progress). IGP Flexible Algorithms Reverse Affinity Constraint Peter Psenak (5 mins) https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-flex-algo-reverse-affinity/ IGP extensions for Advertising Offset for Flex-Algorithm Louis Chan (10 mins) https://datatracker.ietf.org/doc/draft-chan-lsr-igp-adv-offset/ IS Extension to Advertise SRv6 SIDs using SID Block Liyan Gong / Weiqiang Cheng (10 mins) https://datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/ Advertising Exclusive Links for Flex-Algorithm in IGP Liyan Gong / Weiqiang Cheng (10 mins) https://datatracker.ietf.org/doc/draft-gong-lsr-exclusive-link-for-flex-algo/ Total: 125 mins