Robert,
On 05/03/2019 20:12 , Robert Raszuk wrote:
Slow convergence is obviously not a good thing
Could you please kindly elaborate why ?
With tons of ECMP in DCs or with number of mechanism for very fast data
plane repairs in WAN (well beyond FRR) IMHO any protocol *fast
convergence* is no longer a necessity. Yet many folks still talk about
it like the only possible rescue ...
we are talking about the control plane convergence, not data plane one.
If the flooding topology is subset of the real topology, then at the
flooding level you don't have all the ECMPs available - you only have
two paths to reach any node. In such case it is possible that the
flooding topology gets partitioned and you want to get out of that state
quickly, as you may get out of sync with the the reality and eventually
loose all the data plane ECMPs as a consequence.
thanks,
Peter
On Tue, Mar 5, 2019 at 5:42 PM Tony Przygienda <tonysi...@gmail.com
<mailto:tonysi...@gmail.com>> wrote:
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 <ppse...@cisco.com
<mailto:ppse...@cisco.com>> wrote:
Hi Tony,
On 05/03/2019 17:16 , tony...@tony.li <mailto:tony...@tony.li>
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
Lsr@ietf.org <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
