Minutes interim-2019-lsr-01: Thu 07:00
minutes-interim-2019-lsr-01-201905300700-01

LSR WG Interim Meeting
May 30th, 2019
Chair: Acee Lindem
Secretary: Yingzhen Qu

Attendees:
Acee Lindem
Aijun Wang
Donald Estelake
Henk Smit
Huaimo Chen
Jeff Tantsura
Ketan Talaulikar
Kiran Makhijani
Les Ginsberg
Lin Han
Mehmet Toy
Padma Esnault
Peter Psenak
Sarah Chen
Sriganesh Kini
Susan Hares
Tony Li
Tony Przygienda
Xufeng Liu
Yingzhen Qu
Zhenbin (Robin) Li

Chair:    Please be aware of IPR and Notewell.


Starting from Tony's presentation.

Tony:   Arista has filed an IPR claim on dynamic flooding.

Tony:   FT bit from Huaimo's draft is added and it's straightforward. There's
        a minor question I have here for the chairs, about how to deal with
        IANA. I'm not seeing a registry for the link attributes bit.

Les:    you're talking about the ISIS link attribute bits? There is a
        registry and it's referenced in the draft.
Tony:   Okay, my apology.


Acee:   did you say you only wait for 10 ms? So, actually when you receive a
        new flooding topology, you only flood it on the new and old for a
        certain amount of time.
Tony:   yes. Let me be clear that's 10 milliseconds between adding temporary
        additions.
Huaimo: if there are hundreds of links, are you going to do temporary
        flooding on those links?
Tony:   If we have hundreds of links that somehow have fallen off the
        flooding topology and where we have disconnected nodes. Yes, we're
        going to end up adding all hundred links. that the truly bizarre
        occurrence because that should not happen unless there's those nodes
        are truly disconnected.
Acee:   slide 5 please. I read the draft yesterday, this level of detail is
        not in the draft.
Tony:   correct.
Huaimo: this algorithm is not in the draft?
Tony:   yes, not in the draft.
Acee:   hopefully it will converge unless there are some other problems in
        the IGP domain. we don't even need to standardize it, don't we?
Tony:   we don't because as far as I can tell, there's no negotiation going on.
Acee:   it’s a local repair. it's good to have it for information but this
        could be modified based on experimentation.
Tony:   we’ve worked on it. Any other questions?


Huaimo presenting.

* FT bit discussion
Acee:   Let's do the discussion now.
Tony:   there is another reason why we don’t want to do it, consider the case
        where you've got parallel links between A and B. We may be flooding
        to each other on opposite link. If you use this mechanism, you're
        going to warn about an error, and there is no error.
Huaimo: In this case we can send a warning, then people or tools can analysis
        it.
Tony:   this generates lots of noises. Parallel links are extremely common
        these days, especially in data center topologies.
Les:    I did respond to your email on this on the list with some reasons
        why this was not a good idea. When you get a chance, you know, please
        reply to that.2nd, Tony, I agree with you. The way the bit is defined
        in the draft and I would hope the way that this would be used, even
        if we agreed to do what Huaimo suggesting is that it would be edge
        oriented. In other words, you have to advertise the bit on all the
        parallel links. But how you evaluate the bit depends upon whether the
        edges in the flooding topology or not. I think that's the only way it
        could work reasonably.
Huaimo: in cases there are no parallel links, should we do something?
Tony:   no need. If somebody wants to build a tool to look for this they can.
        You're advertising the information.
Peter:  it’s up to implementation, but no need to standardize anything.
Huaimo: so even if there might be problems, we're not going to take action to
        have a temporary fix?
Tony:   If there are real issues on the flooding topology, and partition
        repair would have acted to actually repair the flooding topology.
        This adds another level of worrying about things that we already have
        a mechanism for.


*FN bit discussion
Les:    this issue has nothing to do with dynamic flooding. If the WG decides
        to take it, it should be in a separate draft. Having said that, I'm
        not encouraging you to for example, issue another draft to propose
        this because I don't think this is a good idea. As you've mentioned
        and has been discussed on the list of this problem has already been
        addressed by implementation, without any protocol extension. I think
        there's some very significant issues associated with your solution.
        You're changing the state machine. You're trying to set up a
        negotiation based on partial information. I think there's a lot of
        problems with this solution, but I really would like to divorce it
        from dynamic flooding discussion.
