> 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 <huaimo.c...@huawei.com> wrote: > 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:rob...@raszuk.net] > *Sent:* Monday, August 27, 2018 11:31 AM > *To:* Huaimo Chen <huaimo.c...@huawei.com> > *Cc:* tony...@tony.li; lsr@ietf.org; Jeff Tantsura < > jefftant.i...@gmail.com>; Acee Lindem (acee) <acee=40cisco....@dmarc.ietf. > org>; Peter Psenak <ppse...@cisco.com>; Tony Przygienda < > tonysi...@gmail.com> > *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. > > > > On Mon, Aug 27, 2018 at 5:10 PM, Huaimo Chen <huaimo.c...@huawei.com> > wrote: > > >> 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. > 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. > > >> 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. > 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? > > >> 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 > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr