Huaimo,
On 24/02/2019 06:34 , Huaimo Chen wrote:
Some issues with draft-li-lsr-dynamic-flooding-02 not fully addressed
are briefed below.
1) There is no concrete procedure/method for fault tolerance
to multiple failures. When multiple failures happen and split the
flooding topology, the convergence time will be increased significantly
without fault tolerance. The longer the convergence time, the more the
traffic lose.
there is a solution for multiple failures - see section 6.7.11.
2) The extensions to Hello protocols for enabling “temporary
flooding” over a new link is not needed.
not if you do flooding on every link that comes up. If you want to be
smarter, then you need to selectively enable flooding only under
specific conditions and that must be done from both sides of the new link.
3) The extensions to Hello protocols for requesting/signaling
“temporary flooding” for a connection does not work.
sorry, but if you see a problem, please provide details, saying above is
simply unproductive.
In addition, for signaling the distributed solution/mode or the
centralized solution/mode, a user/operator needs to configure or select
a solution/mode on a node via CLI or other approach first. Which node
should the user/operator use to configure/select a mode? If the
user/operator can only use the leader node in the area to configure,
then it is neither convenient nor reasonable. The leader node in the
area is dynamically generated. But in the distributed mode/solution,
there is no leader selection (i.e., no leader should be generated).
there is an area leader in both modes. In distributed mode the area
leader is the one that advertises the algorithm that is used by all
nodes that participates in dynamic flooding.
regards,
Peter
draft-cc-lsr-flooding-reduction-01 contains solutions for some of the
above issues, which should be merged based on technical merits.
Best Regards,
Huaimo
-----Original Message-----
From: Lsr <[email protected]> On Behalf Of Christian Hopps
Sent: 11 February 2019 16:15
To: [email protected]
Cc: [email protected]; [email protected]; [email protected]
Subject: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 +
IPR poll.
Hi Folks,
We are starting a 2 week adoption call on draft-li-lsr-dynamic-flooding-02.
The aim of this document is to describe the problem space and
standardize a way to signal dynamic flooding information. It does not
standardize any specific algorithm for flooding topology creation.
Authors please respond indicating if you are aware of any IPR related to
this work.
We also have another draft (draft-cc-lsr-flooding-reduction-01) that
started as a distributed flooding topology algorithm and morphed into
that plus competing ideas on signaling of flooding topology information.
The intent after adoption of draft-li-lsr-dynamic-flooding-02 is
two-fold. One, the WG can discuss adding any signaling ideas from this
work to the adopted signaling draft (with proper attribution given as
appropriate), and two, for the authors of
draft-cc-lsr-flooding-reduction-01 to publish a new document without the
signaling portion and instead focus on their flooding topology
algorithm. This new focused document can be considered in parallel along
with the other algorithm work that has been proposed.
Flooding topology creation is seen as a hard problem for which we don't
expect a one-size-fits-all solution. Taking the steps outlined above
will help us move forward on the solutions.
Thanks,
Chris & Acee.
LSR WG Chairs.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