Huaimo: I think this is in the scope of flood reduction. when there are
        thousands of links, we only need to flood over one or two links.
Peter:  there are other issues for this problem, not just flooding. I agree
        with Les, I can confirm there are implementations that solve this
        problem. And there are other problems associated with bring up of
        the large number of adjs. It is completely unrelated to flooding.
Huaimo: we’re talking about bring 1000 adjs up.
Peter:  if you solve this problem, then you wouldn't have that problem.
Tony:   If you solve it as a generic problem, then you bring up, links, a
        few at a time. And as you do that, partition repair within the
        floating dynamic funding would add some of those links to the
        flooding topology temporarily, creating flooding. Then you don’t have
        a problem.
Huaimo: this problem is from you.
Tony:   that was a better way to fix it.
Robin:  I’m confused. Tony mentioned some it was included in the draft?
Tony:   we haven’t included FN bit, just FT bit.
Acee:   the scenario is for thousand links?
Robin:  I agree that this can be solved by implementation, not protocol
        extension.

* Transfer
Les:    the draft has always had the ability to quickly and easily, transition
        between enabling and disabling. I think what we didn't have in the
        draft was a very clear explanation of how this is done. We added some
        language in the latest version v2. I'd encourage you to review that.
        But the draft already has the necessary mechanisms so I don't think
        any of this is necessary.
Huaimo: in the draft, you mentioned centralized mode. After the flooding
        topology is flushed, every node transition to normal flooding.
Les:    apologies for interrupting you but that's actually a point on your
        slides, which is incorrect. The flooding topology is carried in LSP
        or LSA, and if those LSP or LSA get updated, then everybody's link
        state database gets updated in a relatively short period of time,
        we're talking a matter of seconds, the flooding topology is then gone
        or updated. There is no separate aging of the flooding topology
        independent of the link states database. So point five are just not
        correct.
Huaimo: So the flooding topology is advertised by the leaders, so the leader
        needs to flush the LSAs when switching back to normal flooding.
Les:    that’s what the leader will do. the leader will withdraw the
        advertising whether that's purging and LSA, or in the case of ISIS
        it's simply removing the appropriate TLVs from the LSP , in which
        they were advertised, and they're gone.
Huaimo: so the leader will flush the flooding topology, and this is not wrong.
Les:    leader will update the flooding typology as necessary. again this is
        described in the updated language in the draft. I'm just, again to
        repeat, None of this is necessary. The existing TLV or sub TLVs we
        have are sufficient. And we try to make the procedures a bit clear
        in the latest version of the draft. If the language needs to be
        improved and certainly we're open to improving the language, but none
        of this is needed.
Huaimo: for the centralized mode, the draft is ok. For distributed mode,
        because we don’t have a way to tell each node to transfer to normal.
Les:    Actually we do. it’s in version 2.
Huaimo: how did you do that? because you need to transform to centralized
        mode. And then you withdraw the flood topology.
Les:    if I'm a leader, and I want to operate in distributed mode, but I want
        to disable the optimized flooding the dynamic flooding, at this point
        I simply advertise the algorithm zero and I don't advertise the
        flooding topology.
Huaimo: you only have two states. Central or distributed? You can use 0 for
        two things.
Les:    let’s take it offline. Again, I encourage you to read the updated
        draft it does explain how this is done.
Huaimo: we need to fix it. Robert also mentioned it in the list.
Les:    I will try to clarify on the list, but we do have it.
Robin:  I think both parties agree this needs to be fixed, and Les agreed to
        clarify on the list. from my experience, we may have to do protocol
        extension. Considering time, my suggestion it’s better to clarify
        it in the list.
Acee:   Les, please put it up again in the list. There are different ways to
        do it. any algorithm number devoted to normal flooding?
Tony:   we didn’t think it’s needed because disable dynamic flooding is
        terrible.
Acee:   we may want to disable it. so we need separate algorithm for central
        and distributed, then 0 for disable. either way works.
Tony:   we have it covered.
Acee:   Let's move on to the next one.


* Area Leader Sub-TLV
Tony:   I'm sorry you're having trouble understanding it. But the point of
        the area leader sub TLVs  are very clear. This was to carry the
        priority, and also to carry the algorithm for distributed mode. We
        should point out that the dynamic flooding sub TLV is was intended,
        so that nodes can indicate that they are participant and capable of
        operating with dynamic flooding. And also we carry around the
        potential algorithms for distributed mode. all nodes in the topology,
        assuming the codes present, advertising the dynamic flooding sub TLV.
