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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 21 Aug 2018 22:18:53 +0000

Speaking as WG Co-Chair,

At IETF 102, there was no dearth of flooding reduction proposals.  In fact, we have so many proposals that there wasn’t agree as how to move forward and we agreed to discuss on the list. This Email is to initiate that discussion (which I intend to participate in but as a WG member).

Thanks,
Acee

---

From: Tony Li <[email-masked]>
Date: Wed, 22 Aug 2018 09:27:58 -0700

> At IETF 102, there was no dearth of flooding reduction proposals.  In fact, we have so many proposals that there wasn’t agree as how to move forward and we agreed to discuss on the list. This Email…

Hi Acee,

Perhaps a useful starting point of the discussion is to talk about requirements.  There seem to many different perceptions.

Regards,
Tony

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 22 Aug 2018 09:42:32 -0700

+1 Tony

We could start with a document, similar to dc-routing requirements one we did in RTGWG before chartering RIFT and LSVR.
Would help to disambiguate requirements from claims and have apple to apple comparison.
Doing it on github was a good experience.

Regards,
Jeff

> On Aug 22, 2018, at 09:27, Tony Li <[email-masked]> wrote:
> 
> 
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 22 Aug 2018 18:02:55 +0000

In the discussions which led to the creation of LSVR and RIFT WGs, considerable interest was expressed in working on enhancements to existing Link State protocols. You can peruse the dcrouting mailing list archives.

https://mailarchive.ietf.org/arch/browse/dcrouting/

It is rather befuddling to me that the IETF seems to have decided to move forward on two new protocols (no objection from me) but seems to feel there is insufficient reason to move forward on proposals to extend existing IGPs.
I think the suggestion that we need to write (yet another)  requirements document before doing so is a recipe for delay – not for progress.

Multiple drafts have been presented over the course of the past two years and discussed on the list as well.
In the case of two of the drafts:

draft-shen-isis-spine-leaf-ext
draft-li-dynamic-flooding

WG adoption was requested in Montreal.

Please explain why we cannot proceed with “business as usual” as regards these drafts.

   Les

From: Lsr <[email-masked]> On Behalf Of Jeff Tantsura
Sent: Wednesday, August 22, 2018 9:43 AM
To: Tony Li <[email-masked]>
Cc: [email-masked]; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

+1 Tony

Regards,
Jeff

On Aug 22, 2018, at 09:27, Tony Li <[email-masked]<mailto:[email-masked]>> wrote:

Hi Acee,

Regards,
Tony

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www..ietf.org/mailman/listinfo/lsr<https://www.ietf.org/mailman/listinfo/lsr>

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 22 Aug 2018 11:58:53 -0700

I do think it is a good idea in a sense to somehow outline WHAT problem is
being solved via some write-down or mind-melt

a) I hope it's captured in the meeting notes but otherwise running the
danger of repeating myself, the problem splits along the line of "directed
graphs" (basically lattices) which DC topologies are today and generic
graphs. In first case problem can be solved quite well (Pascal's idea based
loosely on MANET in RIFT that could be stretched to flat flooding as well),
in 2nd it's much harder.
b) Beside pure reduction, aspects like redundancy of the resulting
mesh(es), minimal-cut properties and load balancing aspects emerge from
practical pursuit of the problem (let's not even mention the dynamic
re-convergence problems no matter whether some centralized instance floods
or async distributed algorithm is run). Hence the scope or scopes of what
needs being done seems prudent.
c) ultimately, other things like link properties and resulting meshes play
a big role (MANET). In sparse networks we lived quite well without
reduction but MANET/DSR had to deal with it already AFAIR & IP fabric seem
to cause a different variation of the limitation to rear its head

2c

--- tony

On Wed, Aug 22, 2018 at 11:04 AM Les Ginsberg (ginsberg) <ginsberg=
[email-masked]> wrote:

> In the discussions which led to the creation of LSVR and RIFT WGs,
> considerable interest was expressed in working on enhancements to existing
> Link State protocols. You can peruse the dcrouting mailing list archives.
>
>
>
> It is rather befuddling to me that the IETF seems to have decided to move
> forward on two new protocols (no objection from me) but seems to feel there
> is insufficient reason to move forward on proposals to extend existing IGPs.
>
> I think the suggestion that we need to write (yet another)  requirements
> document before doing so is a recipe for delay – not for progress.
>
>
>
> *From:* Lsr <[email-masked]> *On Behalf Of *Jeff Tantsura
> *Sent:* Wednesday, August 22, 2018 9:43 AM
> *To:* Tony Li <[email-masked]>
> *Cc:* [email-masked]; Acee Lindem (acee) <acee=[email-masked]>
> *Subject:* Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward
>
>
>
> +1 Tony
>
>
>
> We could start with a document, similar to dc-routing requirements one we
> did in RTGWG before chartering RIFT and LSVR.
>
> At IETF 102, there was no dearth of flooding reduction proposals.  In
> fact, we have so many proposals that there wasn’t agree as how to move
> forward and we agreed to discuss on the list. This Email is to initiate
> that discussion (which I intend to participate in but as a WG member).
>
>
>
>
>
> Hi Acee,
>
>
>
> Perhaps a useful starting point of the discussion is to talk about
> requirements.  There seem to many different perceptions.
>
>
>
> Regards,
>
> Tony
>
>
>
>
>
> https://www..ietf.org/mailman/listinfo/lsr
> <https://www.ietf.org/mailman/listinfo/lsr>
>

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Wed, 22 Aug 2018 19:19:01 +0000

I do think to solve all the data centers (massive or small) requirement,
this discussion is very useful. If we can list all the requirements and see
what technical approaches we can do to achieve them.

But incremental improvements on existing protocols is useful also. They may not
solve the complete set of “requirements”, but they do help data center
and also non-data center deployments to improve their operations.

