Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Tony Przygienda <[e-mail]>]

On Fri, Aug 24, 2018 at 1:36 PM <[e-mail]> wrote:

>
> Tony,
>
> as to miscabling: yepp, the protocol has either to prevent adjacencies
> coming up or one has to deal with generic topologies. If you don't want to
> design miscabling prevention/topology ZTP into protocol (like ROLL or RIFT
> did) you have to deal with generic graph as you say. I think that if you
> have 99.99% of the time a predictable graph it's easier to restrict wrong
> cabling than deal with arbitrary topology when tackling this problem but
> that's my read.
>
>
>
> Well, you can take that approach, but you are at a risk of ignoring the
> one link that you needed to make the entire topology work better.  ;-)
>

yepp, no free lunch ... IME it's even more sublte. The more regular your
topology the more one can summarize & contain blast radius, the less, the
more topology information needs flooded to avoid blackholes, bow-ties to
the point where a generic topology (assuming prefix mobility) on the fabric
leaves one with host routes & scale limitation ...


> And if you don’t like the extra link problem, there’s also the missing
> link: what do you do when you have a leaf-spine topology, but there’s one
> link missing?  It’s not like you can ignore the missing link and flood on
> it anyway.  ;-)
>
>
that works just fine on -02 RIFT ...


>
> Another observation though would be that if you have a single mesh then
> centralized controller delay on failure becomes your delay bound how long
> flooding is disrupted possibly (unless your single covering graph has
> enough redundancy to deal with single llink failure, but then you're really
> having two as I suggest ;-). That could get ugly since you'll need
> make-before-break if installing a new mesh from controller me thinks with a
> round-trip from possibly a lot of nodes …
>
>
>
> Perhaps you didn’t understand the draft in detail.
>


>
> Even the loss of the area leader does not disrupt flooding.
>
> The flooding topology is in effect until a new area leader is elected and
> a new topology is distributed.  Yes, there is a hole in the flooding
> topology and you’re no longer bi-connected, but as long as it was still a
> single failure, you should still have a functioning flooding topology.  And
> because of that, it’s reasonable to assume that the area members can elect
> a new leader and switch to the new topology in an orderly fashion.
>
> It’s very true that there is a period where things are not bi-connected
> and a second failure will cause a flooding problem.  That period should be
> on the order of one failure detection, one flooding propagation, and one
> SPF computation.  If we expect failures to happen more frequently than
> that, then we need to call that out in our requirements. That type of
> scenario is perhaps reasonable under a MANET environment, but does not
> match any of my experience with typical data centers.
>
>
 Yes, I read the early versions, maybe missed some newer stuff, will read
newest and ponder more ... Though I think we're in sync ...



>
> >  iii) change in one of the vertex lifts
>>
>>
>> Sorry, I don’t understand point iii).
>>
>
> A mildly stuffed (or mathematically concise ;-) way to say that if you
> have one or two covering graphs (and vertex lift is the more precise word
> here since "covering graph" can be also an edge lift which is irrelevant
> here) and one of those subgraphs gets recomputed & distributed (due to
> failures, changes in some metrics, _whatever_) then this should not lead to
> disruption. Basically make-before-break as one possible design point,
> harder to achieve of course in distributed fashion …
>
>
>
> I think it would help the discussion if we phrased it less concisely. :-)
>

You know Aesop's fable on father, son & the donkey ? '-) I am normally
accused of excessive verbiage ;-) so that's somewhat of a compliment ;-)
But will take more care before introducing terms in the future.


>
>
> > moreover, I observe that IME ISIS is much more robust under such
>> optimizations since the CSNPs catch (@ a somehow ugly delay cost) any
>> corner cases whereas OSPF after IDBE will happily stay out of sync forever
>> if flooding skips something (that may actually become a reason to introduce
>> periodic stuff on OSPF to do CSNP equivalent albeit it won't be trivial in
>> backwards compatible way on my first thought, I was thinking a bit about
>> cut/snapshot consistency check [in practical terms OSPF hellos could carry
>> a checksum on the DB headers] but we never have that luxury on a link-state
>> routing protocol [i.e. we always operate under unbounded epsilon
>> consistency ;-) and in case of BGP stable oscialltions BTW not even that
>> ;^} ]).
>>
>> Emacs
>>
>>
> And that I cannot parse. Emacs? You want LISP code? But then, Dino may get
> offended ;-)
>
>
>
> Your comment seemed like just a poke in the perennial IS-IS vs. OSPF
> debate, which seems about as constructive as the Vi vs. Emacs debate.
>
>
ah, got you. Was not my intention, I dislike and like both protocol
equivalently, each has its warts [though if you look @ RIFT it's shameless
ISIS flooding rip-off ;-), that part IMO is somewhat better in ISIS] ;-)
But I thought I bring this angle into the thread since direct experience in
dealing with the problem of flood reduction taught me the ISIS
belts-suspender flooding can really save the bacon in such
algorithms/improvements. Unless we assume the algorithm will be perfect and
never loose anything, like never ever ... ;-)

e'one a good weekend ...

--- tony