Re: [Lsr] Open issues with Dynamic Flooding

[Tony Przygienda <[e-mail]>]

in practical terms +1 to Peter's take here ... Unless we're talking tons of
failures simultaneously (which AFAI talked to folks are not that common but
can sometimes happen in DCs BTW due to weird things) smaller scale failures
with few links would cause potentially diffused "chaining" of convergence
behavior rather than IGP-style fast healing (and on top of that I didn't
see a lot of interest in formalizing a rigorous distributed algorithm which
IMO would be necessary to ensure ultimate convergence when only one/subset
of links is used). Slow convergence is obviously not a good thing unless we
assume people will run FRR with its complexity in DC and/or no more than
one link every fails which seems to me bending assumptions to whatever
solution is available/preferred. To Tony's point though, on large scale
failures enabling all links would cause heavy flood load, yes, but in a
sense it's the "initial bootup" case anyway (especially in centralized
case) since nodes need all topology to make informed correct decisions
about what the FT should be if they don't rely on whatever the centralized
instance thinks (which they won't be able to do given the FT from
centralized instance will indicate lots links that are "gone" due to
failure). As to p2p, I suggest to agree whether you use dense mesh (DC)
case or sparse mesh (WAN) case or "every topology imaginable" since that
drives lots design trade-offs.

my 2.71828182 cents ;-)

--- tony

On Tue, Mar 5, 2019 at 8:27 AM Peter Psenak <[e-mail]> wrote:

> 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
> >
> > .
> >
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>