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

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Mar 2019 12:00:57 +0100

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 ?

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.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 7 Mar 2019 12:11:31 +0100

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).
>
> 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

> 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-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Mar 2019 12:16:59 +0100

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.

But spec seems quite silent on such deployment model hence the post.

Thx,
R.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 7 Mar 2019 12:44:20 +0100

Robert,

> 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

> On Thu, Mar 7, 2019 at 12:11 PM Peter Psenak <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Robert,
>
>     > [email-masked] <mailto:[email-masked]>

---

From: [email-masked]
Date: Thu, 7 Mar 2019 07:09:35 -0800

> On Mar 7, 2019, at 3:16 AM, Robert Raszuk <[email-masked]> 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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 7 Mar 2019 16:28:00 +0100

> 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-masked]> wrote:

> 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
>
>

---

From: [email-masked]
Date: Thu, 7 Mar 2019 07:46:41 -0800

> 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:
> 

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