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

[Robert Raszuk <[e-mail]>]

Tonys / Everyone,

> 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

Do we really need for DC use case to have flooding reduction standardized
for all three protocols ? ISIS, OSPFv2 & OSPFv3 ? Would just focusing on
ISIS not be sufficient ?

I am not sure if OSPF folks will feel offended or left behind if this work
proceeds for ISIS only - well at least for now till we get more experience
with the algorithm.

There is no shortage of protocols for MSDC use (M meaning Massive or
apparently Mid-size or even as reality shows Mini as well :)

Sure IGP flooding reduction can be useful beyond DCs, but do we have line
of people which are keen on trying this out outside of DC or DC like campus
environments ?

Thx,
R.

















On Fri, Aug 24, 2018 at 6:06 PM, Tony Przygienda <[e-mail]>
wrote:

> OK, good, real work. So from some scar tissue here's one question
>
> a) we are talking any kind of topology for the solution, i.e. generic
> graph?
>
> and then suggestion for IME realistic, operational MUST requirements
>
> b) req a): the solution should support distributed and centralized
> algorithm to compute/signal reduced mesh(es). I personally think
> distributed is the more practical choice for something like this but it's
> my 2c from having lived the telephony controller fashion, the distributed
> fashion and the controller fashion now again ;-)
> c) req b): the solution should include redundancy (i.e. @ least 2
> maximally disjoint vertex covers/lifts) to deal with single link failure
> (unless the link is unavoidably a minimal cut on the graph)
> d) req c): the solution should guarantee disruption free flooding in case
> of
>   i) single link failure
>  ii) single node failure
>  iii) change in one of the vertex lifts
> e) the solution should not lead to "hot-spot" or "minimal-cut" links which
> will disrupt flooding between two partitions on failure or lead to flood
> throughput bottlenecks
>
> I am agnostic to Tony L's thinking about diameter and so on. It makes
> sense but is not necessarily easy to pull into the solution.
>
> 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
> ;^} ]).
>
> --- tony
>
>
> On Fri, Aug 24, 2018 at 8:36 AM Acee Lindem (acee) <acee=
> [e-mail]> wrote:
>
>> Speaking as WG member:
>>
>> I agree on this and don't believe we need a separate document or a
>> protracted discussion.
>> Additionally, I don't think we should worry about anything going on in
>> other WGs.
>> Thanks,
>> Acee
>> P.S. I'll provide more input to the discussion as well. As luck would
>> have it, I initiated the discussion and then had a couple more pressing
>> matters (including the cable company's fiber installation contractor
>> messing up my irrigation system ;^(
>>
>> On 8/24/18, 11:04 AM, "Lsr on behalf of [e-mail]" <
>> [e-mail] on behalf of [e-mail]> wrote:
>>
>>
>>     So, going Old Skool here:
>>
>>     Since everyone agrees that this is a reasonable direction, how about
>> we have a real discussion on the list?
>>
>>     Requirement number 1 is straightforward: a significant reduction in
>> flooding overhead.
>>
>>     The basis for this requirement is the understanding that in a dense
>> topology, there is a great deal of redundancy due to flooding, and that it
>> is this redundancy that supersaturates the control plane.
>>
>>     Do we agree on this?
>>
>>     Tony
>>
>>     _______________________________________________
>>     Lsr mailing list
>>     [e-mail]
>>     https://www.ietf.org/mailman/listinfo/lsr
>>
>>
>> _______________________________________________
>> Lsr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
>