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

LSR WG Interim Meeting
May 30th, 2019

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 P
Xufeng Liu
Yingzhen Qu
Zhenbin Li

Chair:    Please be aware of IPR and Notewell.


Starting from Tony Li'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 it'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's the truly bizarre
        occurrence because that should not happen unless 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, do 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. They may be flooding
        to each other on opposite links. 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 noise. 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. Second, 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 are 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 in the flooding topology, then partition
        repair would have acted to actually repair the flooding topology.
        This adds another level of worry 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 on, 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,
        this problem been discussed on the list and 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 the 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 adjacencies. It is completely unrelated to
        flooding.
Huaimo: We’re talking about bringing 1000s of adjacencies 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
        dynamic flooding domain  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 that it was included in the draft?
Tony:   We haven’t included FN bit, just FT bit.
Acee:   The scenario is for thousands of links?
Robin:  I agree that this can be solved by implementation, not protocol
        extension.

* Transition between Flooding Reduction and Normal Flooding
Les:    The draft has always had the ability to quickly and easily, transition
        between enabling and disabling dynamic flooding. 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 transitions 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 LSPs
        or LSAs, and if those LSPs or LSAs 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 is 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:    The 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, that none of this is necessary. The existing TLV or
        sub-TLVs that 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
        flooding.
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 dynamic flooding, at this point
        I simply advertise the algorithm 0 and I don't advertise any
        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 was, as intended,
        so that nodes can indicate that they are capable of operating with
        dynamic flooding. And also we carry around the potential algorithms
        for distributed mode. All nodes in the flooding topology, assuming
        the nodes support ing, are 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. The right way to do that is to not advertise the
        area leader 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 sub-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 fails,
        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 is that we only want one area
        leader sub-TLV advertised leaves us very vulnerable.
Huaimo: The leader will be elected even though we have multiple area sub-TLV
        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.


* Enhancements on FT Encoding
Tony:   In this example, have you considered 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 that you added an 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. This is the way that I see you encoding this. You
        have RN1 as an adjacent node, it's going to mark it as external, and
        it's going to list RN31 as part of its adjacent nodes. Similarly
        RN11 is 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 multiple LSAS
        and would only need to flood LSAs that change. The other thing,
        let's get this into perspective compared to an IS-IS LSP or a
        router LSA, where 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 not 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
        for which there's only one instance. Let me ask this, do backup area
        leaders compute and flooded the FT so it's ready to use right away?
Les:    That’s what we recommended in 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 considered for the Network-LSA in OSPF. Ended up with
        only the DR flooding the Network-LSA.
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 advertises it. Even if the final conclusion is that this
        encoding saves some number of bytes, the total value add to this
        when you look at the full size of link 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, has everybody got
        the acompression 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.
        Second, if there is no critical issue, this can be for future discussion.


* Backup Paths for FT Partitions
Acee:   Is this local repair?
Huaimo: The iteration is local, but computing the path is global. Because
        there is a 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 flooding 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, is to determine which temporary links to flood on
        and  to notice that as soon as you have repaired the partition, you're
        we are 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 a node decides that it has to
        reevaluate. At that point, it is going to see it and flooding topology,
        and proceed differently. We could conceivably add more links while it's
        waiting for the topology. But that's largely irrelevant because as
        soon as 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 have done a successful repair, the flooding topology is
        going to change. We're discussing 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 there is 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 backup path to fix the problem.
Acee:   How does a node know there is partition before area leader computes?
        You don’t know where it is going to be partitioned. How to do 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 converges faster, also minimum number of
        links, and algorithm is simple.
Acee:   Are you tunneling?
Huaimo: No tunnel. Because every node using the same algorithm will come up
        with the same backup path.
Sarah:  Every one has the same algorithm but not the same DB, so the backup
        paths might be different.
Huaimo: We will come up with the same unique backup path no matter of the
        database  and the partition. Ot's guaranteed.
Acee:   I don’t think it’s simple. Node on the backup path will need to
        know.  It’s N squared computation.
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:  In 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 local.
Acee:   This is where we don’t 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. So here is a
        summary.
        FT: there is no good reason for it.
        FN: needs to discussion more.
        Flooding Mode Transition: may need more clarification.
        Area leader: Didn’t really understand. What was it solving?
        Encoding: Not sure about the blocks vs path - need more discussion.
        Backup paths: This also needs to be discussed.
        I’ll send an email. Thanks for people attending this. Special thanks
        to Tony and Huaimo for leading this discussion.