Huaimo: this is also inline with broadcast network.
Tony:   That is exactly what we're modeling this after Yes, every area leader
        candidate needs to advertise a priority. some nodes if they are short
        on RAM or short on CPU, may choose not to be the area leader, they
        would not advertise an area leader priority. It's important that they
        be able to do that. Right way to do that is to not advertise the area
        leaders sub TLV.
Huaimo: you mean you have a way to advertise priority without area leader sub
        TLV now?
Tony:   the priority is in the area leader sub TLV. That is where it belongs.
        That is how a node indicates that it is willing to become area leader.
        The priority belongs in that TLV. if the node chooses the area leader
        it has to advertise priority.
Huaimo: that means every node will send leader sub TLV.
Tony:   selecting a distributed mode algorithm, and having them all not be
        elected except one is not a problem. That is the whole point.
Huaimo: either way can work, right?
Robin:  maybe for simplicity, maybe we should introduce the enhancement now.
Les:    this has been discussed on the list, you may want to have multiple
        area leader advertisements, So that if the current area leader fail.
        You don't have to go through a reconvergence cycle in order to elect
        a new area leader and get the flooding topology from the new area
        leader in centralized mode. So the idea of that we only want one area
        leaders sub TLV advertised leaves us very vulnerable.
Huaimo: The leader will be elected even though we have multiple area sub TLVs
        in the system. When the leader dies, a new leader will be elected.
Les:    that presents a significant convergence problem. And again, if you
        look at the latest version of the draft we've tried to clarify how that
        can be avoided. but it requires that there are multiple area leader
        sub TLVs that are always advertised. So apart from the fact that
        architecturally we have concerns about what you're proposing,
        operationally, it leaves us very vulnerable to a single point of
        failure, which we definitely don't want.
Huaimo: like DR operation in ISIS, we don't have any problem. Leader is
        elected dynamically. Let’s take it offline.


* Encoding
Tony:   In this example, have you incurred the fact that the link between
        RN11 and RN31 is also part of the flooding topology?
Huaimo: Good question. In this case, RN11 is local node, the link between
        RN11 and RN31 is included in the topology.
Tony:   I'm still now clear. it seems to me you added index for link?
Huaimo: no index for link, we only have nodes. the link is represented by
        local node and remote node.
Tony:   If I understand how to encode things here. Let's suppose that the
        links are RN2 to  RN31, and RN11 and RN31 are both part of the
        flooding topology. The way that I see you encoding this. You have RN1
        as an adjacent node, it's going to mark is external, and it's going
        to list RN31 as part of its adjacent nodes. Similarly RN11 that's
        going to have RN31 as one of its adjacent notes.
Huaimo: everything here is implied by the node, local node and the remote node.
Tony:   this implies to me that if you are bi-connected, that the index for
        the node has to appear twice in the block encoding.
Huaimo: no.
Tony:   If you don't do that, then how are you indicating which links to use?
Huaimo: yes, there are some duplications in some cases.
Acee:   it seems this encoding will be more as nodes will be listed as both
        local nodes and remote nodes. What’s the advantage?
Huaimo: slides 6-4. more efficient.
Donald: There's a problem with the nodes having to be listed multiple times
        because the links are all implicitly bi directional.
Tony:   It's a space efficiency issue.
Donald: I think this is more compact.
Tony:   I disagree.
Acee:   you still use the indices?
Huaimo: yes.
Acee:   How can this be more compact as listing multiple times? Didn't think
        much about ISIS, but in OSPF you could break it up into each LSA
        could have a part of it, and only change that. The other thing let's,
        let's get this into perspective you know like something for LSP or a
        router LSA, so that every node in the domain floods this, so it makes
        a bigger difference. as far as the flooding topology, it's only the
        area leader that's flooding it, so there's only one instance of it.
        so it's just a matter of compactness unless there's order of magnitude
        difference. I don't see that it's the most important, correctness is
        the most important consideration. I don't see that for something that
        there's only one instance. Let me ask this, do backup area leaders
        computed and flooded so it's ready to use right away?
Les:    that’s what we recommended the latest version. Because in the event
        that the area leader fails, this allows you to transition to the new
        area leader much more quickly.