I would think this group can proceed with both approaches.

Regards,
- Naiming

On Aug 22, 2018, at 11:02 AM, Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:ginsberg=[email-masked]>> wrote:

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Jeff Tantsura
Sent: Wednesday, August 22, 2018 9:43 AM
To: Tony Li <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Acee Lindem (acee) <acee=[email-masked]<mailto:acee=[email-masked]>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

+1 Tony

Regards,
Jeff

Hi Acee,

Regards,
Tony

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 22 Aug 2018 20:09:16 +0000

It is better to have some short discussions about the requirements. Some requirements were presented and discussed in RTGWG. With some new additions and discussions , we should have a good set of requirements.

Best Regards,
Huaimo
From: Lsr [mailto:[email-masked]] On Behalf Of Naiming Shen (naiming)
Sent: Wednesday, August 22, 2018 3:19 PM
To: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>
Cc: [email-masked]; Jeff Tantsura <[email-masked]>; Tony Li <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Regards,
- Naiming

   Les

+1 Tony

Regards,
Jeff

Hi Acee,

Regards,
Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 22 Aug 2018 20:09:58 +0000

Tony –

The points you make below are good and need to be considered.

But let’s examine what work we have that we could do now.

1)draft-li-dynamic-flooding

This defines modest protocol extensions to support use of flooding reduction algorithms in  any type of topology. Note that it does not (not yet anyway…) specify any algorithms.
Adopting this draft would allow us to define the extensions necessary to enable the use of alternate algorithms and to get immediate benefits from the use of some well known algorithms. Since it does not preclude (and is a necessary infra for)  the use of any algorithm, and it allows support for many algorithms (NOT simultaneously though ☺ ) it does not prevent any future algorithmic solutions from being used.

In parallel with this, discussion/research of points such as you mention below can be done, but I do not see why we should not proceed with this work immediately.

2)Flooding reduction drafts specific to Clos topologies

There are multiple candidates – and I am obviously biased since I have a horse in the race (draft-shen-isis-spine-leaf-ext),  but the point is we have proposals that have practical benefits and have received support. So long as they are compatible with draft-li-dynamic-flooding I again do not see why these cannot move forward now.

Further research/discussion is a fine thing, but that should not prevent us from realizing real benefits now – especially since we can do so in a way that is future-proofed.

   Les

From: Tony Przygienda <[email-masked]>
Sent: Wednesday, August 22, 2018 11:59 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Jeff Tantsura <[email-masked]>; Tony Li <[email-masked]>; [email-masked]; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

I do think it is a good idea in a sense to somehow outline WHAT problem is being solved via some write-down or mind-melt

a) I hope it's captured in the meeting notes but otherwise running the danger of repeating myself, the problem splits along the line of "directed graphs" (basically lattices) which DC topologies are today and generic graphs. In first case problem can be solved quite well (Pascal's idea based loosely on MANET in RIFT that could be stretched to flat flooding as well), in 2nd it's much harder.
b) Beside pure reduction, aspects like redundancy of the resulting mesh(es), minimal-cut properties and load balancing aspects emerge from practical pursuit of the problem (let's not even mention the dynamic re-convergence problems no matter whether some centralized instance floods or async distributed algorithm is run). Hence the scope or scopes of what needs being done seems prudent.
c) ultimately, other things like link properties and resulting meshes play a big role (MANET). In sparse networks we lived quite well without reduction but MANET/DSR had to deal with it already AFAIR & IP fabric seem to cause a different variation of the limitation to rear its head

2c

--- tony

On Wed, Aug 22, 2018 at 11:04 AM Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>> wrote:
In the discussions which led to the creation of LSVR and RIFT WGs, considerable interest was expressed in working on enhancements to existing Link State protocols. You can peruse the dcrouting mailing list archives.

WG adoption was requested in Montreal..

   Les

Cc: [email-masked]<mailto:[email-masked]>; Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>>

+1 Tony

Regards,
Jeff

Hi Acee,

Perhaps a useful starting point of the discussion is to talk about requirements.  There seem to many different perceptions..

Regards,
Tony

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 22 Aug 2018 13:20:45 -0700

Les,

Not going to repeat Tony P. points, however I don’t think anyone said – requirement document should be a gating factor,  personally, I’d do it same way we did in RTGWG – to have a unbiased reference point others can reference to. Development of such document should go in parallel with other work and be a wg/design team effort. 

Hope this clarifies.

Cheers,

Jeff

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wednesday, August 22, 2018 at 13:10
To: Tony Przygienda <[email-masked]>
Cc: Jeff Tantsura <[email-masked]>, Tony Li <[email-masked]>, "[email-masked]" <[email-masked]>, "Acee Lindem (acee)" <[email-masked]>
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Tony –

Adopting this draft would allow us to define the extensions necessary to enable the use of alternate algorithms and to get immediate benefits from the use of some well known algorithms. Since it does not preclude (and is a necessary infra for)  the use of any algorithm, and it allows support for many algorithms (NOT simultaneously though J ) it does not prevent any future algorithmic solutions from being used.

   Les

2c

--- tony 

On Wed, Aug 22, 2018 at 11:04 AM Les Ginsberg (ginsberg) <ginsberg=[email-masked]> wrote:

 

   Les

+1 Tony

Regards,

Jeff

 

 

Hi Acee,

Regards,

Tony

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 22 Aug 2018 13:23:42 -0700

Naiming,

That’s would be the goal, not to boil the ocean (again)the constrain part would be “improvements on existing protocols”, since we are in LSR, perhaps further scoped to ISIS/OSPF.

Cheers,

