Hi Robert, > But I really think this isn’t relevant. The use of LANs in the flooding > topology is only meaningful if we have a multi-access circuit which is used > for transit traffic. And at least some of us are leaning to allowing for that > possibility – which is not at all the same thing as saying you SHOULD run in > LAN mode even if you don’t have to. Nor is it encouraging the use of > multi-access LANs. > > > I guess this is the question ... is dynamic flooding a new flooding paradigm > in IGPs to be used everywhere or is it only applicable to densely connected > topologies ?
It is only sensible in dense topologies. In sparse topologies, such as you would find in a WAN, there is very little improvement to be had. For example, at Prague I showed an 8x8 grid. The FT improvement was only 36%. Given the computational cost, it’s probably not worth it. > If this is former - by all means support of real LANs is must have. If this > is the latter - I doubt. > > In fact if this is the latter more simplification in computing flooding > graph, less complexity in signalling and therefor less bugs will IMHO yield > much better outcome. > > In such cases it may be actually a feature to limit dynamic flooding to p2p > topologies only. Well, I have to disagree. While it’s nice to say that you will limit that feature to those topologies, real operators push the envelope all of the time. Things happen operationally. Folks can definitely use LANs advantageously in dense topologies. It makes sense to support them. > If you want a way to more easily enable P2P mode by default – speak to your > favorite vendor. That is a feature – not a protocol extension. > > > Completely disagree. To detect how many IGP peers are on the interface and > to do the switchover gracefully between 2 vs N or N vs 2 protocol extension > is needed. It is not a single side local hack. What extension are you proposing? Tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
