Aijun,
On 28/08/18 11:14 , Aijun Wang wrote:
Hi, Robert:
As stated in
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-6.3,
the mentioned distributed mode is actually centrally mode. It depends on
the area leader to advertise the algorithms.
above is not correct. draft-li-dynamic-flooding supports both
centralized and distributed modes of operation. All routers in the area
though MUST agree on which mode they operate in and if they operate in
distributed mode, which algorithm is used to compute the flooding topology.
The ideal distributed mode is depending only the action/calculation from
each individual node as done in current SPF calculation. No leader
election process within whole area scope.
please see above.
Can we focus on finding one common algorithms that can deducing the
optimized flooding topology based on the initial synchronized LSDB for
further LSA flooding reduction?
one algorithm may not fit all environments and all users. Having at
least one standardized algorithm is definitely a goal, but I see no
reason to limit ourselves to single one in long run. The framework in
draft-li-dynamic-flooding does give us all the flexibility. And the
leader election is quite simple mechanism to achieve consistency and
maintain the flexibility of the solution.
thanks,
Peter
Best Regards.
Aijun Wang
Network R&D and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.
*发件人:*Robert Raszuk [mailto:[email protected]]
*发送时间:*2018年8月28日0:57
*收件人:*Huaimo Chen
*抄送:*[email protected]; Acee Lindem (acee); [email protected]; Jeff Tantsura;
Tony Przygienda; Peter Psenak
*主题:*Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward
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 <[email protected]
<mailto:[email protected]>> 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:[email protected] <mailto:[email protected]>]
*Sent:* Monday, August 27, 2018 11:31 AM
*To:* Huaimo Chen <[email protected] <mailto:[email protected]>>
*Cc:* [email protected] <mailto:[email protected]>; [email protected]
<mailto:[email protected]>; Jeff Tantsura <[email protected]
<mailto:[email protected]>>; Acee Lindem (acee)
<[email protected] <mailto:[email protected]>>;
Peter Psenak <[email protected] <mailto:[email protected]>>; Tony
Przygienda <[email protected] <mailto:[email protected]>>
*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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