Jeff

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Wednesday, August 22, 2018 at 12:19
To: "Les Ginsberg (ginsberg)" <ginsberg=[email-masked]>
Cc: Jeff Tantsura <[email-masked]>, Tony Li <[email-masked]>, "[email-masked]" <[email-masked]>, "Acee Lindem (acee)" <acee=[email-masked]>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Regards,

- Naiming

On Aug 22, 2018, at 11:02 AM, Les Ginsberg (ginsberg) <ginsberg=[email-masked]> wrote:

 

   Les

+1 Tony

Regards,

Jeff

 

Hi Acee,

Regards,

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 22 Aug 2018 21:26:24 +0000

Works for me.

Thanx Jeff.

    Les

From: Jeff Tantsura <[email-masked]>
Sent: Wednesday, August 22, 2018 1:21 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; Tony Przygienda <[email-masked]>
Cc: Tony Li <[email-masked]>; [email-masked]; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Les,

Hope this clarifies.

Cheers,
Jeff

From: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 22, 2018 at 13:10
To: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Cc: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, Tony Li <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Acee Lindem (acee)" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Tony –

   Les

From: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, August 22, 2018 11:59 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2c

--- tony

   Les

+1 Tony

Regards,
Jeff

Hi Acee,

Regards,
Tony

---

From: Dean cheng <[email-masked]>
Date: Thu, 23 Aug 2018 00:22:08 +0000

This two-approach approach makes sense, since it tends to provide a solution
in a short term but also lay out a foundation for the relatively-long term. And
hopefully some elements deployed in the short term can be leveraged and
further tuned for the long term solution.

Dean

From: Lsr [mailto:[email-masked]] On Behalf Of Naiming Shen (naiming)
Sent: Wednesday, August 22, 2018 12:19 PM
To: Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:ginsberg=[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <acee=[email-masked]<mailto:acee=[email-masked]>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Regards,
- Naiming

   Les

+1 Tony

Regards,
Jeff

Hi Acee,

Regards,
Tony

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Thu, 23 Aug 2018 00:42:00 +0000

Agreed. Also for the relatively-long term solution, I doubt there is
an one-size-fits-all solution. We need to have enough building blocks
in protocols and any data center design/operation can utilize with
to achieve their operational goal.

Regards,
- Naiming

On Aug 22, 2018, at 5:22 PM, Dean cheng <[email-masked]<mailto:[email-masked]>> wrote:

Dean

Regards,
- Naiming

   Les

+1 Tony

Regards,
Jeff

Hi Acee,

Regards,
Tony

---

From: Dean cheng <[email-masked]>
Date: Thu, 23 Aug 2018 01:49:51 +0000

Yes – there are improvements desired (e.g., flooding reduction)
for DC environment but also beneficial in general; but there may
require scenario specific solutions (optional & pluggable?).
Dean

From: Naiming Shen (naiming) [mailto:[email-masked]]
Sent: Wednesday, August 22, 2018 5:42 PM
To: Dean cheng <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]; Jeff Tantsura <[email-masked]>; Tony Li <[email-masked]>; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Regards,
- Naiming

Dean

Regards,
- Naiming

   Les

+1 Tony

Regards,
Jeff

Hi Acee,

Regards,
Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 22 Aug 2018 20:11:38 -0700

> On Aug 22, 2018, at 1:09 PM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 

Just to set expectations: The current mechanism has the flexibility to select one of a number of different distributed algorithms.  If and when someone does decide to publish one such algorithm, I would fully expect it to be a separate document.

Tony

---

From: Peter Psenak <[email-masked]>
Date: Thu, 23 Aug 2018 11:05:33 +0200

Jeff, All,

we have added many extensions to IGP protocols over the years. Many 
times multiple solutions were proposed for the same or similar problem 
and WG picked from the set, many times multiple solutions were merged or 
combined together. We never asked for a requirement document. Even for 
more significant changes then we are talking about here.

I understand that the area of DC routing using IGPs is a broader area, 
but it does not fundamentally change IGPs to warrant the need for 
requirement document as a prerequisite to move forward with any work 
that is related to any optimization that may be applicable to DC 
environment.

So while I'm not against the existence of the document that would cover 
the requirements for IGPs in DC environments , I don't believe we should 
gate all proposed work in this space by such a document. And to be 
completely honest, the requirements are pretty straightforward for 
anyone that is familiar with the protocols' operation.

my 2c,
Peter

On 22/08/18 18:42 , Jeff Tantsura wrote:
> +1 Tony
>
> We could start with a document, similar to dc-routing requirements one
> we did in RTGWG before chartering RIFT and LSVR.
>>> fact, we have so many proposals that there wasn’t agree as how to
>>> move forward and we agreed to discuss on the list. This Email is to
>>> initiate that discussion (which I intend to participate in but as a
>>> WG member).
>>
>>
>> Hi Acee,
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 23 Aug 2018 08:02:09 -0700

On Thu, Aug 23, 2018 at 2:05 AM Peter Psenak <ppsenak=
[email-masked]> wrote:

> ...
>   And to be
The signalling is quite simple as often the case, good quality algorithms,
especially distributed versions, anything but IME ...

--- tony

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 23 Aug 2018 20:15:37 +0000

Hi Tony,

    Regarding to the issues/problems you mentioned for flooding reduction (using distributed algorithm), can you give some more details?

Best Regards,
Huaimo
From: Lsr [mailto:[email-masked]] On Behalf Of Tony Przygienda
Sent: Wednesday, August 22, 2018 2:59 PM
To: ginsberg=[email-masked]
Cc: [email-masked]; Jeff Tantsura <[email-masked]>; Tony Li <[email-masked]>; acee=[email-masked]
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2c

--- tony

   Les

+1 Tony

Regards,
Jeff

Hi Acee,

Regards,
Tony

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 23 Aug 2018 15:59:58 -0700

Peter,

