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

[[e-mail]]

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

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


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


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


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

Tony