Minutes IETF105: lsr
minutes-105-lsr-01

Meeting Minutes Link State Routing (lsr) WG
Title Minutes IETF105: lsr
State Active
Other versions plain text
Last updated 2019-07-25

Meeting Minutes
minutes-105-lsr

   
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