As previously stated - I'm against gating, it should be developed in parallel and with cooperation with the ongoing/existing work.
Note - there's a document (albeit expired, it played its role) that talks about generic DC Routing requirements, work in LSR would be scooped to LSR only.
So no going into religious discussions - new vs old/ls vs pv, etc, but focusing on ospf/isis and what is needed for DC specifically.
I think it would be good to do some gain/complexity mental exercise...  

Cheers,
Jeff

On 8/23/18, 02:05, "Peter Psenak" <[email-masked]> wrote:

    Jeff, All,

    
    
    my 2c,
    Peter

---

From: Peter Psenak <[email-masked]>
Date: Fri, 24 Aug 2018 11:06:59 +0200

Hi Jeff,

> I think it would be good to do some gain/complexity mental exercise...

fair enough. I'm willing to contribute.

thanks,
Peter

> .

---

From: [email-masked]
Date: Fri, 24 Aug 2018 08:03:41 -0700

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 24 Aug 2018 15:35:52 +0000

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 [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    

    Do we agree on this?
    
    Tony

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 24 Aug 2018 09:06:58 -0700

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=
[email-masked]> wrote:

> 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 [email-masked]" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>     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
>

---

From: Peter Psenak <[email-masked]>
Date: Fri, 24 Aug 2018 18:09:06 +0200

Hi Tony,

> 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 pla…

absolutely.

I would add that the flooding reduction should not add significant delay 
to the flooding time compared to the regular flooding case.

thanks,
Peter

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 24 Aug 2018 16:17:08 +0000

Building on what Tony L and Peter have already stated:

R1: Significant reduction in flooding overhead.

R2: Flooding reduction should not add significant delay to the flooding time

R3: Reliability of flooding MUST be maintained

   Les

> -----Original Message-----
> From: Lsr <[email-masked]> On Behalf Of Peter Psenak
> Sent: Friday, August 24, 2018 9:09 AM
> To: [email-masked]
> Cc: [email-masked]; Jeff Tantsura <[email-masked]>; Acee Lindem
> (acee) <acee=[email-masked]>
> 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?
> 
> absolutely.
> 
> I would add that the flooding reduction should not add significant delay to
> the flooding time compared to the regular flooding case.
> 
> thanks,
> Peter
> 
> >
> > Tony
> >
> > .
> >
>

---

From: [email-masked]
Date: Fri, 24 Aug 2018 09:29:02 -0700

> a) we are talking any kind of topology for the solution, i.e. generic graph? 

Well, the problem with a topology restriction is that mistakes happen.  If we have a solution for a pure bipartite graph (i.e., a leaf-spine topology) and someone mistakenly inserts a leaf to leaf link, what happens?  Having the entire DC implode would be a Bad Thing, IMHO.

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

Well, I did think long and hard about this.

Being distributed would be very nice.  However, that implies that all nodes are going to get to the exact same solution. Which implies that they all must execute the same algorithm, presumably with the same inputs.

That’s all well and good, but we don’t have an algorithm to really put on the table yet.  We need experience with one.  We know we want to tweak things based on biconnectivity, performance, and degree because doing it right day one seems unlikely.  Changing algorithms is going to be VERY painful if it’s distributed.  

However, if it’s centralized, it’s completely trivial.

So, my strong preference is to start centralized.  Iterate on the algorithm until we have it where we want it.  And then take it distributed if there’s a point to it.  However, at that point, we have something working.  So why fix it?

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

Not everyone agrees with this, but some do.  This seems like one possible input to the algorithm.

> d) req c): the solution should guarantee disruption free flooding in case of 
>   i) single link failure
>  ii) single node failure

Sorry, I don’t understand point iii).

> 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 

Agreed.

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

It all boils down to the point that Peter just made about performance.  A topology with a high diameter is going to require many flooding hops and hurt performance.  To be avoided...

> 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

Tony

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 24 Aug 2018 09:55:23 -0700

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

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

> consistency ;-) and in case of BGP stable oscialltions BTW not even that
And that I cannot parse. Emacs? You want LISP code? But then, Dino may get
offended ;-)

--- tony

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 24 Aug 2018 17:33:23 +0000

I think distributed is more practical too. 
For computing routes, we have been using distributed SPF on every node for many years.
In fact, we may not need to run the exact algorithm on every node. As long as the algorithms running on different nodes generate the same result, that would work. 

Best Regards,
Huaimo
-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, August 24, 2018 12:29 PM
To: Tony Przygienda <[email-masked]>
Cc: [email-masked]; Jeff Tantsura <[email-masked]>; Peter Psenak <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Agreed.

Emacs

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 24 Aug 2018 19:36:26 +0200

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 <[email-masked]>
wrote:

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

---

From: John E Drake <[email-masked]>
Date: Fri, 24 Aug 2018 18:58:31 +0000

Les,

I think that Tony's draft already has a pretty good set of requirements:  https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-3

Yours Irrespectively,

John

> From: Lsr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
> Sent: Friday, August 24, 2018 12:17 PM
> To: Peter Psenak <ppsenak=[email-masked]>; [email-masked]
> > > Since everyone agrees that this is a reasonable direction, how about
> > > we
> > have a real discussion on the list?
> > >
> > 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?
> >
> > absolutely.
> >
> > I would add that the flooding reduction should not add significant
> > delay to the flooding time compared to the regular flooding case.
> >
> > thanks,
> > Peter
> >
> > >
> > > Tony
> > >
> > > .
> > >
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_lsr&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoC
> > I&r=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE&m=ksaqjl1oSFzKbtFY0O-H
> >
> pMKmAew2h7RmW26uh_BWPrI&s=oGOlkQBdmIFrb8WdCaV7eez4KrIYUjN4
> D08UMlzOPcU&
> > e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_lsr&d=DwICAg&c=HAkYuh63rsuhr6Scbf
> h0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE&m=ksaqjl1oSFzKbtFY0O-
> HpMKmAew2h7RmW26uh_BWPrI&s=oGOlkQBdmIFrb8WdCaV7eez4KrIYUjN
> 4D08UMlzOPcU&e=

