Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
Let's use new email threads for suggested changes. One thread per suggested change/problem to keep things easier to follow. Thanks, Chris. signature.asc Description: Message signed with OpenPGP ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
Hi Tony, > From: Tony Li [mailto:tony1ath...@gmail.com] > Sent: Wednesday, February 27, 2019 2:07 AM > To: Huaimo Chen > Cc: Peter Psenak ; Christian Hopps ; > lsr@ietf.org; > lsr- cha...@ietf.org; lsr-...@ietf.org > Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + > IPR poll. > > > Hi Huaimo, > > > > 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. > I’m sorry that you don’t find it useful. Determining the split is trivial: > when you receive an IIH, > it has a system ID of the another system in it. If that other system is not > currently part of the > flooding topology, then it is quite clear that it is disconnected from the > flooding topology. > Repairing the split is done by enabling temporary flooding on the new link. For an adjacency between two nodes is up, the Hello packets exchanged between them will not change node/system IDs in them. How do you determine that other system is not currently part of the flooding topology? > There is an issue here that we have not yet resolved, which is the rate that > new links should be > temporarily added to the flooding topology. Some believe that adding any new > link is the > correct thing to do as it minimizes the recovery time. Others feel that > enabling too many links > could cause a flooding collapse, so link addition should be highly > constrained. We are still > discussing this and invite the WG’s opinions. The issue is resolved by the solutions in draft-cc-lsr-flooding-reduction. One solution is below, where the given distance can be adjusted/configured. If we want every node to flood on all its links, we let the given distance to a big number. If we want the nodes within 2 hops to a failure to flood on all their links, we set the given distance to 2. “In one way, when two or more failures on the current flooding topology occur almost in the same time, each of the nodes within a given distance (such as 3 hops) to a failure point, floods the link state (LS) that it receives to all the links (except for the one from which the LS is received) until a new flooding topology is built.” Another solution is just adding minimum links temporarily on the flooding topology to repair the split flooding topology until a new flooding topology is built. > > > 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. > We know of only two cases: (1) the neighbor is not part of the flooding > topology and we feel > that we can add more temporary flooding. (2) The neighbor is not part of the > flooding topology > and we cannot add more temporary flooding. > Obviously, in the case where we want to add temporary flooding, that TLV is > needed in the IIH. > > 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. > Agreed, which is why we need the TLV. The link can be enabled for “temporary flooding” by the node without using any TLV or Hello with the TLV. > >The other condition/case is that the new link is attached to nodes on the > >
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
Hi Huaimo, > > > 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. I’m sorry that you don’t find it useful. Determining the split is trivial: when you receive an IIH, it has a system ID of the another system in it. If that other system is not currently part of the flooding topology, then it is quite clear that it is disconnected from the flooding topology. Repairing the split is done by enabling temporary flooding on the new link. There is an issue here that we have not yet resolved, which is the rate that new links should be temporarily added to the flooding topology. Some believe that adding any new link is the correct thing to do as it minimizes the recovery time. Others feel that enabling too many links could cause a flooding collapse, so link addition should be highly constrained. We are still discussing this and invite the WG’s opinions. > > > 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. We know of only two cases: (1) the neighbor is not part of the flooding topology and we feel that we can add more temporary flooding. (2) The neighbor is not part of the flooding topology and we cannot add more temporary flooding. Obviously, in the case where we want to add temporary flooding, that TLV is needed in the IIH. > 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. Agreed, which is why we need the TLV. > 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. Agreed. Note that there are some additional corner cases. Since the two neighbors may not have the exact same information, one may consider the other to be on the flooding topology when in fact it is not. This might happen in the case of a node reboot. The IIH TLV gives us an explicit way of signaling, rather than simply guessing and sometimes getting it wrong. > > > 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. All adjacencies are a single hop in both IS-IS and OSPF. Yes, Hello packets may be lost. Fortunately, they are periodically transmitted, thus the next transmission will also contain the TLV. If IIH’s are getting lost at a significant rate, then the adjacency will not (and should not) come up. Thus, the request for temporary flooding will propagate to the neighbor in all cases that matter. > It is not convenient for a
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
Hi Peter, > -Original Message- > From: Peter Psenak [mailto:ppse...@cisco.com] > Sent: Sunday, February 24, 2019 1:47 PM > To: Huaimo Chen ; Christian Hopps > ; lsr@ietf.org > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org > 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 i
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
> On Feb 24, 2019, at 3:14 PM, Christian Hopps wrote: > >> In distributed mode the area leader is >> the one that advertises the algorithm that is used by all nodes that >> participates in dynamic flooding. > > I'd like to suggest that as this point is discussed we are careful to not try > and replace the standard configuration mechanisms. I appreciate the suggestion. The concern is that configuration of the algorithm selection is extremely challenging. Suppose that an administrator wishes to change algorithms. If manual, individual configuration is the only possible way, then the network is at risk while the configuration is in progress. At scale, this seemed inadvisable. A clear, signaled change seemed like a clean and simple synchronization point. Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
Peter Psenak writes: Huaimo, On 24/02/2019 06:34 , Huaimo Chen wrote: 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. I'd like to suggest that as this point is discussed we are careful to not try and replace the standard configuration mechanisms. Thanks, Chris. 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 On Behalf Of Christian Hopps Sent: 11 February 2019 16:15 To: lsr@ietf.org Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr signature.asc Description: PGP signature ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
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. 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 On Behalf Of Christian Hopps Sent: 11 February 2019 16:15 To: lsr@ietf.org Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
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. 2) The extensions to Hello protocols for enabling "temporary flooding" over a new link is not needed. 3) The extensions to Hello protocols for requesting/signaling "temporary flooding" for a connection does not work. 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). 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 On Behalf Of Christian Hopps Sent: 11 February 2019 16:15 To: lsr@ietf.org Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
Hi All, I support the adoption of this draft. Thanks, Sridhar.S > > -Original Message- > From: Lsr On Behalf Of Christian Hopps > Sent: 11 February 2019 16:15 > To: lsr@ietf.org > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org > 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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
I support the adoption of this draft by the WG. Thanks, Ketan -Original Message- From: Lsr On Behalf Of Christian Hopps Sent: 11 February 2019 16:15 To: lsr@ietf.org Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
Support. Thanks Mankamana -Original Message- From: Lsr on behalf of Christian Hopps Date: Monday, February 11, 2019 at 2:47 AM To: "lsr@ietf.org" Cc: "lsr-cha...@ietf.org" , "lsr-...@ietf.org" , "cho...@chopps.org" 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
Hi All, In favor of adopting both drafts in parallel, and then one draft focuses on the centralized solution and the other on the distributed solution. Best regards, Lei On Mon, Feb 11, 2019 at 2:47 AM Christian Hopps wrote: > > 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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
Yes/support Cheers, Jeff On Feb 11, 2019, 2:47 AM -0800, Christian Hopps , wrote: > > 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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
Support adoption (as co-author). I am not aware of any relevant IPR. Les > -Original Message- > From: Lsr On Behalf Of Christian Hopps > Sent: Monday, February 11, 2019 2:45 AM > To: lsr@ietf.org > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org > 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
Support the adoption of the draft. Regards, - Naiming > On Feb 11, 2019, at 2:44 AM, Christian Hopps wrote: > > > 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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
support. On Mon, Feb 11, 2019 at 4:47 AM Christian Hopps wrote: > > 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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > -- steve ulrich (sulrich@botwerks.*) ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
Support -Original Message- From: Lsr On Behalf Of Acee Lindem (acee) Sent: Monday, February 11, 2019 5:23 AM To: Christian Hopps ; lsr@ietf.org Cc: lsr-cha...@ietf.org; lsr-...@ietf.org Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll. Speaking as a WG member: I support adoption of draft-li-lsr-dynamic-flooding-02 as infrastructure for flooding reduction mechanisms based on a separate flooding topology. Work on individual flooding reduction/topology determination algorithms can proceed in separate drafts. Thanks, Acee On 2/11/19, 5:47 AM, "Christian Hopps" wrote: 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
> On Feb 11, 2019, at 10:19 AM, Lizhenbin wrote: > > Hi Chris, > 1. I have doubt about "The aim of this document is to describe the problem > space and standardize a way to signal dynamic flooding information.". Does > the aim mean the draft describes the problem space and standardize the way > for the centralized solution or mean the draft will standardize the way used > for both the centralized solutions and the distributed solutions? It does not standardize any algorithms. For a centralized algorithm (unspecified) use one has to distribute the flooding topology it does specify this. It also supplies the means to signal what distributed algorithm is in use (a value). > 2. I explained in the previous mail the distributed solution includes more > than the algorithms defined in the draft-cc-lsr-flooding-reduction-00 and > the overlapped signallings defined in the > draft-cc-lsr-flooding-reduction-00/draft-li-dynamic-flooding-03. For example, > it may define the standardized procedures for the distributed solutions. If > there is such part, is it defined by draft-li-lsr-dynamic-flooding-02 or > draft-cc-lsr-flooding-reduction? How a distributed algorithm decides to implement itself is up to that algorithm. This is not part of the signaled information. Again, the only thing that I am aware of in draft-li-dynamic-flooding in regards to distributed algorithms is what's required for us to use them as they get defined in the future, i.e., a way to signal which one is in use. Thanks, Chris. > > I hope you could clarify the above issues firstly for the adoption. > > > Thanks & Regards, > Zhenbin (Robin) > > > > > > 发件人: Lsr [lsr-boun...@ietf.org] 代表 Christian Hopps [cho...@chopps.org] > 发送时间: 2019年2月11日 18:44 > 收件人: lsr@ietf.org > 抄送: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org > 主题: [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. signature.asc Description: Message signed with OpenPGP ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
Support. On Mon, Feb 11, 2019 at 2:47 AM Christian Hopps wrote: > > 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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
Support. r. On Mon, Feb 11, 2019 at 11:47 AM Christian Hopps wrote: > > 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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
Speaking as a WG member: I support adoption of draft-li-lsr-dynamic-flooding-02 as infrastructure for flooding reduction mechanisms based on a separate flooding topology. Work on individual flooding reduction/topology determination algorithms can proceed in separate drafts. Thanks, Acee On 2/11/19, 5:47 AM, "Christian Hopps" wrote: 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[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. signature.asc Description: PGP signature ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
