Works for me.
Thanx Jeff.
Les
From: Jeff Tantsura <[email protected]>
Sent: Wednesday, August 22, 2018 1:21 PM
To: Les Ginsberg (ginsberg) <[email protected]>; Tony Przygienda
<[email protected]>
Cc: Tony Li <[email protected]>; [email protected]; Acee Lindem (acee)
<[email protected]>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward
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 protected]<mailto:[email protected]>>
Date: Wednesday, August 22, 2018 at 13:10
To: Tony Przygienda <[email protected]<mailto:[email protected]>>
Cc: Jeff Tantsura <[email protected]<mailto:[email protected]>>,
Tony Li <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "Acee
Lindem (acee)" <[email protected]<mailto:[email protected]>>
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward
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 protected]<mailto:[email protected]>>
Sent: Wednesday, August 22, 2018 11:59 AM
To: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>
Cc: Jeff Tantsura <[email protected]<mailto:[email protected]>>;
Tony Li <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; Acee Lindem (acee)
<[email protected]<mailto:[email protected]>>
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)
<[email protected]<mailto:[email protected]>> 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.
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 protected]<mailto:[email protected]>> On Behalf Of Jeff
Tantsura
Sent: Wednesday, August 22, 2018 9:43 AM
To: Tony Li <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; Acee Lindem (acee)
<[email protected]<mailto:[email protected]>>
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.
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 protected]<mailto:[email protected]>> wrote:
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
_______________________________________________
Lsr mailing list
[email protected]<mailto:[email protected]>
https://www..ietf.org/mailman/listinfo/lsr<https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________
Lsr mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
