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

[Tony Przygienda <[e-mail]>]

Hey 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.

Then I get you on the centralized story ;-)  But again, if you're willing
to restrict the graph then stuff like RIFT distributed solution is
implemented and works fine (yes, it took 2 scraps of the approach until
Pascal had the flash of intuition fueled by my-bad-ideas how to use MANET
concepts in a novel way with hashes). BTW implementation experience there
changed bunch of things on what's published in -02 due to interesting
effects, that will be put out in -03 ;-)

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 ...

Overall, I'm agnostic and watch how things will play out and what people
decide needs be done ...

>  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 ...


>
>
>
> > 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 ;-)

--- tony