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<mailto: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<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to