LSR Interim Agenda Chairs: Acee Lindem, Chris Hopps Secretary: Yingzhen Qu WG Status Web Page: http://tools.ietf.org/wg/lsr/ Session #1 Date: Thursday, 02 April 2020 Start Time: 09:00 America/New_York 9:05 IGP Flexible Algorithm - Peter Psenak https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/ Chris Hopes: If the selection is done domain wide. Are you using system id for selection? Peter: The FAD selection happens in an area. It doesn’t have to be the same across areas. The selection is contained in each area. Jie Dong: Why os FAD generation from level 1 to level 2 not allowed? Peter: Where would you put your FAD definition? It is very likely in the backbone. The reason we define this is to avoid looping of FAD. You don’t want loop it back to L2. It doesn’t mean you can’t have FAD in L1, but it can’t be leaked. Jie: Did you consider the leaking between multiple instances or protocols? Peter: No. The redistribution is about prefix, not anything else. You implementation can do it, but it’s local behavior, not needed in this draft. Jie: So maybe each protocol can have their own 128 flex algos? Peter: Yes. Xuesong Geng: Is it allowed for user to change the metric? What if I want to use latency as metric? Peter: You can change the regular IGP metric. You’re allowed to change the delay metric. Xuesong: If I want a low-delay path. How can I do it? Peter: We allow the delay metric to be set manually. It’s up to the user to set the delay metric. Acee: Since there are implementations. We will poll how many read it, and see whether it’s ready for LC. Chris H: My concern is people may want to read the change. Peter: I can wait a bit. Not in a rush, but don’t want to wait until next IETF. Chris H: Everyone should read. It’s getting close to the WG LC. Acee: We’ll do a poll on the list. Alvaro: It will be great to have some operational considerations in the draft. To help people understand why. Peter: I can add it. 9:15 An Algorithm for Computing Dynamic Flooding Topologies - Sarah Chen https://datatracker.ietf.org/doc/draft-chen-lsr-dynamic-flooding-algorithm/  Acee: Do you have always use the subgraph you just added for endpoint selection for the next one? Sarah: Yes. Xuesong: Is this algorithm supporting only single failure? How about multi-failure? Sarah: The goal is to have a bi-connected graph so it still works when there is single failure. If there are multiple failures, we’ll need to do partition repair and flood over some temp links if the graph becomes disconnected. Xuesong: So in case of multi failures, we don’t go back to the original topology, but just some special links, right? Sarah: The area leader detects the topo change. Xuesong: Do you think it’s necessary to add some description about that. Tony Li: It’s in the base dynamic flooding draft. Aijun Wang: This algorithm can be used centralized mode, can it be used in distributed mode? How to ensure each node gets the same result? Sarah: For distributed mode, you need to make sure all the nodes get consistent results. We haven’t considered that. 9:45 Area Proxy - Tony Li https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/   Chris H: Is it working with SRv6 SID? Tony: I took the format from existing ISIS SR decoding. I’m not sure about 128bits SID. Acee: It’s different SUB-TLV. Tony: I’ll add SRv6 support. Acee: Speaking as WG chair. We started a bit discussion, considering we also have a similar TTZ draft for abstracting the areas. We didn’t see strong support on the list. Also there is collaboration problem. Is it still the case you have anonymous customer wants it? Tony: Yes. There are several customers interested in this. 9:30 Hierarchical IS-IS - Tony Li https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-extended-hierarchy/ Chris H: A picture will be helpful. Will it work if you advertise all levels always, make it mandatory? Tony Li: You could do that. But you may want to expand levels anyway. Chris H: If you’re level 5, you can always advertise level 0. Tony Li: That’s expanding the LSP space. Les Ginsberg: If you know what area you want to use at each level, you can always advertise them. But if you don’t know, you can advertise 0. Chris: Yes. I understood the transition. The tradeoff is LSP space. You can put real number there, but not enable them. Tony: Correct. Acee: Speaking as chair, is anybody implementing this? (No answer) Chris: The customer changed their minds? Tony: Customers are still interested, however multiple instances are capable of doing similar things. Adequate workaround. Nobody is in a rush to implement it. 10:00 Topology-Transparent Zone - Huaimo Chen https://datatracker.ietf.org/doc/draft-chen-isis-ttz/ Chris H: There are two similar solutions. OSPF is an experimental RFC, has OSPF been implemented? Has it been live in networks? Huaimo: We have a prototype implementation, but no deployment yet. Chris H: As far as I know, OSPF has not been deployed even though it’s an RFC. There are lots of similarities with differences. I’m not sure what to do with it. Acee: I’m not sure either. We have one more that’s not exactly the same but solves the same problem, flood reflector. In the past, we did experimental for all of them. Acee: Huaimo mentioned OSPF is experimental draft. Considering its Complexity and there are lots of corner cases. Alvaro Retana: What did we agree to? Considering I’m on one of the drafts, Martin Vigoureux will be in charge. 10:10 IS-IS Flood Reflection - Tony Przygienda https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection/ Chris H: I read the draft, it’s still complex to me. It talks about using L1 as transit for L2. Does it also do flood reduction? Tony P: It’s not about flooding reduction. If I’m forced to compare, it’s much less L2 topology to flood around. We haven’t thought through about multi-hierarchy levels, but as Tony pointed out, multi-instances can also solve the problem from practical point of view. This is for traditional a L1 and L2 network. This will work without changes to BGP LS. Acee: You said you added a section for tunnels. Tony: The prefix leaking is how you do without tunnels if you do it correctly. Acee: Just like ospf virtual links. How do you scale it? Do you have multiple L1 areas in parallel? Tony: Precisely. L2 doesn’t change much. It’s very practical problem. Forklifting the whole network even part of the network is a no starter. 10:20  IGP for Network High Availability - Huaimo Chen https://datatracker.ietf.org/doc/draft-chen-lsr-ctr-availability/ Tony Li: Seems to me this is controller communication channel issue, shy should it go into IGP? Huaimo: This is an information channel. It’s for communications when failure splits the group. Tony: You could have each instance advertise themselves, not in IGP. Huaimo: The election process happens in the cluster, IGP is just distributing selection information. Tony: Your TLV is a list of controller IDs? Huaimo: Those IGP just advertise information about controllers. Tony: Why do you need a proxy? Why do you need somebody to advertise multiple controller id? Huaimo: I agree. Normally we don’t need those. Tony: I still don’t understand. John Scudder: I agree with Tony. As I said in IDR, there are some well-known solutions, should not be in routing protocols. RFC7787, Distributed node consensus protocol, I’m not recommending it, but it exists. Huaimo: That’s another way. There are number of ways to provide HA, This is just another solution, might be simpler. Chris H: Echo early comments. The consensus is that this is a well-studied problem. There are five authors, not any references for what has been done before. As Tony said, why is it here? Regarding LSR, you will advertise the controllers and IGP as a transport. We may not want that. Huaimo: We’ll look at references. 10:30 Passive Interface Attribute - Aijun Wang  https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-00 Ketan: About using prefix to identify link? As discussed on the list, may not appropriate for inter-area links. The Link type stub may not enough to identify what kind of link it is. I don’t think it’s a good way of discovering the topology. Aijun: Do you have any other idea? Ketan: We can look at other proposals, let’s discuss offline. Aijun: Ok. Chris: Sounds like there will be more discussion on the list. 10:40 IGP Extensions for Advertising IFIT Node Capability - Yali Wang https://datatracker.ietf.org/doc/draft-wang-lsr-ifit-node-capability-advertisement/ Acee: You would have to compute a path with all the nodes have iFIT capability. Yali: Let’s look at the 2nd example. If there is any specific routing, like SRv6, we need to know the head and end node has iFIT capability to avoid header leaking. Transit node has trace option-type. Acee: You have to know the exact path for transit information. We can take it to the list. Chris H: It’s about advertising application in ISIS/OSPF. For an operator to deploy this, you just need to write a YANG model, you don’t need it in IGP. I think telemetry is important, but whether advertising it in IGP is needed, non-routing stuff. We need WG consensus. Yali: NETCONF/YANG is another way to do it. But this is another way to do it, why not? Chris H: If you start adding application capability in routing, more will come. Why is it needed in routing? Robin Li: From my point of view, MSD is advertised by IGP. I don’t think IFIT is an application, it can also related to SR path. IFIT information is needed when calculating SR path, so it’s path attribute related. Chris: Are you saying you will change routing based on iFIT info? Robin: Maybe not the path, but SR policy. Chris: If you’re saying you will route differently based on whether I can trace it? Then it belongs to routing. Otherwise, it’s something above. Robin: It belongs to traffic engineering. Let’s discuss it more on the list. Process wise, why is BGP-LS also in the draft? Chris: Speaking as chair, that’s the agreement with IDR. Robin: Might be too early to individual draft. John Scudder: Presumably any draft is hopping to get to WG doc, and you want the right format. I don’t think it’s too early. Acee: If this is just the information about capability, I don’t have much problem. But if we put other type of information, it will be too much. Speaking as WG member, also author of RFC 7770. Jeff T: Leaking this information to control plane is not a good idea. You will need configuration channel anyway. Comparing with MSD is not correct. MSD is used to calculate path. Acee: I agree with respect to MSD, it’s not the same type of use case. Jie Dong: Another example is seamless BFD. Chris: But it’s related to adj and path computation. Rakesh Gandhi: There is one requirement that SR head node needs the info. Aijun Wang: It should be in IGP. If you use NETCONF/YANG, it’s not enough. Chris: I don’t understand it. You can query anything with YANG. IGPs don’t have to be used as transport for router capability. The encapsulations, the calculation node needs to know it. As a chair, if you have some information want the network to know, we think of IGP easily. But we have to push back on this. Robin: There are not many protocols can be used. Rakesh: For SR MPLS, we use PCEP for advertising encapsulation capability. Acee: Speaking as co-chair, we should take it to the list. Another point is whether iFIT framework will be adopted. Yali: if the network is changing, IGP is more efficient way to collect the information. Acee: Is the framework being adopted? That has to come before we consider this. Robin: We will discuss iFIT in OPSWG, which is informational. Chris: As WG chair, it’s our job to let them know if we don’t like this work. 10:55 IGP Extensions for Segment Routing based Enhanced VPN - Jie Dong https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/   Tarek Saad: What’s the relationship between VTN ID and MTID? About VTN ID, is it global? Jie: We have 3 solutions: in the 1st and 2nd solution, it is 1:1; in the 3rd solution, it is different, we allow n:1 mapping; With respct to 2nd question, VTN ID is global for multi-domain. Tarek: MT ID is IGP construct, it’s within a domain. Jie: If you deploy in multiple domains, there are some constraints. Tony P: These L2 bundles running off L3? The real problem is the semantics, it’s not clear what the semantics is when you have multiple topologies. Jie: We need to specify the semantics about topology-specific TE. Tony P: How the resources are shared in IGP? L2 is an optimization. Jie: I’ll think about it.