Acee:   that’s what we did for the network lsa in ospf.
Huaimo: This is more efficient because of blocks.
Acee:   I don’t see why. This is actually more. The total size is more.
Huaimo: no. ..
Les:    Acee, I’d like to reinforce your point. I think the primary concern
        here is correctness. And because there's only going to be a small
        number of copies of the flooding typology. What we've recommended in
        the draft is see the area leader to advertise it and the second best
        candidate advertise it. Even if the final conclusion is that this
        encoding saves some number of bytes that the total value add to this
        when you look at the full size of state database is very modest.
        So to me, correctness is the dominant concern here.
Huaimo: The correctness is equal, also the complexity.
Aijun:  based on the block information, we can easily recover the flooding
        topology, but not with path info.
Tony:   paths are links in the topology.
Aijun:  block encoding is more structured.
Robin:  if we don’t use this enhancement, is there any critical issue?
Huaimo: no critical issue. This is for improvement. it’s to reduce flooding.
Tony:   It's true that we're trying to be reasonably space efficient. But as
        we've said many times, we are trying not to make things so complicated
        that things become fragile. if we were really trying to ultimately
        make everything efficient, we could actually use compression
        algorithms and run them on top of our LSPs before we flood them. set
        aside the patent issues, there's a question, is everybody got
        compression algorithm compressing correctly? We try not to do that.
        Again, correctness is more important than efficiency.
Huaimo: regarding correctness, the methods are equal.
Robin:  to simplify the discussions, we may not want to have too many options.
        2nd, if there is no critical issue, this can be for future discussion.


* Backup paths
Acee:   is this local repair?
Huaimo: the iteration is local, but computing the path is global. Because
        there is split, the database may be out of sync among some nodes, we
        add some links to make database resync, then we converge one step
        further. But for rate limiting, those flooding topologies are
        calculated by the leaders, and it may take a long time.
Tony:   that’s incorrect. Both mechanisms needs full topology information
        for repair.
Huaimo: For the backup path, we don't depend on the flood topology computed
        by the leader. as soon as we calculate backup paths, we enable them.
        For rate limiting, each node needs to check whether this is a link to
        the remote site through flooding topology computed by the leader.
Tony:   I disagree. the correct thing to do here, regardless of which
        mechanism you use, to determine which temporary links to flood on is
        to notice that as soon as you have repaired the partition, you're
        going to get new LSP information. As soon as that happens. Assuming
        centralized mode, so we could be just on the same page. Then the area
        leader is going to have to re compute the flooding topology in both
        situations.
Huaimo: no. the area leader will compute the flooding topology.
Tony:   rate limit checks change, then decides that it has to reevaluate. At
        that point, is going to see it and flooding topology, and proceed
        differently. could conceivably add more links while it's waiting for
        the topology. But that's largely irrelevant because it gets the
        flooding topology it's going to disable it.
Huaimo: we need to check based on flooding topology.
Tony:   rate limiting acting on topology change, not flooding topology.
Huaimo: so you will need to check whether a link is part of the flooding
        topology.
Tony:   after you done a successful repair, the flooding topology is going to
        change. we're discussing in the arrival of the flooding topology
        information, and some other events.
Huaimo: so depending on the flooding topology change, you iterate further,
        right?
Tony:   if necessary.
Huaimo: yes, that's the difference. The backup path is not depending on the
        flooding topology change.
Tony:   it still has to look at the flooding topology to determine if there is
        a partition, it’s completely dependent.
Robin:  is there a case that no backup path in some topology?
Huaimo: as soon as the topology is connected, we will have a unique backup
        path. if the topology is physically split, no way we have a backup
        path.

Robin:  from my experience, partition is a real problem. And it’s better to
        use back up path to fix the problem.
Acee:   how does a node know there is partition before area leader computes?
        You don’t know where is going to be partition. How to you calculate
        repair paths? are you saying you compute every node you're connected
        to?
Huaimo: This is on demand. as soon as there is failure, we assume there is
        partition and compute backup path.
Acee:   any reason this enhancement couldn't go on a 2nd draft?
Tony:   we’re trying to have one draft.
Acee:   but this is something extra.
Tony:   We need one consistent algorithm for the domain to act on for
        partition repair.