---

From: [email-masked]
Date: Fri, 24 Aug 2018 13:16:09 -0700

> On Aug 24, 2018, at 10:36 AM, Robert Raszuk <[email-masked]> wrote:
> 
> 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 ? 

Eventually, yes.  It’s clear that we’re not going to get people to change their IGP just for this.  So, in the spirit of glasnost, why not fix ‘em all at once?

Tony

---

From: [email-masked]
Date: Fri, 24 Aug 2018 13:20:39 -0700

> I think distributed is more practical too. 

I would appreciate more detailed insights as to why you (and others) feel this way.  It is not at all obvious to me.

> For computing routes, we have been using distributed SPF on every node for many years.

True, but that algorithm is (and was) very well known and a fixed algorithm that would clearly solve the problem at the time. If we were in a similar situation, where we were ready to set an algorithm in concrete, I might well agree, but it’s quite clear that we are NOT at that point yet.  We will need to experiment and modify algorithms, and as discussed, that’s easier with a centralized approach.

> In fact, we may not need to run the exact algorithm on every node. As long as the algorithms running on different nodes generate the same result, that would work. 

Insuring a globally consistent result without running the exact same algorithm on the exact same data will be quite a trick.  Debugging distributed problems at scale is already a hard problem.  Having different algorithms in different locations would add another order of magnitude in difficulty.  No thank you.

Tony

---

From: [email-masked]
Date: Fri, 24 Aug 2018 13:36:07 -0700

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.

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

> 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

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 24 Aug 2018 14:25:22 -0700

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

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

> round-trip from possibly a lot of nodes …
>
>
>

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

> 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
> harder to achieve of course in distributed fashion …
>
>
>

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.

> 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

---

From: Christian Hopps <[email-masked]>
Date: Mon, 27 Aug 2018 08:10:34 -0400

> On Aug 24, 2018, at 12:29 PM, [email-masked] wrote:
> 

I find this reasoning quite compelling.

Thanks,
Chris.

---

From: Peter Psenak <[email-masked]>
Date: Mon, 27 Aug 2018 14:22:09 +0200

Chris and All,

> I find this reasoning quite compelling.

I would leave the door open for both and not limit the solution to one 
or the other.

As an example, draft-li-dynamic-flooding-05 supports both centralized 
and distributed mode of operation.

thanks,
Peter

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 27 Aug 2018 14:23:54 +0000

Hi Chris, Peter and Everyone,

>From: Lsr [mailto:[email-masked]] On Behalf Of Peter Psenak
>Sent: Monday, August 27, 2018 8:22 AM
>To: Christian Hopps <[email-masked]>; Tony Li <[email-masked]>
>Cc: [email-masked]; Jeff Tantsura <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; Tony Przygienda <[email-masked]>
>Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward>
>
>Chris and All,
>
>>> Being distributed would be very nice.  However, that implies that all nodes are going to get to the exact same solution. Which implies that they all must execute the same algorithm, presumably with >the same inputs.
>>>
>I would leave the door open for both and not limit the solution to one or the other.
>
>As an example, draft-li-dynamic-flooding-05 supports both centralized and distributed mode of operation.
>

draft-cc-ospf-flooding-reduction-02 supports operations on three modes including distributed mode and centralized one. 

Best Regards,
Huaimo

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 27 Aug 2018 15:10:49 +0000

>I would appreciate more detailed insights as to why you (and others) feel this way.  It is not at all obvious to me.
IGP is distributed in nature. The distributed computation of flooding topology like distributed SPF will keep IGP still distributed in nature. Introducing centralized feature into IGP will break IGP's distributed nature, which may cause some issues/problems. 

>True, but that algorithm is (and was) very well known and a fixed algorithm that would clearly solve the problem at the time. If we were in a similar situation, where we were ready to set an algorithm in >concrete, I might well agree, but it’s quite clear that we are NOT at that point yet.  We will need to experiment and modify algorithms, and as discussed, that’s easier with a centralized approach.
After flooding reduction is deployed in an operational (ISP) network, will we be allowed to do experiments on their network? 
After an algorithm is determined/selected, will it be changed to another algorithm in a short time? 

>Insuring a globally consistent result without running the exact same algorithm on the exact same data will be quite a trick.  Debugging distributed problems at scale is already a hard problem.  Having >different algorithms in different locations would add another order of magnitude in difficulty.  No thank you.
In some existing networks, some nodes run IGPs from one vendor, some other nodes run IGPs from another vendor, and so on. Some may use normal SPF, some others may use incremental SPF. It seems that we have had these cases for many years. 

Best Regards,
Huaimo

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 27 Aug 2018 15:30:37 +0000

Huaimo -

> draft-cc-ospf-flooding-reduction-02 supports operations on three modes
> including distributed mode and centralized one.
> 
[Les:] The "third mode" mentioned in your draft is "static" which was defined many years ago in RFC 2973 (Mesh Groups).
More importantly I think it is dynamic solutions that are of interest in this discussion.

It is absolutely fair to discuss ideas from various drafts, but the suggestion that "3 is better than 2" I think is very misleading in this case.

   Les

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 27 Aug 2018 17:30:57 +0200

Hi Huaimo,

> Introducing centralized feature into IGP will break IGP's distributed
nature

That clearly proves that word "centralized" has been significantly
overloaded here.  To many indeed "centralized" means a controller (like
OpenFlow or SDN) and that such device added to a network is to push
information - typically 1RU linux blade -  here optimized flooding graph.
But this never was the plan with this proposal from its start ie. -00
version.

