Robert,
On 07/03/2019 12:16 , Robert Raszuk wrote:
Hey Peter,
Yes I was not so much asking from the perspective of the node which does
not support it. I was more curious if his directly adj neighbor will be
smart enough to treat such node rigth.
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.
Spec says:
"In incremental deployments, understanding which nodes support Dynamic
Flooding can be used to optimize the flooding topology."
Given that the spec does not define any algorithm, not much can be said
on top of that.
thanks,
Peter
But spec seems quite silent on such deployment model hence the post.
Thx,
R.
On Thu, Mar 7, 2019 at 12:11 PM Peter Psenak <ppse...@cisco.com
<mailto:ppse...@cisco.com>> wrote:
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
> Lsr@ietf.org <mailto:Lsr@ietf.org>
> https://www.ietf.org/mailman/listinfo/lsr
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
