thanks Les, albeit the authors got already lots of helpful comments from you and Peter over beers in a bar I hope for further discussions. Especially your opinion on
a) special case where FR is 1-hop away from the leafs should not need a tunnel. I think most people would agree it's a good thing b) some example/better text on the computation as John poked at c) to give no favorite treatment to either data-tunnels or no-data-tunnels shortcutting since both of those variants have its own camp of non-likers ;-) ; both shall be equally documented over time I think. d) some people pine for FR hierarchy which would have the advantage of being "future-proof" while I fear the rathole involved when looking @ my RR-hierarchy-deployment-scar-tissues. Maybe we can cook something up that buys us an option to add it in the future in backwards compatible fashion without doing work now. I didn't think through the issue though. Ultimately, and in the danger of sounding a bit like a broken record, your view on hierarchy is IMO bitsy sideways. Customer would do like a generic, summarizing, self-building, non-looping hierarchy (i.e. not forced to be star-like) but as I think became obvious, only realistic distributed option without connection setup and crank-back is unfortunately a rather rigidly configured star without sideways transits (or high instability in hierarchy if arbitrary edges are introduced and hierarchy is 'renegotiated'). And it's not even protocol mechanics, it's fairly grounded in graph theory (if you summarize, i.e. information flow is only partial). Another way to think about it that Clos is actually nothing but such a star-no-horizontal-transit networks (well, to an extent, this discussion leads into ABR alternate behavior and shortcuts we lived and was "solved" for 2 levels only as well) and hence automatically building hierarchy from the defined center out is safe (just as RPL [which forces basically a CLOS and would be possibly an option for ISIS but don't forget that RPL to work needs arc-direction packet format change to prevent looping so that would need looking at] or RIFT [which largely assumes CLOS with some variants so is basically only good in discovering automatically a constraint it already posed ;-) ]). We may evolve over time to all networks topologies being Banyan-variants exclusively (well, where locality is given, we already do) but I consider that unlikely in generic WANs hence sprung the need for this draft. thanks --- tony On Sun, Jun 21, 2020 at 7:37 AM Les Ginsberg (ginsberg) <ginsberg= [email protected]> wrote: > I support WG adoption of > https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection .. > > > > (I also support the WG adoption of > https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/ ) > > > > I believe the problem space addressed by these two drafts warrants > attention. > > > > I am not yet overly enthused about approaches which promote > non-hierarchical network architectures. But it seems clear that there is > interest in deploying non-hierarchical solutions and both drafts present > solutions > > which merit further evaluation. > > > > The easy road for the WG to take would be to simply allow both drafts to > proceed to Experimental RFCs, but I hope we are able to do more than this. > Multiple solutions place undesirable burdens on vendors and providers alike. > > > > To the extent they feel comfortable, I encourage folks who wish to deploy > such solutions to share their requirements and discuss how each of the > solutions > > address their requirements/fall short of addressing their requirements. I > think this would help the WG discover better ways forward. > > > > Les > > > > > > > -----Original Message----- > > > From: Lsr <[email protected]> On Behalf Of Christian Hopps > > > Sent: Wednesday, June 10, 2020 12:29 PM > > > To: [email protected] > > > Cc: [email protected]; [email protected]; Christian Hopps > > > <[email protected]> > > > Subject: [Lsr] WG adoption call for > draft-przygienda-lsr-flood-reflection-01 > > > > > > This begins a 2 week WG adoption call for the following draft: > > > > > > https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection > > > > > > The draft would be adopted on the Experimental track. > > > > > > Please indicate your support or objection by June 24, 2020. > > > > > > Authors, please respond to the list indicating whether you are aware of > any > > > IPR that applies to this draft. > > > > > > Thanks, > > > Chris and Acee. > > > _______________________________________________ > > > Lsr mailing list > > > [email protected] > > > https://www..ietf.org/mailman/listinfo/lsr > <https://www.ietf.org/mailman/listinfo/lsr> > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