Centralized means that optimized flooding graph comes from single redundant
node.

Leader election happens automatically and procedures for that are to be
vastly similar to today's DR or DIS election. So with this in mind one may
observe that both OSPF and ISIS are pretty centralized on multiaccess
networks today :)

To your point of multi-vendor networks true - and that is precisely why
upgrade network wide to a release containing consistent algorithm from more
then a single vendor (and even for single vendor) is practically a very
time consuming and difficult process.

Btw I don't think there is any problem here ... The text added to -05
version allows very seamless choice of centralized vs distributed topology
computation by signalling either zero or non zero value in the added to
version -05 area leader sub-tlv.

In other words I don't see any problem or room for debate .. adopting and
implementing -05 allows use of centralized or distributed optimal flooding
computation at the operator's discretion.

Thx,
R.

On Mon, Aug 27, 2018 at 5:10 PM, Huaimo Chen <[email-masked]> wrote:

> >I would appreciate more detailed insights as to why you (and others) feel
> this way.  It is not at all obvious to me.
> IGP is distributed in nature. The distributed computation of flooding
> topology like distributed SPF will keep IGP still distributed in nature.
> Introducing centralized feature into IGP will break IGP's distributed
> nature, which may cause some issues/problems.
>
> >True, but that algorithm is (and was) very well known and a fixed
> algorithm that would clearly solve the problem at the time. If we were in a
> similar situation, where we were ready to set an algorithm in >concrete, I
> might well agree, but it’s quite clear that we are NOT at that point yet.
> We will need to experiment and modify algorithms, and as discussed, that’s
> easier with a centralized approach.
> After flooding reduction is deployed in an operational (ISP) network, will
> we be allowed to do experiments on their network?
> >> In fact, we may not need to run the exact algorithm on every node. As
> long as the algorithms running on different nodes generate the same result,
> that would work.
> >Insuring a globally consistent result without running the exact same
> algorithm on the exact same data will be quite a trick.  Debugging
> distributed problems at scale is already a hard problem.  Having >different
> algorithms in different locations would add another order of magnitude in
> difficulty.  No thank you.
> In some existing networks, some nodes run IGPs from one vendor, some other
> nodes run IGPs from another vendor, and so on. Some may use normal SPF,
> some others may use incremental SPF. It seems that we have had these cases
> for many years.
> >Tony
>
> Best Regards,
> Huaimo

---

From: [email-masked]
Date: Mon, 27 Aug 2018 08:53:51 -0700

Hi Huaimo,

> After flooding reduction is deployed in an operational (ISP) network, will we be allowed to do experiments on their network? 

Some may well permit it.  Certainly in lab scenarios they may be very willing.  It all depends on their motivation to achieve improvements.

It should be remembered that we are where we are today because some people were willing to work towards better technology and understood that there would be issues while we worked out issues with implementations. All protocols, features, and implementations have growing pains. We are where we are because we work through them.

> After an algorithm is determined/selected, will it be changed to another algorithm in a short time? 

Possibly. Someone may have an insight that produces theoretical breakthrough and gives us a completely different algorithm. Or, more likely, someone discovers a catastrophic bug in an algorithm and moves to fix it.

> In some existing networks, some nodes run IGPs from one vendor, some other nodes run IGPs from another vendor, and so on. Some may use normal SPF, some others may use incremental SPF. It seems that…

I’m unaware of anyone trying to get EIGRP to interoperate with IS-IS at the protocol level.  ;-)

I’m also unaware of anyone trying to implement anything other than SPF.

And that’s what I think you’re proposing…

Tony

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 27 Aug 2018 16:41:44 +0000

Hi Robert,

>Leader election happens automatically and procedures for that are to be vastly similar to today's DR or DIS election. So with this in mind one may observe that both OSPF and ISIS are pretty centralized on multiaccess networks today :)

Today’s DR or DIS election is local to a special interface/network such as a broadcast interface. Leader election in a network is global. Every node in the network depends on it (its flooding topology). These two seems different.

>Btw I don't think there is any problem here ... The text added to -05 version allows very seamless choice of centralized vs distributed topology computation by signalling either zero or non zero value in the added to version -05 area leader sub-tlv.
>
>In other words I don't see any problem or room for debate .. adopting and implementing -05 allows use of centralized or distributed optimal flooding computation at the operator's discretion.

draft-cc-ospf-flooding-reduction-02 allows operators to select distributed mode, centralized one or static one smoothly.

Best Regards,
Huaimo

From: Robert Raszuk [mailto:[email-masked]]
Sent: Monday, August 27, 2018 11:31 AM
To: Huaimo Chen <[email-masked]>
Cc: [email-masked]; [email-masked]; Jeff Tantsura <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; Peter Psenak <[email-masked]>; Tony Przygienda <[email-masked]>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi Huaimo,

> Introducing centralized feature into IGP will break IGP's distributed nature

That clearly proves that word "centralized" has been significantly overloaded here.  To many indeed "centralized" means a controller (like OpenFlow or SDN) and that such device added to a network is to push information - typically 1RU linux blade -  here optimized flooding graph. But this never was the plan with this proposal from its start ie. -00 version.

Centralized means that optimized flooding graph comes from single redundant node.

Leader election happens automatically and procedures for that are to be vastly similar to today's DR or DIS election. So with this in mind one may observe that both OSPF and ISIS are pretty centralized on multiaccess networks today :)

To your point of multi-vendor networks true - and that is precisely why upgrade network wide to a release containing consistent algorithm from more then a single vendor (and even for single vendor) is practically a very time consuming and difficult process.

Btw I don't think there is any problem here ... The text added to -05 version allows very seamless choice of centralized vs distributed topology computation by signalling either zero or non zero value in the added to version -05 area leader sub-tlv.

