Minutes IETF105: lsr
Link State Routing
||Minutes IETF105: lsr
LSR Agenda IETF 105
Chairs: Acee Lindem
Secretary: Yingzhen Qu
WG Status Web Page: http://tools.ietf.org/wg/lsr/
Jabber room: email@example.com
WG Status Update
Update to LSR Dynamic Flooding
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.
Flooding Topology Computation Algorithm
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
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.
IS-IS Flooding Speed advertisement
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
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.
Flooding Acceleration on Tx
Chris H: You're make assumptions based on implementations, like one FIFO
queue. For such implementation, this is not easy, but it's not
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.
IS-IS Area Abstraction
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
Update IS-IS Invalid TLV
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.
Update to IS-IS SRv6
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
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.
Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS and OSPF
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
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?
Acee: Maybe you want to add the BGP LS part, instead of making a separate
Peter: Welcome the contribution.
IGP Flexible Algorithm
Advertising L2-Bundle Member Link Attributes in OSPF
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.
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
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
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.
Acee: nybody read the draft? I'll review it.
IS-IS Extensions To Support The IPv6 Compressed Routing Header (CRH)
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
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
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
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
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
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
Bruno: Maybe we should do some sort of prioritize.
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
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
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
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
??: shouldn't we do something to get just one LSP update? Instead of
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
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