> Well unless they know by design to always flood when peer is not dynamic > flooding capable.
That would be an extremely detailed piece of corner case coding. ;-) > > 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 ? Yes, certainly. > 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. I don’t see that this is contradictory. Rather it is endorsing it. > 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 :) I would…. discourage that concept. > 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. The leader will be busy regardless. Recognizing that something is a legacy node and special-casing it is not a significant win. The cost comes in exploring the topology. Handling two link nodes is pretty much the same, regardless of whether it’s a legacy node or not. > Of course one option is to just split those into separate areas or levels, > but keeping it at single one could be considered attractive. Splitting it would cause massive confusion, so I agree with keeping it to a single area. Tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
