Re: [Lsr] Open issues with Dynamic Flooding

[Peter Psenak <[e-mail]>]

Hi Tony,

On 05/03/2019 17:47 , [e-mail] wrote:
>
> Hi Peter,
>
>>>> 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.
>
>
> What if the node in question is one of the spines?  Folks are building
> systems that large… and it seems inevitable that port counts will only
> grow.  Toto, I don’t think that’s an AGS any more…. ;-)
>
>
>> 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.
>
>
> LS topologies can have a very large number of adjacencies as well,
> typically with multiple spines, so for a new spine, all of the of the
> links may be unnecessary.

ok, we talked bout the balance before - adding one link at a time to the 
FT may result in slow recovery, while adding all link is claimed to be 
dangerous. What is the right number? I feel that the increment value can 
be something that the implementation can choose or even make 
configurable, so the user can decide based on the particular topology 
and scale. We are not going to find the magic value I'm afraid.

>
>
>>> 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.
>
>
> As Xiaohu suggested, the management plane would be an obvious
> application. Interconnects also seem likely.

I believe his case is completely orthogonal to this discussion as in his 
case there is a single giant LAN used for flooding and we all know we 
can not optimize flooding inside a LAN itself.

>
> Let’s set the algorithmic parts aside.  Do you have an objection to
> supporting them in the signaling?

will get complicated, especially for OSPF/OSPFv3. Also temporary 
flooding operation on LAN is tricky and sub-optimal. I don't really 
believe it's worth the complexity.

my 2c,
Peter

>
> Tony
>