> The upstream nodes do need to be told this. Well unless they know by design to always flood when peer is not dynamic flooding capable.
Yes today this seems to be consider transient and rather an exception (example bootstraping or incremental deployment). My main point was should this be also a valid and legal deployment model ? The draft is actually on one hand says the above and on the other indicates that dynamic flooding could be enabled and run only on part of the area: Flooding that is initiated by nodes that support Dynamic Flooding will remain within the flooding topology until it reaches a legacy node, which will resume legacy flooding. See TORs are one case .. but there are ideas to run dynamic protocols to the hosts too. I have heard there was even a volunteer to write ISIS-lite to be used on hosts :) However If you mandate that all of the members must be included in the flooding graph the leaders may get a little bit busy from time to time. Of course one option is to just split those into separate areas or levels, but keeping it at single one could be considered attractive. Robert. On Thu, Mar 7, 2019 at 4:09 PM <[email protected]> wrote: > > > On Mar 7, 2019, at 3:16 AM, Robert Raszuk <[email protected]> wrote: > > And precisely to that point I have tried to indicate that if this is by > design there is no point of including those 100s of TORs in constructing > and distributing flooding graph. > > > > And to the point of the algorithm, including those 100s of TORs in > constructing the graph is absolutely necessary. In the case where the > TOR’s have a pair of upstream nodes, you want both of those upstream > interfaces enabled for flooding. The upstream nodes do need to be told this. > > Tony > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
