Hi Eric, Indeed, my first impression is that you are indeed correct. Thanks from pointing this out. It seems to me a valid observation. One of the first worries we had while crafting the draft is the potential of ending up with a fragmented control plane environment.
A first impression is that adding restrictions upon anchor placement when +1 flooding anchor is used (for example they must be directly connected (or at least not further away as "1-hop")) could resolve this. It would be less gracious, but the simplicity of the algorithm may compensate for it. Thanks again for sharing this observation. G/ -----Original Message----- From: Eric Rosen <[email protected]> Sent: Monday, November 19, 2018 16:52 To: Henk Smit <[email protected]>; [email protected] Cc: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email protected]> Subject: Re: [Lsr] A new proposal on how to do Sparse Link-State Flooding in Dense Topologies Let's test out this simple algorithm on a simple topology: A--B--C--D--E--F where B and E are both configured as potential anchor nodes. To make it even simpler, suppose we set this up in the lab, and power up all six routers at the same time. Now there may be some moment at which: - A and C have seen LSPs from A, B, C, and D, but have have not seen the LSP from E. - D and F have seen the LSPs from C, D, E, and F, but have not seen the LSP from B. So A, B, and C will choose B as the anchor, enabling flooding on AB and BC. Also, D, E, and F will choose D as the anchor, enabling flooding on DE and EF. C will request flooding to be disabled on CD, since it leads away from B. D will request flooding to be disabled on DC, since it leads away from E. So there is no flooding on CD/DC. Now A, B, and C will never get an LSP from E, while D, E, and F will never get an LSP from B. Since CD/DC was never down, there is no reason to do a database exchange over it. It seems like the network is permanently broken, as the flooding topology is partitioned by CD/DC. Did I miss something? _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
