LSR Agenda IETF 105 Chairs: Acee Lindem Chris Hopps Secretary: Yingzhen Qu WG Status Web Page: http://tools.ietf.org/wg/lsr/ Jabber room: lsr@jabber.ietf.org Status 13:30 5m Administrivia Acee/Chris 13:35 10m WG Status Update Acee/Chris 13:45 10m Update to LSR Dynamic Flooding https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/ Tony Li Tony: We'd like to ask for early allocation. Acee: I think we're ready for it. Tony: Anything we need to do? Acee: We'll ask Alvaro. Chris H: There was a good outcome from the interim. 13:55 10m Flooding Topology Computation Algorithm https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/ Huaimo Chen Huaimo: We'd like to request WG adoption. Acee: Any IPR in this? Huaimo: Yes. We'll disclose the IPR. Acee: You need to describe the previous next-hop better in the draft. It's hard to understand the draft without these pictures. I understood better from presentation. Huaimo: I agree with you. Tony Li: When we first started the flooding draft, we issued an IPR statement, but I don't know whether it covers this. Chris H: Do you know Arista's IPR discloser whether is IETF friendly? Tony LI: It's one of those we won't sue you if you don't sue us. Tony Li: Thanks Huaimo for the presentation. We looked at the draft carefully, We'd like to understand this, but we are not there yet. Is it intentional to be breadth search? Huaimo: It's based on the breadth first. it's just one proposal. Tony: We'd like to understand it better, anything you can do will be helpful. 2nd, have you done anything in your algorithm to constrain the diameter? Huaimo: Yes. Tony: We didn't see the diameter addressed by this algorithm in the draft. Huaimo: We'll add more examples. Acee: We'll discuss it more on the list. Alvaro: We have a new format for RFCs, and you can put in pics. This draft can be the first one to try it. Chirs H: It will be great if you can put some pics in the draft. we'll do the adoption, maybe after one more round. It's looking good. 14:05 12m IS-IS Flooding Speed advertisement https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ Bruno Decraene Kireeti: Why did you use upstream? What does it mean? Bruno: We're using upstream and downstream for sending and receiving. But when there are two sending nodes, it's not clear. Acee: You should put that in the draft to make it clear. We have different definitions in MPLS, and multicast. Kireeti: The interval is ms, shouldn't it be 100us? Because ms means 1000 per second. depending on your burst size. Let's use a number that makes sense. Chris H: I have the same comments. You could use 32 bits instead of 16, and call it micro seconds. Bruno: We've received comments on the list. Jeff T: It's applicable to instance. You're introducing additional per adj states. You send update to everyone. Bruno: You mean implementation for LSP pacing? But yes. 14:17 10m Flooding Acceleration on Tx Les Ginsberg Chris H: You're make assumptions based on implementations, like one FIFO queue. For such implementation, this is not easy, but it's not all implementations. Les: I don't necessarily disagree with you, but there are implementations doing this. There are reasons to be this way. Chris H: There are different considerations for doing this. Chris H: Lots of good work can be done on this. Who ever heard of receiver based flow control? oh right, RTS/CTS on serial links, etc.. I think you have valid points, like network wide fast flood. Maybe we need to look at the receiver side though. It would have been better if this had been discussed on the list. Acee: There was not enough time. Tony P: I largely agree with Les. The dense the network, this is a less issue. With modern techniques, per interface is doable. You should look more at the sender, it's much easier. I agree BCP is probably the best thing to do. Chris H: There is a reason for a draft no matter what. Les: The 33ms was meant for broadcast interface. Chris B: Your arguments are superficial. You're saying using Hello is out of band signaling consuming resources. Les: Are you saying to accept from receive end and do not change them? Chris B: Yes. Les: If you're not doing dynamic signaling, then it's fine. Tonly Li: I do agree we want things to converge, but I don't think the right answer is to slow everything down to the least. Les: I agree that's not the point we're trying to make. Tony Li: That means we have to have real active flow control. Receiver has to give you some feedback. Now I need to disagree with some of my co-authors that those number need to change pretty rapidly. It looks just like a TCP receiver window. Les: We're talking about flooding networkwide, not TCP connection. Tony Li: Seems like to have a local control loop is better. Receiver should provide feedback, make reinforcement to the sender. Chris H: you're raising the point of p2p not having limitation in ISO standard. they were saying as fast as you can. We're trying to figure out the side, sender or receiver. Acee: OSPF has nothing mandated, it's up to implementation. Bruno: I disagree that needs to be network level. We can be fast. Les: We all agree flooding is slower than necessary. The point I'm trying to make is flooding is a network wide parameter. Chris H: after 2nd session, we can talk about it. Rick: You're conflicting two points. One is p2p? 2nd is that link state is about consistent database across the network, you want to speed up your whole network. 14:27 10m Hierarchial IS-IS https://datatracker.ietf.org/doc/draft-li-lsr-isis-hierarchical-isis/ Tony Li 14:37 10m IS-IS Area Abstraction https://www.ietf.org/id/draft-li-lsr-isis-area-abstraction/ Tony Li Chris H: I asked Tony P about doing a presentation on why we should not be doing hierarchical link state routing and he said no. I haven't thought about WG adoption call, maybe we can ask the WG. Acee: if you have any question, please come forward. Chris H: I just don't want to jump the gun too quick. Rick: What's the main usage for this? Tony: The main use case is scale. All sorts of strange thing to resolve this issue over years. It's time to address this scale issue. Tony P: If you're interested in the reasoning, think why we didn't build BGP on top of ??. Tony Li: Hopefully in IGP you don't have policy to cause path invalid, therefore you don't need crank back. Chris H: There might be other issues. Tony LI: The point is to have the same mechanisms at different levels. Chris H: How many would like to see this adopted? Let's put this on the list. 14:47 10m Update IS-IS Invalid TLV https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-invalid-tlv Les Ginsberg Les: We'd like to request LC. Acee: We'll need to adopt it and have one more round before LC. Les: We're done, no additional work. 14:57 10m Update to IS-IS SRv6 https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions Peter Psenak Shraddha: We already have N bit. What's the difference with A bit? Peter: N bit is different. it's a node, not anycast. Peter: if there is something that's anycast, you want an anycast prefix. Not including N bit doesn't mean it's anycast. Shraddha: I understand N bit, why do you want to know whether it's anycast? Peter: I'm just saying A flag should go to a more generic subtlv. Shraddha: What about prefix advertised from different nodes? shall them have A-bit set? Peter: With a leak or distributed? There are different flags. I'll put this on the list. We will see whether anyone has implemented it and we don't want to cause problems. But I think it would be worth to move it. Acee: I agree any cast flag is generic other than SRv6. 15:07 10m Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS and OSPF https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/ https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/ Peter Psenak Ketan: I agree with the new proposal. There are applications that could benefit from the node attributes, now I have to look for it. Peter: I understand. But they are not the same thing. This is the best we can do. Acee: Most of time OSPF router-id is routable. Peter: but it's not 100%. Acee: if you advertise ERLD doesn't that imply you support? Peter: Yes. Acee: Maybe you want to add the BGP LS part, instead of making a separate draft. Peter: Welcome the contribution. 15:17 10m IGP Flexible Algorithm https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/ Peter Psenak 18:20 10m Advertising L2-Bundle Member Link Attributes in OSPF https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/ Ketan Talaulikar Acee: The ISIS equivalent is in RFC editor queue. Ketan: In the draft, it's marked as applicable. Acee: There are some inconsistencies in the draft. Ketan: I'll correct it. Acee: Maybe you want to call it sub sub TLV. Strict BFD https://tools.ietf.org/html/draft-ketant-lsr-ospf-bfd-strict-mode-02 Tony P: Why do you need this signal? what if you just don't send hellos. Ketan: Hello needs to be sent to detect the neighbor. We need the hello to start BFD. Chris H: How many read? and support? We'll put it on the list. Acee: Who added the OSPFv3 IPv4 instance? Ketan: We got it from a customer. Chris H: We'll have more time in the 2nd session to discuss to flow control. LSR Session 2 Monday, 22 July 2019, Afternoon Session III 18:10-19:10 Room Name: Duluth YANG Update Acee Lindem Acee: Has anybody looked at this model? Not many. Chris H: Will ask on list for adoption, shouldn't be any controversy with these standard modules. OSPFv3 SRv6 https://tools.ietf.org/html/draft-li-ospf-ospfv3-srv6-extensions-04 Ketan Talaulikar Acee: nybody read the draft? I'll review it. IS-IS Extensions To Support The IPv6 Compressed Routing Header (CRH) https://datatracker.ietf.org/doc/draft-bonica-lsr-crh-isis-extensions/ Shraddha Hegde Chris H: This is really new stuff. it was not presented in SPRING yet. Shraddha: The CRH was presented last time. Ron: It was presented in 6MAN last night. CRH will be in SPRING this Wednesday. Acee: We'll do the protocol signaling adoption after the main draft is adopted in 6MAN. Flood speed discussion Acee: OSPF does not have a gap, just implementations. That's current best practice. If we were to do it, it has to be standard track. You mentioned we're violating ISO standard, it will have to be standards track, right? Chris H: It wouldn't be bad to have something saying you don't actually have to send it that slowly. the discussions seem to be interesting, receiving side vs. transmitting. My key takeaway is that Les' idea is to look at more like flow control, retransmitting queue, and Bruno's idea is more proactive, finding out we're not flooding too fast, etc. Bruno: I'll provide comments on the list. So in the draft we're advertising static value, and the slides make the opposite claims. Chris H: Tony did say he'd disagreed with the authors and he thinks it might be a good idea. Les: Are you saying different flood speed on different interface through configuration? Bruno: Yes. It's up to the implementation and configuration. Les: one major point I was making is that's a bad idea. Bruno: we can discuss that. Chris H: I don't understand why we don't flood asap. Are you saying we should be pacing the entire network based on that link? Tony Li: Les's point is we flood irregularly, there might be micro loops. Ideally everybody should get all LSPs at exactly the same time. the only mechanism we have right now is hop by hop flow control. we can go faster than we can absorb. It's better to have receiver tell us how fast it can go, similar to TCP. Chris H: my point earlier was that this was not going to be a problem because L2 will handle it. That model to me is like flow control on a p2p link, not a domain wide value. That's why I thought it is correct to look at it from interface level. Les: If you have a network, where every interface is not capable of the same flooding rate, then your convergence will suffer. Flow control is not going to solve that. It can only temporarily slow down the link. We demonstrated years ago with consistent SPF value. Chris H: So ISO is broken. It can be sent as fast as possible. Les: It didn't say how fast. I'm talking about consistent convergence. John S: That's not true that network will run inconsistently with different interface speed. Nobody has complained. I understand there might be problems in some use cases. I'm sure it's not as bad as what Les said. Tony Li: Do we need to pace the network to the slowest node? maybe. but we may want to slam everything into the network as fast as possible, and the eventually the slow one will catch up. I think that's the best we can do. Acee: Modern IGPs don't have this inter-packet gap. I had one implementation, we used the OS scheduler and it worked fine. We had issues with LSA fragmentation. I'm not sure adding this complexity is needed. Chris H: Are you saying send as fast as you can? Acee: Sending as fast as you can with constraints. Bruno: You don't think it's a good idea to do flow control? Flood reduction is a good idea. One more thing, all LSPs are not created equal. Bruno: Maybe we should do some sort of prioritize. Acee: Yes. Bruno: Do you think we should do flow control on BGP? Or just ISIS? Chris H: We know we can kill routers by overflowing. I think we do have to do something. Acee: We do have pace control. Chris H: But most dynamic flooding is not based on feedback. Stephane: I'd suggest configure a timer on the sender side. Bruno: Which value will you configure? Different value for each network? Stephane: Similar value for all neighbors. Bruno: You will need to change configurations when there is like topology change in your network. Stephane: It's something manageable. Bruno: We don't do it. Chris H: So you're saying if you know there are LSP drops, you could change the pacing on that interface bring the number down? Stephane: Yes. My understanding is the config is static? Bruno: Yes. But you can change it. Stephane: There will be race conditions. Bruno: It's better on the receiver side. You can change depending on the hardware. And we'll use conservative value. Not as fast as you can to overload it. ??: We know we get micro-loops if we have SPF runs not synchronized or inconsistent database. I'd like it to be done on the fast side. I don't think trying to slow down is helpful. I'd rather to have receiver drop something and resend. Tony Li: There is value when converge fast. We have to do something, maybe not just timers. The right way is dynamic feedback. Chris H: We should model some of this. I think many of us are using a bit of intuition on the whole-system behavior based on experiences with more focused situations, modeling to verify expectations would be useful. Bruno: LSP pacing is used by everyone. Chris H: Using by everyone doesn't mean it's the right solution. Bruno: It means it works, and will be better if the parameter is correct. Ketan: What will be the default value? What's the requirement to be dynamic? Bruno: We're sending static value. No reason to be dynamic. Flow control is between sender and receiver. Ketan: If the receiver is busy, how does it know it will drop packets? Bruno: the dropping happens between line card and the control plane. It's a cost issue. Peter P: I don't see benefit if sending from the receiving side. And how do you find out what is the value you can start? Bruno: As a vendor, you should know better than I do. Peter: If you're talking about static, I don't understand. Only the sender knows. One more thing you can get packet drop between the line card and your ISP, and you will never know it. How does this work? Bruno: You don't know there are packet drops? What's the priority? Chris H: Your line card can tell you there is packet dropping. Tony Li: You don't know what you didn't receive. You can only know this is acknowledged. Acee: Typically those sockets are slower than NICs. Dino: Send as fast as you can means no delay timer. That doesn't mean packets will go as fast as possible. I don't think you can control it, there will be tail drop etc. The only way is to slow it down, is to have a whole network received at exactly the same time. If you have to send as fast as you can, the only way is to have some bandwidth delicate to control packets, and we may still run into problems in multiaccess network. So bottom line of my comments is as you can't control this, we're doing the best we can right now. Chris H: Right now we,re sending very slowly. For tail drop, there are priorities. ??: shouldn't we do something to get just one LSP update? Instead of 50 links? Acee: Let's not make it more complex. That's dynamic flooding. Enke Chen: I'm wondering how much we can learn from TCP? Bruno: I don't need to go as fast as TCP or BGP. Enke: The goal is to make it dynamic. Chris H: So far I think everyone has said dynamic, and that should be seriously considered. Gaurav: I agree we should go dynamic. Chris H - Chris Hopps Chris B - Chris Bowers Tony - Tony Li Huaimo - Huaimo Chen Peter - Peter Psenak Les - Les Ginsberg Tony P - Tony Przygienda Shraddha - Shraddha Hegde Bruno - Bruno Decraene Jeff T - Jeff Tantsura Dino - Dino Farinacci Rick - Rick Taylor Gaurav - Gaurav Dawra John S - John Scudder Enke - Enke Chen Ketan - Ketan Talaulikar Kireeti - Kireeti Kompella