In other words I don't see any problem or room for debate .. adopting and implementing -05 allows use of centralized or distributed optimal flooding computation at the operator's discretion.

Thx,
R.

Best Regards,
Huaimo

---

From: [email-masked]
Date: Mon, 27 Aug 2018 09:50:12 -0700

> Today’s DR or DIS election is local to a special interface/network such as a broadcast interface. Leader election in a network is global. Every node in the network depends on it (its flooding topol…

Hmm….  Ethernet is not ‘special’.   Pretty much all that we have today.  :-)

If DR/DIS election fails, then there’s likely to be a failure in flooding.  Anything transiting that network is likely to be mis-routed. Seems not very different to me.  The phone will ring regardless.

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 27 Aug 2018 18:56:31 +0200

> draft-cc-ospf-flooding-reduction-02 allows operators to select
distributed mode, centralized one or static one smoothly.

Aside from static approach can you summarize in purely technical points
advantages your draft proposes over draft-li-dynamic-flooding-05 ?

Many thx,
R.

On Mon, Aug 27, 2018 at 6:41 PM, Huaimo Chen <[email-masked]> wrote:

> Today’s DR or DIS election is local to a special interface/network such as
> a broadcast interface. Leader election in a network is global. Every node
> in the network depends on it (its flooding topology). These two seems
> different.
>
>
>
> draft-cc-ospf-flooding-reduction-02 allows operators to select
> distributed mode, centralized one or static one smoothly.
>
>
>
> Best Regards,
>
> Huaimo
>
>
>
> *From:* Robert Raszuk [mailto:[email-masked]]
> *Sent:* Monday, August 27, 2018 11:31 AM
> *To:* Huaimo Chen <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; Jeff Tantsura <
> [email-masked]>; Acee Lindem (acee) <acee=[email-masked].
> org>; Peter Psenak <[email-masked]>; Tony Przygienda <
> [email-masked]>

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 27 Aug 2018 10:19:13 -0700

> in the network depends on it (its flooding topology). These two seems

so it's party like it's 1999, seems the peer group leader election gets
rediscovered ;-)  Interesting old new problems, interesting old new attack
vectors like https://ieeexplore.ieee.org/document/822780/

---- tony

---

From: [email-masked]
Date: Mon, 27 Aug 2018 14:44:21 -0700

> so it's party like it's 1999, seems the peer group leader election gets rediscovered ;-)  Interesting old new problems, interesting old new attack vectors like https://ieeexplore.ieee.org/document/822780/ <https://ieeexplore.ieee.org/document/822780/>

No argument there.  There are no new problems or solutions.  Just us rediscovering the problems and approaches that others have used before.

That said, the solutions still need to be applied.  That is, after all, engineering.

Preferably in a Little Red Corvette.

Tony

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 28 Aug 2018 17:14:14 +0800

Hi, Robert:

As stated in https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-6.3, the mentioned distributed mode is actually centrally mode. It depends on the area leader to advertise the algorithms.

The ideal distributed mode is depending only the action/calculation from each individual node as done in current SPF calculation. No leader election process within whole area scope.

Can we focus on finding one common algorithms that can deducing the optimized flooding topology based on the initial synchronized LSDB for further LSA flooding reduction?

Best Regards.

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

发件人: Robert Raszuk [mailto:[email-masked]] 
发送时间: 2018年8月28日 0:57
收件人: Huaimo Chen
抄送: [email-masked]; Acee Lindem (acee); [email-masked]; Jeff Tantsura; Tony Przygienda; Peter Psenak
主题: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

> draft-cc-ospf-flooding-reduction-02 allows operators to select distributed mode, centralized one or static one smoothly. 

Aside from static approach can you summarize in purely technical points advantages your draft proposes over draft-li-dynamic-flooding-05 ? 

Many thx,

R.

Hi Robert,

>Btw I don't think there is any problem here .... The text added to -05 version allows very seamless choice of centralized vs distributed topology computation by signalling either zero or non zero value in the added to version -05 area leader sub-tlv. 

Best Regards,

Huaimo

Hi Huaimo,

Thx,

R.

Best Regards,
Huaimo

---

From: Peter Psenak <[email-masked]>
Date: Tue, 28 Aug 2018 11:36:51 +0200

Aijun,

On 28/08/18 11:14 , Aijun Wang wrote:
> Hi, Robert:
>
> As stated in
> https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-6.3,
> the mentioned distributed mode is actually centrally mode. It depends on
> the area leader to advertise the algorithms.

above is not correct. draft-li-dynamic-flooding supports both 
centralized and distributed modes of operation. All routers in the area 
though MUST agree on which mode they operate in and if they operate in 
distributed mode, which algorithm is used to compute the flooding topology.

>
> The ideal distributed mode is depending only the action/calculation from
> each individual node as done in current SPF calculation. No leader
> election process within whole area scope.

please see above.

>
> Can we focus on finding one common algorithms that can deducing the
> optimized flooding topology based on the initial synchronized LSDB for
> further LSA flooding reduction?

one algorithm may not fit all environments and all users. Having at 
least one standardized algorithm is definitely a goal, but I see  no 
reason to limit ourselves to single one in long run. The framework in
draft-li-dynamic-flooding does give us all the flexibility. And the 
leader election is quite simple mechanism to achieve consistency and 
maintain the flexibility of the solution.

thanks,
Peter

