Hi Peter, > -----Original Message----- > From: Peter Psenak [mailto:[email protected]] > Sent: Sunday, February 24, 2019 1:47 PM > To: Huaimo Chen <[email protected]>; Christian Hopps > <[email protected]>; [email protected] > Cc: [email protected]; [email protected] > Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + > IPR poll. > > 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. >
Section 6.7.11 just briefly mentions that the edges of split parts will determine and repair the split after the split of the flooding topology happens. However, there is not any details or description on how to determine or repair the split. This is not useful for implementers. > > > > > > > > 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. There are only a limited number of conditions (or cases). In each condition/case, it is deterministic whether we need to enable "temporary flooding" for a new link when it is up. Thus there is no need for any extensions to Hello protocols for enabling "temporary flooding" on a new link. For example, suppose that we have a current flooding topology containing all live nodes in an area, when a new link comes up, we may just have two conditions/cases. One condition/case is that the new link is attached to a new node not on the current flooding topology. In this condition/case, the new link needs to be enabled for "temporary flooding" after it is up. The other condition/case is that the new link is attached to nodes on the current flooding topology. In this condition/case, there is no need to enable "temporary flooding" on the 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. "The nodes ... will try to repair the flooding topology locally by enabling temporary flooding towards the nodes that they consider disconnected from the flooding topology ..." The above quoted text is from draft-li-lsr-dynamic-flooding-02, where "enabling temporary flooding towards the nodes" is to request/signal "temporary flooding" for a connection to connect partitioned/disconnected flooding topology into one through the extensions to Hello protocols described in draft-li-lsr-dynamic-flooding-02. Right? The extensions to Hello protocols for requesting/signaling "temporary flooding" for a connection to connect partitioned/disconnected flooding topology into one does not work since the connection may have two or more hops and a Hello packet may get lost. > > > > > > > > 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. > It is not convenient for a user/operator to configure on an area leader since the leader is dynamically selected. How do you address this? After the user/operator does some configurations on the (designated) leader, will the backup leader takes over the configurations after the designated leader is down? Best Regards, Huaimo > 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]<mailto:[email protected]>> On Behalf Of > Christian Hopps > > Sent: 11 February 2019 16:15 > > To: [email protected]<mailto:[email protected]> > > Cc: [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[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]<mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ > 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