Acee:   independent of this, centralized or distributed, you will have a new
        flooding topology whether or not you try to do this backup. So the
        question is does this do anything faster? How does a guy in the middle
        of the flooding topology know that there is a partition? I'm saying
        let's just say you're doing distributed because it's easier to see the
        analogy. If you're doing this on on demand backup path, you might as
        well just compute a new flooding topology. Because everybody's going
        to converge to a new topology sooner rather than trying to do a repair
        with the existing one.
Les:    Acee, I think that's the that's the catch 22 here. if the flooding
        topology is partitioned, you don’t know what you don’t know. You can
        only detect locally, like your neighbor is not on the flooding
        topology.
Acee:   then why is this better then temporary flooding?
Huaimo: with backup paths, it convergences faster, also minimum number of
        links, and algorithm is simple
Acee:   are you tunneling?
Huaimo: no tunnel. because every node use same algorithm will come up with
        the same backup path.
Sarah:  every one has the same algorithm but not the same DB, so the back up
        paths might be different.
Huaimo: we will come up with same unique backup path no matter of the database
        and the partition. it's guaranteed.
Acee:   I don’t think it’s simple. Node on the back up path will need to know.
        It’s squared.
Huaimo: No. Every node compute backup path from A to B. ...
Acee:   Let’s take it offline. I will think more about it.
Sarah:  you seem to enable more links for temporary flooding.
Huaimo: no. minimum number of links are used.
Sarah:  some cases, it may enable less links but not all cases.
Huaimo: no.
Tony:   you don’t know that yet. Because you don't have critical information
        about everything north of the partition. You only have database
        before the partition. your calculation is not correct.
Huaimo: Iteration is different. This one is more locally.
Acee:   this one we don’t think we have a converge. I don’t see the advantage
        of this because you don’t really know the whole topology. If you have
        multiple failures, you don't know where the failures are. Let’s take
        it offline. The rate limiting is already in the draft. 


Acce’s Somewhat Biased Summary of today's Dynamic Flooding Discussion


    1. FT Consistency Check - This has been incorporated into the Dynamic
       Flooding draft but in the LSPs/LSA encodings rather than hellos. 

       Consensus of the room was that we should not prescribe the behavior
       when there is a disagreement on flooding topology. The check doesn't
       work when there are parallel links given that while flooding
       topology inclusion is bi-directional, nodes may use different links. 


    2. Flooding Negotiation Bit - this is meant to solve the problem of a
       node entering the domain that has many links. 

       This problem is really a generic problem independent of dynamic
       flooding. Additionally, the proposed solution negotiates flooding
       when it is really a problem of the node with all the links entering
       the the IGP domain. Also, it only takes effect after the adjacencies
       are formed which doesn't address a large part of the problem. 

    3. Transfer between Flooding Reduction and Normal Flooding

       This is handled in the current draft. We can verify on the list
       that this mechanism is sufficient. Les to start an Email thread.
 
    4. Enhancement related to Area Leader Sub-TLV

       It seems that either encoding would work. However, I can't
       see that the proposed change offers any advantage. The existing
       encoding consolidates area-leader information in a single
       TLV (priority and proposed algorithm) which, at least in my
       opinion, seems to be a minor advantage. In any case, it doesn't
       worth a protracted debate. 


    5. Enhancement on Flooding Topology Encoding 

       I don't believe we concluded this discussion and this needs to be
       continued on the list along with some examples. I think there was
       general agreement that compactness is not the primary
       consideration here given the flooding topology is only flooded by
       the area leader and, potentially, one or more backups.
       Consequently, I view the consensus as not pursuing the compressed
       path encoding. Between the path and block, we should continue the
       discussion on the list with emphasis on clarity, consumption, and
       dynamics rather than initial byte size. A potential outcome could
       be that it doesn't really make that much difference as the two
       are roughly equivalent.
     
    6. Flooding Topology Backup Paths

      This one is somewhat of a misnomer. A heuristic was presented at
      interim for handling partitioned flooding topologies. Huaimo
      presented another heuristic to solve this problem based on
      computation of backup path to a router adjacent to the partition
      breakage. I believe we need to continue this discussion with in
      terms of the following:

         - Behavior of routers adjacent to the partitioning 
         - Bahavior of other router in the domain 
         - Information required for hueristic to fix the partiion 

      Both Huaimo and the dynamic flooding draft authors have thought
      about the problem infinitely more than myself. 


Thanks for people attending this. Special thanks to Tony and Huaimo 
for leading this discussion.