Hi Robert,
On 07/03/2019 12:00 , Robert Raszuk wrote:
Hi,
My reading of draft-ietf-lsr-dynamic-flooding indicates that said
document in number of places rather assumes that entire topology (entire
instance) supports dynamic flooding (perhaps other then bootstrap phase).
Let's observe that there can be lots of L3 TORs only dual attached to
access routers which will not benefit at all to be part of the game.
Moreover those TORs may be from different vendors and could support link
state protocols without any dynamic flooding extensions.
So the question is if the proposal considers a case where only part of
the fabric in single topology, single area/level, single LSDB etc. is
aware about dynamic flooding protocol extensions ?
sure, see section 5.1.2.
If the node does not participate in dynamic flooding, it will use
standard flooding mechanism. This means that the flooding may be less
optimal, but nothing would break.
If you wan to be extra smart, your algorithm can even take the node
participation into account and compute the flooding topology with that
in mind.
thanks,
Peter
Let's also observe that In any deployment such state when some nodes are
enabled and some not for dynamic flooding can happen during migrating
phase or operator's errors which one would assumed must be handled
correctly by the protocol.
Many thx,
R..
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
