Re: [Lsr] Open issues with Dynamic Flooding

[Peter Psenak <[e-mail]>]

Hi Tony,

On 05/03/2019 17:16 , [e-mail] wrote:
>
> Peter,
>
>>>    (a) Temporarily add all of the links that would appear to remedy the partition. This has the advantage that it is very likely to heal the partition and will do so in the minimal amount of convergence time.
>>
>> I prefer (a) because of the faster convergence.
>> Adding all links on a single node to the flooding topology is not going to cause issues to flooding IMHO.
>
>
> Could you (or John) please explain your rationale behind that? It seems counter-intuitive.

it's limited to the links on a single node. From all the practical 
purposes I don't expect single node to have thousands of adjacencies, at 
least not in the DC topologies for which the dynamic flooding is being 
primary invented.

In the environments with large number of adjacencies (e.g. 
hub-and-spoke) it is likely that we would have to make all these links 
part of the flooding topology anyway, because the spoke is typically 
dual attached to two hubs only. And the incremental adjacency bringup is 
something that an implementation may already support.

>
>
>
>> given that the flooding on the LAN in both OSPF and ISIS is done as multicast, there is currently no way to enable flooding, either permanent or temporary, towards a subset of the neighbors on the LAN. So if the flooding is enabled on a LAN it is done towards all routers connected to the it.
>
>
> Agreed.
>
>
>> Given that all links between routers are p2p these days, I would vote for simplicity and make the LAN always part of the FT.
>
>
> I’m not on board with this yet.  Our simulations suggest that this is not necessarily optimal.  There are lots of topologies (e.g., parallel LANs) where this blanket approach is suboptimal.

the question is how much are true LANs used as transit links in today's 
networks.

thanks,
Peter

>
> Tony
>
> .
>