Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Robert Raszuk <[e-mail]>]

> 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 <[e-mail]> 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:[e-mail]]
> *Sent:* Monday, August 27, 2018 11:31 AM
> *To:* Huaimo Chen <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; Jeff Tantsura <
> [e-mail]>; Acee Lindem (acee) <acee=[e-mail].
> org>; Peter Psenak <[e-mail]>; Tony Przygienda <
> [e-mail]>
> *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 <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
>
>