> *发件人:*Robert Raszuk [mailto:[email-masked]]
> *发送时间:*2018年8月28日0:57
> *收件人:*Huaimo Chen
> *抄送:[email-masked]; Acee Lindem (acee); [email-masked]; Jeff Tantsura;
> Tony Przygienda; Peter Psenak
> *主题:*Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward
>
> advantages your draft proposes over draft-li-dynamic-flooding-05?
>
> Many thx,
>
> R.
>
> On Mon, Aug 27, 2018 at 6:41 PM, Huaimo Chen <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Hi Robert,
>
> Today’s DR or DIS election is local to a special interface/network such
> as a broadcast interface. Leader election in a network is global. Every
> node in the network depends on it (its flooding topology). These two
> seems different.
>
> *From:*Robert Raszuk [mailto:[email-masked] <mailto:[email-masked]>]
> *To:* Huaimo Chen <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; Jeff Tantsura <[email-masked]
> <mailto:[email-masked]>>; Acee Lindem (acee)
> <acee=[email-masked] <mailto:[email-masked]>>;
> Peter Psenak <[email-masked] <mailto:[email-masked]>>; Tony
> Przygienda <[email-masked] <mailto:[email-masked]>>
> information - typically 1RU linux blade -  here optimized flooding
> graph. But this never was the plan with this proposal from its start ie.
> -00 version.
>
> vastly similar to today's DR or DIS election. So with this in mind one
> may observe that both OSPF and ISIS are pretty centralized on
> multiaccess networks today :)
>
> upgrade network wide to a release containing consistent algorithm from
> more then a single vendor (and even for single vendor) is practically a
> very time consuming and difficult process.
>
> version allows very seamless choice of centralized vs distributed
> topology computation by signalling either zero or non zero value in the
> added to version -05 area leader sub-tlv.
>
> In other words I don't see any problem or room for debate .. adopting
> and implementing -05 allows use of centralized or distributed optimal
> flooding computation at the operator's discretion.
>
> Thx,
>
> R.
>
> On Mon, Aug 27, 2018 at 5:10 PM, Huaimo Chen <huaimo.chen@huawei..com
> <mailto:[email-masked]>> wrote:
>
>     IGP is distributed in nature. The distributed computation of
>     flooding topology like distributed SPF will keep IGP still
>     distributed in nature. Introducing centralized feature into IGP will
>     break IGP's distributed nature, which may cause some issues/problems.
>
>     After flooding reduction is deployed in an operational (ISP)
>     network, will we be allowed to do experiments on their network?
>     In some existing networks, some nodes run IGPs from one vendor, some
>     other nodes run IGPs from another vendor, and so on. Some may use
>     normal SPF, some others may use incremental SPF. It seems that we
>     have had these cases for many years.
>     >Tony
>
>     Best Regards,
>     Huaimo
>

---

From: Christian Hopps <[email-masked]>
Date: Tue, 28 Aug 2018 09:47:36 -0400

> No argument there.  There are no new problems or solutions.  Just us rediscovering the problems and approaches that others have used before.

Sheesh, that's giving me the Computer Blue[s].

Chris.

---

From: [email-masked]
Date: Tue, 28 Aug 2018 08:18:40 -0700

> Can we focus on finding one common algorithms that can deducing the optimized flooding topology based on the initial synchronized LSDB for further LSA flooding reduction?

We welcome proposals for algorithms that fulfill the requirements that have been discussed.

So far …. crickets.

Tony

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 30 Aug 2018 15:01:17 +0000

Hi Robert,

>Aside from static approach can you summarize in purely technical points advantages your draft proposes over draft-li-dynamic-flooding-05 ?
Initially, our draft focused on distributed solution for flooding reduction, and Tony’s on centralized way. This should be one advantage. Distributed solution is more practical.
In addition, we proposed the followings during the progress of our draft:

1)    A method to allow flooding topology to be lean and to allow multiple failures in an area;

2)    A procedure for establishing a new adjacency between a (new) node and  an existing node supporting flooding reduction;

3)    A way in which one touch (or command) to enable flooding reduction in a whole area within a short time;

4)    A way in which one touch (or command) to rollback flooding reduction to normal flooding in a whole area smoothly;

5)    A TLV for distributing the priority of a node to become a leader;

6)    Three algorithms for building a flooding topology.
Distributed solution for flooding reduction is stable after we resolve the issues raised by other experts during the last few IETFs.
BTW, as a service provider, which mode/solution (distributed or centralized) will you select to use in an operational network?

Best Regards,
Huaimo
>R.

On Mon, Aug 27, 2018 at 6:41 PM, Huaimo Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Best Regards,
Huaimo

From: Robert Raszuk [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, August 27, 2018 11:31 AM
To: Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>>; Peter Psenak <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi Huaimo,

Thx,
R.

Best Regards,
Huaimo

---

From: John E Drake <[email-masked]>
Date: Thu, 30 Aug 2018 19:35:14 +0000

Hi,

I have reviewed both of the flood reduction drafts and the draft referenced below, draft-cc-ospf-flooding-reduction-02, seems to me to be a derivative document inferior in quality to the draft, draft-li-dynamic-flooding-05, from which it is derived.  For example, the referenced draft fails to include a description of the message used to deliver the flooding topology when using centralized mode, it neglects to include any analysis of error conditions, and it neglects to include any description of the interactions with down-level nodes.

Yours Irrespectively,

John

From: Lsr <[email-masked]> On Behalf Of Huaimo Chen
Sent: Thursday, August 30, 2018 11:01 AM
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]; Acee Lindem (acee) <acee=[email-masked]>; [email-masked]; Jeff Tantsura <[email-masked]>; Tony Przygienda <[email-masked]>; Peter Psenak <[email-masked]>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi Robert,

Best Regards,
Huaimo

Best Regards,
Huaimo

Hi Huaimo,

Thx,
R.

Best Regards,
Huaimo
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_lsr&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=dQNetSHGAsFGcKk3dMxdWF6zY3NJc1cUOiTIkr-KOMA&s=aj_vuMJsmKUm-qly2FE2m_7WtK2ra7w4ftfPz37zXB8&e=>