[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-ospf
Subject:    Re: [Lsr] Open issues with Dynamic Flooding
From:       tony.li () tony ! li
Date:       2019-04-02 21:33:55
Message-ID: 6AC654AF-3FE8-467C-9995-706037BEAD4F () tony ! li
[Download RAW message or body]


Hi Huaimo,

> Can you give some details about: what is the rate limiting link addition and how \
> does it (the rate limiting link addition) fix or help fix the flooding topology \
> (FT) split when multiple failures occur on FT?

The details of the wording will have to wait until someone (probably Peter) drafts \
them. In general, what we do in such cases is to leave the implementation details to \
the respective implementations.

As we've discussed, when there is a partition of the FT (or equivalently, new nodes \
that are not part of the FT), we need to add links temporarily to the FT to restore \
flooding. We agree that we want to add a link when one (or more) of the parties \
appears to not be on the FT.  If we happen to pick the right links to add \
temporarily, this should repair the partition.

Where we have had a discussion was about how many links to add.  As I've described, \
some people feel that adding links aggressively is the best course of action, because \
convergence time is an issue.

Others feel that adding too many links too quickly may lead to excessive flooding and \
a possible cascade failure.

Rate limiting is something of a compromise between these two extremes.

Yes, I freely admit that it is a weasel-wording approach to a compromise.  It \
basically implies that anyone can do anything that they want.  Until we clearly know \
more, it's the best that we can do.

Call it an agreement to disagree. :-)

Regards,
Tony

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


[prev in list] [next in list] [prev in thread] [next in thread]