Tony – The points you raise are worthy of discussion in the WG – but they are not the subject of this thread.
The subject of this thread is whether the draft should proceed in its current form (definition of a flooding algorithm + definition of new control procedures) or whether the two should be split into separate drafts. I do not see why definition of a flooding algorithm – which is functionally independent of the mechanism used to enable the use of such an algorithm – should be defined in the same document as a control mechanism. Could you please speak to this subject? Thanx. Les From: Tony Przygienda <tonysi...@gmail.com> Sent: Saturday, August 17, 2024 5:36 AM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> Cc: Tony Li <tony...@tony.li>; Acee Lindem <acee.i...@gmail.com>; lsr <lsr@ietf.org> Subject: Re: [Lsr] Re: Consensus Call on "IS-IS Distributed Flooding Reduction" - draft-ietf-lsr-distoptflood-05 First, let's observe precisely that the framework does not mandate in any way multiple algorithms, it just allows them. the draft does not in any way suggest that presence of multiple algorithms is desirable or recommended. If clarifying text is needed, it can be easily added. Second, contrary to assertions extended in this thread it is absolutely possible to mix algorithms in the framework provided as the draft proves by CDS induction. I expect the opponents claiming here otherwise to provide a clear counter example to put their claims on some substantiated base. In fact, the draft can be mixed much easier than we thought with dynamic flooding, basically anything advertising dynamic flooding sub-TLV must be considered a component by itself and due to the CDS stitching rules the mix will work fine (i.e. a leader component and leaderless component will be glued at edges and since both are CDS the result will be a CDS). A future version will improve what we have today. Having said that, the multiple algorithms itself is red herring largely (except maybe during migration) since the driving requirement here is minimal blast radius under any condition required by many customers looking at deploying the technology now and dynamic flooding does not meet it. And to point out why dynamic flooding does not meet its own requirement #4 in the draft, let us run the scenarios that make the suggested leaderless mode necessary: 1) if area leader and backup area leader are behind an articulation (and sorry, articulations are not uncommon in large and very large networks) the failure of the node partitioning the network may lead to large part of the network losing access to the leader or worse, rely on unreachable, old TLVs (and with that reduction being e.g. impossible to disable) and hence, in strictest sense the nodes relying on leader should always compute reachability to the leader before using its TLVs (as was done based on deployment experience in PNNI ultimately) . Dismissing "partition is not a problem" is basically telling lots of customers that the technology is not deployable for them without significant blast radius, configuration and placement risk. Leaderless framework does not expose them to such unnecessary risks and complexity. 2) The other significant blast radius in leader election occurs when an algorithm must be migrated to another one (bugs, better algorithm or some such). Yes, each node can be updated to a new algorithm separately in dynamic flooding but the switch on the leader ultimately leads to _all_ nodes involved changing behavior, generating basically blast radius of all nodes in the network using the reduction AFAIS. Leaderless framework contrary to that allows a node by node migration from one algorithm to another without all-nodes blast radius at certain point. 3) Ultimately, misconfiguration of the leader (by e.g. fat fingering the algorithm or introducing inadvertently misconfigured node with higher priority and so on and so on) can lead to change of behavior of all nodes running the algorithm, e.g. disabling it. Such outages are anything but theory on very large networks. Leaderless framework does not suffer from such possible blast radius. In a sense, one can consider the leaderless mode actually a simple extension of the dynamic flooding draft (and such was suggested to the authors). A new sub-TLV saying "active running leaderless algorithm" is necessary and it should be advertised w/o the dynamic flooding subTLV. Hence the nodes running leaders will run their algorithm and active running leaderless algorithm will use the rules in the leaderless framework to consider those a different component. Whether the leaderless algorithm number comes from the dynamic floodng registry or some other doesn't matter as long it's marked as "leaderless". Two versions can be put into registry for same algorithm, one leaderless, one not. As to improvement of framework language/terms I'm more than happy to oblige/discuss though component/CDS and many other terms (but not prunner) are simply standardized graph theory language. thanks --- tony On Fri, Aug 16, 2024 at 7:25 PM Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> wrote: So, this is exactly why the current content of the draft, which combines both the definition of a flooding algorithm with the definition of a new mechanism to control which algorithm(s) are used is problematic. Regarding the new control mechanism, my opinion is much the same as Tony Li - I think it is problematic. Acee - it seems that you feel otherwise. But I suspect all three of us can agree that the new flooding algorithm (defined in Section 2 of the draft) is something that is desirable. By combining the two into a single draft, the WG is forced to gives a thumbs up/down on both - which is not logical since even the draft itself allows that the algorithm (Section 2) can be deployed by using either the procedures defined in https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/ or by the new procedures defined in Section 1 of this draft. Please give the WG the opportunity to evaluate and progress (or not) these two logically independent elements in separate drafts. Les > -----Original Message----- > From: Tony Li <tony1ath...@gmail.com<mailto:tony1ath...@gmail.com>> On Behalf > Of Tony Li > Sent: Friday, August 16, 2024 8:06 AM > To: Acee Lindem <acee.i...@gmail.com<mailto:acee.i...@gmail.com>> > Cc: lsr <lsr@ietf.org<mailto:lsr@ietf.org>> > Subject: [Lsr] Re: Consensus Call on "IS-IS Distributed Flooding Reduction" - > draft-ietf-lsr-distoptflood-05 > > > Hi Acee, > > I beg to differ. Without a consistent, uniform algorithm selection, havoc > will > necessarily ensue. The algorithm itself can be distributed. The decision of > which algorithm to use cannot be inconsistent. > > For this reason, I oppose moving forward as the document currently stands. > > Tony > > > > On Aug 16, 2024, at 7:48 AM, Acee Lindem > > <acee.i...@gmail.com<mailto:acee.i...@gmail.com>> wrote: > > > > Speaking as WG member: > > > > From a technical standpoint, I don’t have a problem with the addition of the > flooding signaling (though I’m not fond of the prunner/zero prunner > terminology). > > > > The existing area leader election and flooding algorithm selection > (https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/) was > originally targeted at centralized flooding reduction. While it has been made > to > work for distributed flooding reduction, electing an area leader is not > needed. > Rather, the described one-hop signaling is all that is needed to assure > correct > operation and more suited to distributed flooding reduction algorithms. > > > > Thanks, > > Acee > > > >> On Aug 2, 2024, at 2:06 PM, Acee Lindem > >> <acee.i...@gmail.com<mailto:acee.i...@gmail.com>> wrote: > >> > >> > >> The subject draft was adopted as a WG document containing only the > flooding reduction algorithm (section 2). > >> > >> Procedures and signaling have been added to the current version allowing > concurrent operation within an IS-IS area of IS-IS routers running different > flooding reduction algorithms or no flooding reduction at all (section 1). > >> > >> WG members are questioning if this extra requirement needs to be met and > included in this document. There was an extensive discussion during the IETF > 120 LSR meeting and a MeetEcho show-of-hands poll was taken - > https://notes.ietf.org/notes-ietf-120-lsr > >> > >> Please indicate your preference and reasoning amongst the following > options by August 17, 2024: > >> > >> 1) The document remains in its current form describing both the > >> flooding > reduction algorithm signaling/procedures and the new flooding reduction > algorithm. > >> 2) The flooding reduction algorithm and procedures will be split into a > separate document with its own LSR WG adoption call. > >> 3) Some other resolution? > >> > >> Thanks, > >> Yingzhen, Chris, and Acee (LSR Chairs) > > > > > > _______________________________________________ > > Lsr mailing list -- lsr@ietf.org<mailto:lsr@ietf.org> > > To unsubscribe send an email to > > lsr-le...@ietf.org<mailto:lsr-le...@ietf.org> > > _______________________________________________ > Lsr mailing list -- lsr@ietf.org<mailto:lsr@ietf.org> > To unsubscribe send an email to lsr-le...@ietf.org<mailto:lsr-le...@ietf.org> _______________________________________________ Lsr mailing list -- lsr@ietf.org<mailto:lsr@ietf.org> To unsubscribe send an email to lsr-le...@ietf.org<mailto:lsr-le...@ietf.org>
_______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
