LSR WG Agenda IETF-102 Time Slot (150m): Monday, July 16, 2018 09:30-12:00 EDT Chairs: Chris Hopps and Acee Lindem Secretary: Yingzhen Qu - Intro, Adminastriva, Document Status o Presenter: LSR Chairs (Christian Hopps, Acee Lindem) Les: 7810bis is not an RFC yet. we’d like to progress it fast. - Yang Updates o Presenter: Yingzhen Qu o Document: https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/ o Document: https://datatracker.ietf.org/doc/draft-ietf-ospf-yang o Document: https://datatracker.ietf.org/doc/draft-ietf-isis-sr-yang/ o Document: https://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/ Chris: I’d like to have both OSPF and ISIS progress together. Acee: Considering the size of the documents, maybe better to progress them consecutively. Instead of sending 240 pages document, 120 is probably preferred. Chris: I want to send both because if something wrong found in one document, it can be fixed in both. Jeff Hass: Considering what’s happened for BFD model, I’d suggest one at a time. Otherwise you may get lots of unusual comments, and it’s easier to get them resolved before sending the doc. Yingzhen: The authors are actively working on both documents and address comments together. Chris: I just don’t want to see an extra meeting added to this process. - OSPF Link Traffic Engineering (TE) Attribute Reuse o Presenter: Peter Psenak o Document: https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse Peter: Should be ready by next IETF for LC. No question asked. - IGP Flexible Algorithm o Presenter: Peter Psenak o Document: https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo Acee: Would it be possible to specify a loopback for each service and use Flex algorithm w/o segment routing? Peter: By loopback you mean specific address? Acee: Yes Peter: You can. The intention is you don’t have to. Acee: That would have be described in a separate IP-only draft. Peter: probably Acee: Speaking as Chair, I was not asking for this draft. It was just hypothetical. - Dynamic Flooding on Dense Graphs o Presenter: Peter Psenak o Document: https://datatracker.ietf.org/doc/draft-li-dynamic-flooding Acee: Is there an implementation done or underway? Peter: We’re looking at it. Acee: For these last two flood reduction, people are look at implementations. Peter: This is a generic solution for any arbitrary topology. Chris: Doesn’t multicast give you this kind of tree? Acee: It’s not reliable. Peter: You may come up with a spanning tree, but you want more, at least a bi-connected flooding tree. This is more interesting. - IS-IS Extensions to Support Routing over IPv6 Dataplane o Presenter: Peter Psenack o Document: https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions Acee: So for routers which don’t support this, will it install a route based on Normal OSPFv3? Peter: The router will see two different TLVs, reachability tav is preferred, but the result is the same. Jie Dong: Question about End.X SID sub-TLV. I see algorithm is added. In SR-MPLS, the algorithm is applicable only to prefix SID. Peter: In SRv6, the address is global. Although the locator SID has algorithm, we also added it here, it’s for consistency. You have certain locators which you want to use for a certain algorithm, but the end SID would actually fall from forwarding perspective, which will be part of a different locator and for a certain algorithm. You want to make sure you have a strict association. So, by specifying algorithm here you make sure that you're not going to use the wrong locator during the transition. That's basically the reason. Jie: So, if there's any inconsistency between these sub-TLV and the locators algorithm, which one will be preferred? Peter: Basically what you say is if I have a locator which is for a certain algorithm, I make sure that this one will pick that one and not the other one. For example, if you for some reason remove that locator that this one may fall into a different locator, so it is like you want this it to be algorithm five but it will fall back from the forwarding perspective. The best match would be something the locator which is of algorithm six. You don't want that to happen, you want to make sure that you pick the right locator so that's the reason why we have the algorithm field here. Sue Hares: Have you worked with BGP to make sure the changes are correct? Peter: If you mean BGP-LS, yes. - Restart Signaling for IS-IS o Presenter: Les Ginsberg o Document: https://datatracker.ietf.org/doc/draft-ginsberg-isis-rfc5306bis Chris: Does anybody object? No. Do people support? (a tleast 1/2 the room raised their hands). We’ll ask on the list. Comment from Jabber, no slides number. - IS-IS Routing for Spine-Leaf Topology o Presenter: Naiming Shen or Les Ginsberg o Document: https://datatracker.ietf.org/doc/draft-shen-isis-spine-leaf-ext Acee: We have lots of discussion on flood reductions. Chris and I are discussing strategy. We’d like to ask WG on how to progress them and deploy them? You want to add about requirement? Chris: We got lots of solutions. So I’m wondering how we pick? Or let the market decide? How to best progress? Jeff Hass: I didn’t follow this draft. My question is if you end up with different topologies. How could this be applicable? One of the things we've seen in the presentations including the open fabric presentation, is that other topologies are being explored for things. my question/comment to you all is this is optimized for that situation. If you end up with a different topology other than CLOS, how does this feature potentially interact with those? So as you consider do extensions you know consider how it might actually interact if you try to deploy it a different topology. Acee: I think this one is simpler that it's just between tier 0 and tier 1, so it's not limited to CLOS. Jeff Hass: Right and that's going to be probably the the single most common thing when you look at the other topologies know is when you get no an extra layer to up that it becomes more interesting. But my suspicion based on how this is seems to be presented is that the generalization of here's how it apply for the next levels are you actually doing Auto provisioning though otherr topologies. So you have basically the easy mode for clos and therefore you're going to have to know this is your levels 1 and 2, and that they auto-discover each other and can tell that they're miss wired. Acee: Zero touch provisioning it is targeted clos. Chris Martin: I was just gonna say that if you look at the agenda we still have I think two or three more presentations that cover areas like this and that doesn't include what's happening, for example, in RIFT. So going back to your point, in terms of how the market looks, at this point I would say that there's really what I mean from my view and just Jeff just mentioned this as well. There are at least four different approaches that are really tied to CLOS, and then there's maybe one or two that are in terms of generic topology. So maybe we look at them as they apply to them maybe the bigger use case which is leaf/spine or CLOS, and then you know the generic use case which is arbitrary topologies, and then let's decide there. Because there obviously is a big need for addressing this problem, and I just going back I mean having these discussions over the past couple years, we're trying to solve a flooding problem that's limiting link state protocols being used in leaf/spine or in clos topologies. If that's what we're trying to do, then that should be the fundamental requirement. you know a lot of the work that's coming out now over the past five years has been to try to fix the flooding problem, so we have BGP being used to fix flooding. When now it looks like everybody said well maybe we should just fix the flooding problem. So if that's the fundamental requirement I don't know if Chris is what you're suggesting that we go to a requirements document first, to try to solve flooding problems in IGPs. if that I mean I’ve seen a presentation at Manoa in 2000 and it was this comparative anatomy presentation. And basically there's a problem with scale is reduces really to flooding this is almost 20 years ago, and there's been no attempt made, so if that's really where we're trying to do then why we just focus on that. Chris Hopps: I don't know whether we go to do a requirmemnts document or not, or if it's enough to just talk on the list. But I think especially when you get competing solutions, and try to pick one, then sometimes requirements document helps focus on that. But I don't know if we're there yet. Russ: My take on this is I'm much preferential to having unified signaling than a unified solution at this moment. Because there are different scales and different kinds of topologies like Chris said, and Acee said that. You know we need to look at and I would just prefer for the moment just to get on the path of having unified singnaling and let's not worry about which solution is best depending on what happens in the marketplace, and where things go in the future. Because I'm not convinced that a requirements document is needed and I'm not certain that a requirements document is gonna be able to capture like operational realities in a way that's gonna have to be helpful in the long term. Jeff T: We started DC Routing a few IETFs back. As a result, we have two new WGs. I don’t think the end goal is to address the problem for specific topology. We should focus not only on flooding, but a new protocol on particular topology and see how it fits. Dino: Leaf/Spine topology has a big market. If you want to fix this problem in simple but large scale, have you considered static routing? ECMP and static routing will take you a long way. Chris H: Yes. Acee: A lot of these Controller-based solutions basically are static routing. It's just more dynamic than in the past. Dino: In SDN, what controllers do are in management plane to configure static routes. It was “ ip route” command in the 90s. Naiming: This proposal is very similar to static routes. You actually install two static routes. Tony P: The links still fails. The problem is you need to split whether you have a direct topology or generic topo. If you work on that stuff, I think you have to keep it apart, I think in the north/south direction, the topology is actually quite tractable, and there's a couple of different proposal of different properties. the generic problem has been walked for twenty with by multiple people with poor results. and I do not think that the results were improved because nothing new in graph theory and the properties you will find hot links and so on and so on are still in place. Whether the north-south is more immediate and I think it's much more tractable so it's kind of meta input. Naiming: Yeah, agreed. It's more into like the first tier fully mesh. Acee: Let’s start this on the list. - Preferred Path Routing (PPR) in IS-IS/OSPF o Presenter: Uma Chunduri o Document: https://datatracker.ietf.org/doc/draft-chunduri-lsr-isis-preferred-path-routing o Document: https://datatracker.ietf.org/doc/draft-chunduri-lsr-ospf-preferred-path-routing Acee: So the selection of preferred path is separate work? How do you know which subset of paths you’re going to do preferred path? Uma: PCE does the calculation like SR. Acee: This draft covers only the dataplane and the advertisement of the paths? Ketan: Isn’t this similar to RSVP-TE path, but populate the paths in IGP? It’s flooded across the domain and program the data plane. It’s really flooding N**2 paths across the domain? Uma: You don’t have to advertise the path if there is no issue with SPF SR. Ketan: Let’s say if there are 1000 paths, they will be flooded in the IGP domain. It’s really RSVP flooded by IGP. Uma: in RSVP, you don’t flood. Ketan: In RSVP, it’s only flooded to this hops, but you’re flooding the domain. Acee: Let’s take it on the list. Dino: #1 - Overwhelmed by the complexity. #2 - Your tax overhead was completely understated, #3 - I think you have to build new machinery to reinvent MPLS in a more complicated way. This is just my opinion and you could take it or leave it, doesn’t matter. You could have solved this problem with straight source routing, with not every hop-by-hop as the SID. You just could have found a repair path input one entry in the source route to get around the failure and that would have taken you a long way. Uma: It’s not only for FRR. FRR is a by-product. Dino: the basic stuff is complicated, and there is more coming. Chris: Let’s take it on the alias. Acee: Do you want to start a discussion on the alias?
 Uma: Yes. We’re ready. - IGP Extensions for Segment Routing based Enhanced VPN o Presenter: Jie Dong o Document: https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/ Peter: Biven MTR is available, obviously you can use it. My question is how’s the scalability? How many slices are you thinking of? You have too provision on each interface. There might be alternative solutions that can achieve the same thing in a better way. Jie: Let’s discuss it offline. The scalability of MTR is depending on the number of slices you have. We may see whether some optimization possible. Dino: I have a general statement not just about this presentation. I see maybe every five years, IGP is being used to ship the information across the network. You store it in LSPs in the middle of a network while nobody is using it but only the edge. We saw this long time ago with IBGP, and put in route reflectors. We need a reliable mechanism. Running multicast on edge for transport. There are only so many possible ways to do routing. People are taking all possible combinations. Stewart: I agree we need a general purpose way to propagate the message, but we do need to move along and ISIS seems to be a good solution in short term. We should separate the problems in long term. Chris H: Just want to clarify, Dino meant you may want to have it only on the edge routers not the center of the network. Dino: You have no flexibility because you have to change all routers. Stewart: This case it’s needed on all routers. Dino: Another way to think about it is to use mapping system. Stewart: For this particular application, we need it everywhere for traffic engineering to steer traffic. Acee: Because you’re doing resource reservation, you need not only edge routers to have the state. Stewart: We will need to introduce more states. it’s about particular resource. Jeff T: We have it presented in RTGWG several times. We need a more structured way. You may not want to flood it everywhere. Acee: TRhe base network slicing should advance before this one, correct? Jie: Yes. Acee: I’d advise people to read this draft. But we’re dependent on the progress of the base draft in SPRING? Jie: Yes. - OSPF Extend for Inter-Area Topology Retrieval o Presenter: Aijun Wang o Document: https://datatracker.ietf.org/doc/draft-wang-lsr-ospf-inter-area-topology-ext/ Acee: There is some history. We rejected a long time ago overloading OSPFv2 TOS bits for other purpose. All those using non-TLV proposals were rejected. I think Padma had a proposal a long time ago reusing TOS and we didn’t do it. At that time we didn’t have a way to extend ospfv2, now we should only use TLV. Chris H: You should just use TLV. Ketan: We shared comments offline. I think some of the non backward-compatible were addressed. Like Acee mentioned, we should use TLV. I’d support the use of source router id TLV. Acee: You can look at the use case, it might be weak. This could be used for other things, but please use TLV. Peter: I think we can use the source router id, but I don’t think it fixes what you’re trying to solve. Because what you advertised is prefix and you associate it with the Router ID. but what you have seems to try to do if I understood it from the layout, you are trying to reconstruct the topology but there's no topology data it's just the prefix. So I don't know how are you going to use this to reconstruct any topology data. Jie: Let’s take it offline. How to use the topology and prefix together. - IS-IS Support for Openfabric o Presenter: Russ White o Document: https://datatracker.ietf.org/doc/draft-white-openfabric/ Chris: I just want to clarify that we didn’t want to have any requirement document, that seems like a over kill. Russ: That’s fine. Acee: This seems to be a separate track because it diverges enough from standard IS-IS. Maybe it can be experimental? Have you considered checksum? Russ: Yes, we considered checksum. This should not matter. Christian: Flooding scope is not impacted by the checksum. Russ: If you have more questions, take them to the list. Chris: Do we have anybody with interop lab? To test these different algorithms? Maybe publishing paper? Russ: This is actually modeled using the same model as OSPF MANET. This is pretty much already deployed and running. Acee: OSPF MANET is much more complex than this one. Russ: Yes - OSPF Flooding Reduction o Presenter: Huaimo Chen o Document: https://datatracker.ietf.org/doc/draft-cc-ospf-flooding-reduction/ Les: We have two presentations saying the same thing. From WG perspective, we should not progress two documents. Acee: Intuitively Tony’s is better. You’re reverting back to normal flooding when you have more load in the network. You’re saving flooding when the flooding topology doesn't change. Huaimo: In that case, we have different solutions. we use those links to guarantee when one critical node is down, we use those links. In between some of the nodes are doing normal flooding, most of nodes are still optimized. Chris: Second what Les is saying, we don’t need two proposals for the same thing. Huaimo: Tony’s original proposal was centralized, and mine was distributed. Now Tony has distributed mode. There are more modes now. Chris: Maybe there are room for working together. Chris: Isn’t static configure work better? Huaimo: Static config is fine. we provide more options for customers.