Re: [Lsr] Clarification on co-existance of dynamic flooding aware and not aware nodes

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 <ppsenak@cisco.com
> <mailto:ppsenak@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
>     >
>