Re: [Lsr] LSR Flooding Reduction Drafts

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=
40cisco.com@dmarc.ietf.org> 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 <lsr-bounces@ietf.org> *On Behalf Of *Jeff Tantsura
> *Sent:* Wednesday, August 22, 2018 9:43 AM
> *To:* Tony Li <tony1athome@gmail.com>
> *Cc:* lsr@ietf.org; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>
> *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 <tony1athome@gmail.com> 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
> Lsr@ietf.org
> https://www..ietf.org/mailman/listinfo/lsr
> <https://www.ietf.org/mailman/listinfo/lsr>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>