Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Huaimo – Some responses inline. From: Lsr On Behalf Of Huaimo Chen Sent: Monday, March 04, 2019 8:16 PM To: Tony Li Cc: lsr@ietf.org; Christian Hopps ; Acee Lindem (acee) Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Hi Tony, >From: Tony Li [mailto:tony1ath...@gmail.com] >Sent: Thursday, February 21, 2019 12:32 AM >To: Huaimo Chen mailto:huaimo.c...@huawei.com>> >Cc: Peter Psenak mailto:ppse...@cisco.com>>; Acee Lindem >(acee) mailto:a...@cisco.com>>; Christian Hopps >>mailto:cho...@chopps.org>>; >lsr@ietf.org<mailto:lsr@ietf.org> >Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] > > >Hi Huaimo, > >>The way in which the flooding topology converges in the centralized >>mode/solution is different >>from that in the distributed mode/solution. In the former, after receiving >>the link states for the failures, >>the leader computes a new flooding topology and floods it to every other >>node, which receives >>and installs the new flooding topology. The working load on every non leader >>node is light. It has more >>processing power for a procedure/method for fault tolerance to failures. >>However, in the latter, every node computes and installs a new flooding >>topology after receiving >>the link states for the failures. It has less processing power for a >>procedure/method for fault tolerance. >>It is better to let each of the two modes use its own procedure/method for >>fault tolerance to failures, >>which is more appropriate to it. > >It’s true that a distributed solution will call more on an average node than a >centralized >solution will. However, that is not the steady state for either. In the >steady state, the flooding topology has been computed and has been put in >place already. >Thus, the impact of the topology computation at the time of the >topology change is nil. > >In addition, the amount of work to temporarily amend the flooding topology >should also >be minimal, and by that, I mean O(log n). The decision should only >be whether or not to temporarily add a link to flooding, and the only >information that a node >needs to do that is to determine if the node is already on the >flooding topology. That should be a lookup in a tree that represents the nodes >on the topology, >and that lookup should be O(log n). In other words, it’s fast >and efficient and not a significant drain on resources. > When multiple failures happen, the current flooding topology changes, the procedure for fault tolerance to failures is triggered to run, and a new flooding topology is to be computed. We need to have a converged flooding topology as soon as possible. In the distributed solution/mode, if a procedure for fault tolerance, which is not appropriate to it, is used, then we will have a converged flooding topology in a longer time. For example, after multiple failures occur, one procedure (in rough idea) for fault tolerance includes: 1) determine whether the current flooding topology splits, 2) compute backup paths to connect the split flooding topology, 3) enable/request the temporary flooding on the backup paths through extensions to Hello protocol. We can see that this procedure for fault tolerance takes a longer time than the algorithm computes a new flooding topology. This procedure will delay the convergence of flooding topology, which is not appropriate to the distributed solution/mode. So it is better for the distributed solution/mode to use a procedure for fault tolerance, which is more appropriate to it. [Les:] Given that you do not define what you think we should do I cannot comment on whatever alternative you might have in mind. I can say that your discussion does not acknowledge that BEFORE I can compute a new flooding topology I have to make sure I know what the updated full network topology is. This is what is compromised when the old flooding topology becomes partitioned. So the first priority has to be acquiring the updated topology. It would be useful if you replied to the thread that Tony started earlier today where he asks for input on how best to use temporary additions to the flooding topology. One extreme (my words – not Tony’s) would be to enable flooding on all links. This clearly risks introducing a destabilizing flooding storm. The other extreme would be to enable temporary flooding on a “minimal set of links”. This clearly risks delaying convergence. If this topic interests you, please reply to Tony’s new thread (“Open issues with Dynamic Flooding”). >>In the centralized solution/mode, scheduling an algorithm to compute flooding >>topology happens >>only on the leader, and then on the backup leader after the leader fails. The >>parameters for
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Hi Tony, >From: Tony Li [mailto:tony1ath...@gmail.com] >Sent: Thursday, February 21, 2019 12:32 AM >To: Huaimo Chen >Cc: Peter Psenak ; Acee Lindem (acee) ; >Christian Hopps >; lsr@ietf.org >Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] > > >Hi Huaimo, > >>The way in which the flooding topology converges in the centralized >>mode/solution is different >>from that in the distributed mode/solution. In the former, after receiving >>the link states for the failures, >>the leader computes a new flooding topology and floods it to every other >>node, which receives >>and installs the new flooding topology. The working load on every non leader >>node is light. It has more >>processing power for a procedure/method for fault tolerance to failures. >>However, in the latter, every node computes and installs a new flooding >>topology after receiving >>the link states for the failures. It has less processing power for a >>procedure/method for fault tolerance. >>It is better to let each of the two modes use its own procedure/method for >>fault tolerance to failures, >>which is more appropriate to it. > >It’s true that a distributed solution will call more on an average node than a >centralized >solution will. However, that is not the steady state for either. In the >steady state, the flooding topology has been computed and has been put in >place already. >Thus, the impact of the topology computation at the time of the >topology change is nil. > >In addition, the amount of work to temporarily amend the flooding topology >should also >be minimal, and by that, I mean O(log n). The decision should only >be whether or not to temporarily add a link to flooding, and the only >information that a node >needs to do that is to determine if the node is already on the >flooding topology. That should be a lookup in a tree that represents the nodes >on the topology, >and that lookup should be O(log n). In other words, it’s fast >and efficient and not a significant drain on resources. > When multiple failures happen, the current flooding topology changes, the procedure for fault tolerance to failures is triggered to run, and a new flooding topology is to be computed. We need to have a converged flooding topology as soon as possible. In the distributed solution/mode, if a procedure for fault tolerance, which is not appropriate to it, is used, then we will have a converged flooding topology in a longer time. For example, after multiple failures occur, one procedure (in rough idea) for fault tolerance includes: 1) determine whether the current flooding topology splits, 2) compute backup paths to connect the split flooding topology, 3) enable/request the temporary flooding on the backup paths through extensions to Hello protocol. We can see that this procedure for fault tolerance takes a longer time than the algorithm computes a new flooding topology. This procedure will delay the convergence of flooding topology, which is not appropriate to the distributed solution/mode. So it is better for the distributed solution/mode to use a procedure for fault tolerance, which is more appropriate to it. >>In the centralized solution/mode, scheduling an algorithm to compute flooding >>topology happens >>only on the leader, and then on the backup leader after the leader fails. The >>parameters for >>scheduling on the leader may be different from those for scheduling on the >>backup leader. >>However, in the distributed solution/mode, scheduling an algorithm to compute >>flooding topology >>occurs on every node. The parameters for scheduling on all the nodes need to >>be the same. > > >Actually, that’s not true. An implementation is free to do its own internal >scheduling >however it chooses, regardless of whether it implements a >distributed or centralized implementation. > > >>The procedure for achieving this is specific to the distributed mode/solution. > >More accurately, it is specific to a given implementation. > > >>If every particular algorithm for computing flooding topology in the >>distributed solution/mode >>describes a procedure for scheduling in details itself, there will be >>duplicated descriptions of >>the same procedure in multiple algorithms, one of which is selected to >>compute flooding >>topology on every node. It is better for the same scheduling procedure for >>multiple algorithms >>to be described in one document. > > >Actually, since the IETF should not be specifying the details of scheduling as >it is an >implementation detail, as they do not affect the behavior of the protocol, it >should not be >d
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Hi Huaimo, > The way in which the flooding topology converges in the centralized > mode/solution is different from > that in the distributed mode/solution. In the former, after receiving the > link states for the failures, > the leader computes a new flooding topology and floods it to every other > node, which receives > and installs the new flooding topology. The working load on every non leader > node is light. It has more > processing power for a procedure/method for fault tolerance to failures. > However, in the latter, every node computes and installs a new flooding > topology after receiving > the link states for the failures. It has less processing power for a > procedure/method for fault tolerance. > It is better to let each of the two modes use its own procedure/method for > fault tolerance to failures, > which is more appropriate to it. It’s true that a distributed solution will call more on an average node than a centralized solution will. However, that is not the steady state for either. In the steady state, the flooding topology has been computed and has been put in place already. Thus, the impact of the topology computation at the time of the topology change is nil. In addition, the amount of work to temporarily amend the flooding topology should also be minimal, and by that, I mean O(log n). The decision should only be whether or not to temporarily add a link to flooding, and the only information that a node needs to do that is to determine if the node is already on the flooding topology. That should be a lookup in a tree that represents the nodes on the topology, and that lookup should be O(log n). In other words, it’s fast and efficient and not a significant drain on resources. > In the centralized solution/mode, scheduling an algorithm to compute flooding > topology happens > only on the leader, and then on the backup leader after the leader fails. The > parameters for > scheduling on the leader may be different from those for scheduling on the > backup leader. > However, in the distributed solution/mode, scheduling an algorithm to compute > flooding topology > occurs on every node. The parameters for scheduling on all the nodes need to > be the same. Actually, that’s not true. An implementation is free to do its own internal scheduling however it chooses, regardless of whether it implements a distributed or centralized implementation. > The procedure for achieving this is specific to the distributed mode/solution. More accurately, it is specific to a given implementation. > If every particular algorithm for computing flooding topology in the > distributed solution/mode > describes a procedure for scheduling in details itself, there will be > duplicated descriptions of > the same procedure in multiple algorithms, one of which is selected to > compute flooding > topology on every node. It is better for the same scheduling procedure for > multiple algorithms > to be described in one document. Actually, since the IETF should not be specifying the details of scheduling as it is an implementation detail, as they do not affect the behavior of the protocol, it should not be discussed in any documents. Regards, Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Hi Peter, >-Original Message- >From: Peter Psenak [mailto:ppse...@cisco.com] >Sent: Monday, February 18, 2019 10:39 AM >To: Huaimo Chen ; Acee Lindem (acee) ; >Christian >Hopps ; lsr@ietf.org >Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] > >Hi Huaimo, > >On 18/02/2019 16:28 , Huaimo Chen wrote: >> Hi Peter, >> >>> -Original Message- >>> From: Peter Psenak [mailto:ppse...@cisco.com] >>> Sent: Thursday, February 14, 2019 2:30 AM >>> To: Huaimo Chen ; Acee Lindem (acee) >>> ; Christian Hopps ; lsr@ietf.org >>> Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft >>> Redux] >>> >>> Hi Huaimo, >>> >>> On 13/02/2019 22:50 , Huaimo Chen wrote: >>>> Hi Peter, >>>> >>>> My explanations/answers are in line below with prefix [HC]. >>>> >>>> -Original Message----- >>>> From: Peter Psenak [mailto:ppse...@cisco.com] >>>> Sent: Wednesday, February 6, 2019 4:58 AM >>>> To: Huaimo Chen ; Acee Lindem (acee) >>>> ; Christian Hopps ; lsr@ietf.org >>>> Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft >>>> Redux] >>>> >>>> Hi Huaimo, >>>> >>>> On 03/02/2019 17:58 , Huaimo Chen wrote: >>>>> Hi Acee, >>>>> >>>>> >>>>> >>>>> I agree with you on keeping the signaling for two modes. The >>>>> other parts for the distributed solution need to be removed. >>> >>> optimized flooding is not only about algorithm to calculate the >>> flooding topology and the way it is distributed/computed. It is also about >>> local rules to make sure the flooding remains consistent. >>> These are _independent_ of centralized/distributed modes. And it make >>> no sense to specify these rules in two drafts. >> >> [HC] The rules/procedures/behaviors that are common to both the >> centralized and distributed solution/mode should be in one document. These >> common parts will be used by both solutions/modes. >> They are described in the two drafts and should be merged based on technical >> merits. >> >> In addition to the common parts, there are still some >> rules/procedures/behaviors that are different from one mode to another >> mode. For example, the rule/procedure for fault tolerance to failures >> used in the centralized solution/mode will be different from that used in >> the distributed solution/mode. >I don't think there is any significant difference needed. And I believe these >local rules for both >modes should reside in a single document as most of them are applicable to >both modes. The way in which the flooding topology converges in the centralized mode/solution is different from that in the distributed mode/solution. In the former, after receiving the link states for the failures, the leader computes a new flooding topology and floods it to every other node, which receives and installs the new flooding topology. The working load on every non leader node is light. It has more processing power for a procedure/method for fault tolerance to failures. However, in the latter, every node computes and installs a new flooding topology after receiving the link states for the failures. It has less processing power for a procedure/method for fault tolerance. It is better to let each of the two modes use its own procedure/method for fault tolerance to failures, which is more appropriate to it. >> In the distributed solution/mode, there will be a set of >> rules/procedures/behaviors that are common to the algorithms for >> computing flooding topology and specific to the distributed >> solution/mode. For example, a specific procedure for scheduling an algorithm >> to compute a flooding topology will be used on every node for the >> distributed solution/mode. >scheduling a distributed versus centralized computation is not something that >makes the >behavior different. Sure, you can put a scheduling details for a particular >algorithm in the >document that describes the distributed algorithm itself. In the centralized solution/mode, scheduling an algorithm to compute flooding topology happens only on the leader, and then on the backup leader after the leader fails. The parameters for scheduling on the leader may be different from those for scheduling on the backup leader. However, in the distributed solution/mode, scheduling an algorithm to compute flooding topology occurs on every node. T
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Hi Huaimo, On 18/02/2019 16:28 , Huaimo Chen wrote: Hi Peter, -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Thursday, February 14, 2019 2:30 AM To: Huaimo Chen ; Acee Lindem (acee) ; Christian Hopps ; lsr@ietf.org Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Hi Huaimo, On 13/02/2019 22:50 , Huaimo Chen wrote: Hi Peter, My explanations/answers are in line below with prefix [HC]. -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Wednesday, February 6, 2019 4:58 AM To: Huaimo Chen ; Acee Lindem (acee) ; Christian Hopps ; lsr@ietf.org Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Hi Huaimo, On 03/02/2019 17:58 , Huaimo Chen wrote: Hi Acee, I agree with you on keeping the signaling for two modes. The other parts for the distributed solution need to be removed. optimized flooding is not only about algorithm to calculate the flooding topology and the way it is distributed/computed. It is also about local rules to make sure the flooding remains consistent. These are _independent_ of centralized/distributed modes. And it make no sense to specify these rules in two drafts. [HC] The rules/procedures/behaviors that are common to both the centralized and distributed solution/mode should be in one document. These common parts will be used by both solutions/modes. They are described in the two drafts and should be merged based on technical merits. In addition to the common parts, there are still some rules/procedures/behaviors that are different from one mode to another mode. For example, the rule/procedure for fault tolerance to failures used in the centralized solution/mode will be different from that used in the distributed solution/mode. I don't think there is any significant difference needed. And I believe these local rules for both modes should reside in a single document as most of them are applicable to both modes. In the distributed solution/mode, there will be a set of rules/procedures/behaviors that are common to the algorithms for computing flooding topology and specific to the distributed solution/mode. For example, a specific procedure for scheduling an algorithm to compute a flooding topology will be used on every node for the distributed solution/mode. scheduling a distributed versus centralized computation is not something that makes the behavior different. Sure, you can put a scheduling details for a particular algorithm in the document that describes the distributed algorithm itself. thanks, Peter There are no "other" parts specific for the distributed solution. [HC] Some behaviors for the distributed solution/mode are described in draft-li-dynamic-flooding. For example, there are a few of places from page 27 to 30, which define the behaviors specific for the distributed solution/mode. I strongly disagree. The fact that we say in centralized mode area leader recomputes and in distributed mode all nodes recompute make no difference in behavior. [HC] It seems better for some of them to be more general. Best Regards, Huaimo thanks, Peter . ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Hi Peter, >-Original Message- >From: Peter Psenak [mailto:ppse...@cisco.com] >Sent: Thursday, February 14, 2019 2:30 AM >To: Huaimo Chen ; Acee Lindem (acee) ; >Christian Hopps ; lsr@ietf.org >Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] > >Hi Huaimo, > >On 13/02/2019 22:50 , Huaimo Chen wrote: >> Hi Peter, >> >> My explanations/answers are in line below with prefix [HC]. >> >> -Original Message- >> From: Peter Psenak [mailto:ppse...@cisco.com] >> Sent: Wednesday, February 6, 2019 4:58 AM >> To: Huaimo Chen ; Acee Lindem (acee) >> ; Christian Hopps ; lsr@ietf.org >> Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] >> >> Hi Huaimo, >> >> On 03/02/2019 17:58 , Huaimo Chen wrote: >>> Hi Acee, >>> >>> >>> >>> I agree with you on keeping the signaling for two modes. The >>> other parts for the distributed solution need to be removed. > >optimized flooding is not only about algorithm to calculate the flooding >topology and the way >it is distributed/computed. It is also about local rules to make sure the >flooding remains consistent. >These are _independent_ of centralized/distributed modes. And it make no sense >to specify >these rules in two drafts. [HC] The rules/procedures/behaviors that are common to both the centralized and distributed solution/mode should be in one document. These common parts will be used by both solutions/modes. They are described in the two drafts and should be merged based on technical merits. In addition to the common parts, there are still some rules/procedures/behaviors that are different from one mode to another mode. For example, the rule/procedure for fault tolerance to failures used in the centralized solution/mode will be different from that used in the distributed solution/mode. In the distributed solution/mode, there will be a set of rules/procedures/behaviors that are common to the algorithms for computing flooding topology and specific to the distributed solution/mode. For example, a specific procedure for scheduling an algorithm to compute a flooding topology will be used on every node for the distributed solution/mode. >> >> There are no "other" parts specific for the distributed solution. >> >> [HC] Some behaviors for the distributed solution/mode are described in >> draft-li-dynamic-flooding. >>For example, there are a few of places from page 27 to 30, which define the >>behaviors specific >>for the distributed solution/mode. > >I strongly disagree. The fact that we say in centralized mode area leader >recomputes and in distributed >mode all nodes recompute make no difference in behavior. [HC] It seems better for some of them to be more general. Best Regards, Huaimo >thanks, >Peter ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
I want to make sure I'm not misinterpreted here, I'm not asking for a new draft
specifying these behaviors. I view these as flooding-algorithm-independent
generic behaviors. If there is something wrong or missing from this basic set,
they can be fixed via normal WG discussion and update. For a specific
centralized of distributed flooding algorithm, these behaviors could be
potentially be augmented with backward compatible enhancements.
Thanks,
Acee
On 2/14/19, 6:00 PM, "Acee Lindem (acee)" wrote:
Speaking as a WG member,
I just re-read section 6.7 and all the actions for distributed computation
are pretty much intuitive corollaries for the actions for the centralized
solution. I see no real reason to remove these. However, there is nothing to
prevent improvements to be proposed in an alternate draft.
Thanks,
Acee
On 2/14/19, 8:58 AM, "John E Drake" wrote:
Hi,
I completely agree with Peter.
Yours Irrespectively,
John
> -Original Message-
> From: Lsr On Behalf Of Peter Psenak
> Sent: Thursday, February 14, 2019 2:30 AM
> To: Huaimo Chen ; Acee Lindem (acee)
> ; Christian Hopps ; lsr@ietf.org
> Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
>
> Hi Huaimo,
>
> On 13/02/2019 22:50 , Huaimo Chen wrote:
> > Hi Peter,
> >
> > My explanations/answers are in line below with prefix [HC].
> >
> > -Original Message-
> > From: Peter Psenak [mailto:ppse...@cisco.com]
> > Sent: Wednesday, February 6, 2019 4:58 AM
> > To: Huaimo Chen ; Acee Lindem (acee)
> > ; Christian Hopps ; lsr@ietf.org
> > Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft
Redux]
> >
> > Hi Huaimo,
> >
> > On 03/02/2019 17:58 , Huaimo Chen wrote:
> >> Hi Acee,
> >>
> >>
> >>
> >> I agree with you on keeping the signaling for two modes. The
> >> other parts for the distributed solution need to be removed.
>
> optimized flooding is not only about algorithm to calculate the
flooding
> topology and the way it is distributed/computed. It is also about
local rules to
> make sure the flooding remains consistent. These are _independent_ of
> centralized/distributed modes. And it make no sense to specify these
rules in
> two drafts.
> >
> > There are no "other" parts specific for the distributed solution.
> >
> > [HC] Some behaviors for the distributed solution/mode are described
in draft-
> li-dynamic-flooding. For example, there are a few of places from page
27 to 30,
> which define the behaviors specific for the distributed solution/mode.
>
> I strongly disagree. The fact that we say in centralized mode area
leader
> recomputes and in distributed mode all nodes recompute make no
difference in
> behavior.
>
> thanks,
> Peter
>
> >
> > draft-li-dyanmic-flooding defines:
> >
> > 1. the signalling that is common and used by both modes 2.
distribution of the
> flooding-topology, which is specific to centralized mode 3. common
behavior of
> the nodes that support the extension, which is independent of the
mode of
> operation.
> >
> > [HC] In addition to these, draft-cc-lsr-flooding-reduction defines
more,
> including concrete protections, operations, and algorithms for
computing a
> flooding topology.
> >
> > Best Regards,
> > Huaimo
> >
> > thanks,
> > Peter
> >
> >
> >>
> >>
> >>
> >> Best Regards,
> >>
> >> Huaimo
> >>
> >> *From:* Acee Lindem (acee) [mailto:a...@cisco.com]
> >> *Sent:* Sunday, February 3, 2019 11:45 AM
> >> *To:* Huaimo Chen ; Christian Hopps
> >> ; lsr@ietf.org
> >> *Subject:* Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft
> >> Redux]
> >>
> >>
> >>
> >> Hi Huaimo,
> >>
> >>
> >>
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Speaking as a WG member,
I just re-read section 6.7 and all the actions for distributed computation are
pretty much intuitive corollaries for the actions for the centralized solution.
I see no real reason to remove these. However, there is nothing to prevent
improvements to be proposed in an alternate draft.
Thanks,
Acee
On 2/14/19, 8:58 AM, "John E Drake" wrote:
Hi,
I completely agree with Peter.
Yours Irrespectively,
John
> -Original Message-
> From: Lsr On Behalf Of Peter Psenak
> Sent: Thursday, February 14, 2019 2:30 AM
> To: Huaimo Chen ; Acee Lindem (acee)
> ; Christian Hopps ; lsr@ietf.org
> Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
>
> Hi Huaimo,
>
> On 13/02/2019 22:50 , Huaimo Chen wrote:
> > Hi Peter,
> >
> > My explanations/answers are in line below with prefix [HC].
> >
> > -Original Message-
> > From: Peter Psenak [mailto:ppse...@cisco.com]
> > Sent: Wednesday, February 6, 2019 4:58 AM
> > To: Huaimo Chen ; Acee Lindem (acee)
> > ; Christian Hopps ; lsr@ietf.org
> > Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
> >
> > Hi Huaimo,
> >
> > On 03/02/2019 17:58 , Huaimo Chen wrote:
> >> Hi Acee,
> >>
> >>
> >>
> >> I agree with you on keeping the signaling for two modes. The
> >> other parts for the distributed solution need to be removed.
>
> optimized flooding is not only about algorithm to calculate the flooding
> topology and the way it is distributed/computed. It is also about local
rules to
> make sure the flooding remains consistent. These are _independent_ of
> centralized/distributed modes. And it make no sense to specify these
rules in
> two drafts.
> >
> > There are no "other" parts specific for the distributed solution.
> >
> > [HC] Some behaviors for the distributed solution/mode are described in
draft-
> li-dynamic-flooding. For example, there are a few of places from page 27
to 30,
> which define the behaviors specific for the distributed solution/mode.
>
> I strongly disagree. The fact that we say in centralized mode area leader
> recomputes and in distributed mode all nodes recompute make no difference
in
> behavior.
>
> thanks,
> Peter
>
> >
> > draft-li-dyanmic-flooding defines:
> >
> > 1. the signalling that is common and used by both modes 2. distribution
of the
> flooding-topology, which is specific to centralized mode 3. common
behavior of
> the nodes that support the extension, which is independent of the mode of
> operation.
> >
> > [HC] In addition to these, draft-cc-lsr-flooding-reduction defines more,
> including concrete protections, operations, and algorithms for computing a
> flooding topology.
> >
> > Best Regards,
> > Huaimo
> >
> > thanks,
> > Peter
> >
> >
> >>
> >>
> >>
> >> Best Regards,
> >>
> >> Huaimo
> >>
> >> *From:* Acee Lindem (acee) [mailto:a...@cisco.com]
> >> *Sent:* Sunday, February 3, 2019 11:45 AM
> >> *To:* Huaimo Chen ; Christian Hopps
> >> ; lsr@ietf.org
> >> *Subject:* Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft
> >> Redux]
> >>
> >>
> >>
> >> Hi Huaimo,
> >>
> >>
> >>
> >> See inline.
> >>
> >>
> >>
> >> *From: *Lsr mailto:lsr-boun...@ietf.org>> on
> >> behalf of Huaimo Chen >> <mailto:huaimo.c...@huawei.com>>
> >> *Date: *Saturday, February 2, 2019 at 12:27 AM
> >> *To: *Christian Hopps mailto:cho...@chopps.org>>,
> >> "lsr@ietf.org <mailto:lsr@ietf.org>" >> <mailto:lsr@ietf.org>>
> >> *Subject: *Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft
> >> Redux]
> >>
> >>
> >>
> >> Hi Everyone,
> >>
> >>
> >>
> >> We proposed the distributed solution first, and Tony proposed the
> >> centralized solution first. Tony added the distributed solution
> >> (except for the algori
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Hi, I completely agree with Peter. Yours Irrespectively, John > -Original Message- > From: Lsr On Behalf Of Peter Psenak > Sent: Thursday, February 14, 2019 2:30 AM > To: Huaimo Chen ; Acee Lindem (acee) > ; Christian Hopps ; lsr@ietf.org > Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] > > Hi Huaimo, > > On 13/02/2019 22:50 , Huaimo Chen wrote: > > Hi Peter, > > > > My explanations/answers are in line below with prefix [HC]. > > > > -Original Message- > > From: Peter Psenak [mailto:ppse...@cisco.com] > > Sent: Wednesday, February 6, 2019 4:58 AM > > To: Huaimo Chen ; Acee Lindem (acee) > > ; Christian Hopps ; lsr@ietf.org > > Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] > > > > Hi Huaimo, > > > > On 03/02/2019 17:58 , Huaimo Chen wrote: > >> Hi Acee, > >> > >> > >> > >> I agree with you on keeping the signaling for two modes. The > >> other parts for the distributed solution need to be removed. > > optimized flooding is not only about algorithm to calculate the flooding > topology and the way it is distributed/computed. It is also about local rules > to > make sure the flooding remains consistent. These are _independent_ of > centralized/distributed modes. And it make no sense to specify these rules in > two drafts. > > > > There are no "other" parts specific for the distributed solution. > > > > [HC] Some behaviors for the distributed solution/mode are described in > > draft- > li-dynamic-flooding. For example, there are a few of places from page 27 to > 30, > which define the behaviors specific for the distributed solution/mode. > > I strongly disagree. The fact that we say in centralized mode area leader > recomputes and in distributed mode all nodes recompute make no difference in > behavior. > > thanks, > Peter > > > > > draft-li-dyanmic-flooding defines: > > > > 1. the signalling that is common and used by both modes 2. distribution of > > the > flooding-topology, which is specific to centralized mode 3. common behavior of > the nodes that support the extension, which is independent of the mode of > operation. > > > > [HC] In addition to these, draft-cc-lsr-flooding-reduction defines more, > including concrete protections, operations, and algorithms for computing a > flooding topology. > > > > Best Regards, > > Huaimo > > > > thanks, > > Peter > > > > > >> > >> > >> > >> Best Regards, > >> > >> Huaimo > >> > >> *From:* Acee Lindem (acee) [mailto:a...@cisco.com] > >> *Sent:* Sunday, February 3, 2019 11:45 AM > >> *To:* Huaimo Chen ; Christian Hopps > >> ; lsr@ietf.org > >> *Subject:* Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft > >> Redux] > >> > >> > >> > >> Hi Huaimo, > >> > >> > >> > >> See inline. > >> > >> > >> > >> *From: *Lsr mailto:lsr-boun...@ietf.org>> on > >> behalf of Huaimo Chen >> <mailto:huaimo.c...@huawei.com>> > >> *Date: *Saturday, February 2, 2019 at 12:27 AM > >> *To: *Christian Hopps mailto:cho...@chopps.org>>, > >> "lsr@ietf.org <mailto:lsr@ietf.org>" >> <mailto:lsr@ietf.org>> > >> *Subject: *Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft > >> Redux] > >> > >> > >> > >> Hi Everyone, > >> > >> > >> > >> We proposed the distributed solution first, and Tony proposed the > >> centralized solution first. Tony added the distributed solution > >> (except for the algorithms to compute flooding topology) into his > >> draft. And then we added the centralized solution into our draft. The > >> latest versions of the two drafts have largely converged at least at > >> the high level to a solution for solving the same problem. > >> > >> > >> > >> Our draft has multiple key technical advantages over Tony's draft as > >> we described in our email to the LSR list, which are summarized below: > >> > >> 1. It uses a fraction of flooding resource (i.e., it is multiple > >> times more efficient in flooding topology encoding); > >> > >> 2. It provides fault tolerance to multiple failures, minimizing > >> impact on network convergence, thus minimizing traffic lose
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Hi Huaimo, On 13/02/2019 22:50 , Huaimo Chen wrote: Hi Peter, My explanations/answers are in line below with prefix [HC]. -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Wednesday, February 6, 2019 4:58 AM To: Huaimo Chen ; Acee Lindem (acee) ; Christian Hopps ; lsr@ietf.org Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Hi Huaimo, On 03/02/2019 17:58 , Huaimo Chen wrote: Hi Acee, I agree with you on keeping the signaling for two modes. The other parts for the distributed solution need to be removed. optimized flooding is not only about algorithm to calculate the flooding topology and the way it is distributed/computed. It is also about local rules to make sure the flooding remains consistent. These are _independent_ of centralized/distributed modes. And it make no sense to specify these rules in two drafts. There are no "other" parts specific for the distributed solution. [HC] Some behaviors for the distributed solution/mode are described in draft-li-dynamic-flooding. For example, there are a few of places from page 27 to 30, which define the behaviors specific for the distributed solution/mode. I strongly disagree. The fact that we say in centralized mode area leader recomputes and in distributed mode all nodes recompute make no difference in behavior. thanks, Peter draft-li-dyanmic-flooding defines: 1. the signalling that is common and used by both modes 2. distribution of the flooding-topology, which is specific to centralized mode 3. common behavior of the nodes that support the extension, which is independent of the mode of operation. [HC] In addition to these, draft-cc-lsr-flooding-reduction defines more, including concrete protections, operations, and algorithms for computing a flooding topology. Best Regards, Huaimo thanks, Peter Best Regards, Huaimo *From:* Acee Lindem (acee) [mailto:a...@cisco.com] *Sent:* Sunday, February 3, 2019 11:45 AM *To:* Huaimo Chen ; Christian Hopps ; lsr@ietf.org *Subject:* Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Hi Huaimo, See inline. *From: *Lsr mailto:lsr-boun...@ietf.org>> on behalf of Huaimo Chen mailto:huaimo.c...@huawei.com>> *Date: *Saturday, February 2, 2019 at 12:27 AM *To: *Christian Hopps mailto:cho...@chopps.org>>, "lsr@ietf.org <mailto:lsr@ietf.org>" mailto:lsr@ietf.org>> *Subject: *Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Hi Everyone, We proposed the distributed solution first, and Tony proposed the centralized solution first. Tony added the distributed solution (except for the algorithms to compute flooding topology) into his draft. And then we added the centralized solution into our draft. The latest versions of the two drafts have largely converged at least at the high level to a solution for solving the same problem. Our draft has multiple key technical advantages over Tony's draft as we described in our email to the LSR list, which are summarized below: 1. It uses a fraction of flooding resource (i.e., it is multiple times more efficient in flooding topology encoding); 2. It provides fault tolerance to multiple failures, minimizing impact on network convergence, thus minimizing traffic lose; and 3. It is simpler and needs less processing time (i.e., faster and more efficient) in multiple scenarios. Based on the technical merits, our draft should be moved forward. However, Chair proposed to move Tony's draft forward and have us work on a distributed algorithm as we started with. I think that the distributed solution in Tony's draft needs to be removed and they work on the centralized solution. We remove the centralized solution from our draft and work on the distributed solution. I'm against "cutting the baby in half" given that the signaling for the distributed solution is a proper subset of what is required for the centralized solution. It is undesirable to have different signaling for the two modes. For the distributed algorithm you are proposing, do see problems with the signaling? Thanks, Acee Best Regards, Huaimo -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps Sent: Friday, February 1, 2019 7:26 AM To: lsr@ietf.org <mailto:lsr@ietf.org> Cc: cho...@chopps.org <mailto:cho...@chopps.org> Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Summary of where we are at with dynamic flooding reduction: - We have a well written original work that came first and described the problems as well as a TLVs to allow for a centralized solution (draft-li-dyanmic-flooding). We do not need to standardize the centralized algorithm. - A small change to this work allowed for distributed algorithms and for outside work on distributed algorithms to continue in parallel. - We have another original work that
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Hi Peter, My explanations/answers are in line below with prefix [HC]. -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Wednesday, February 6, 2019 4:58 AM To: Huaimo Chen ; Acee Lindem (acee) ; Christian Hopps ; lsr@ietf.org Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Hi Huaimo, On 03/02/2019 17:58 , Huaimo Chen wrote: > Hi Acee, > > > > I agree with you on keeping the signaling for two modes. The other > parts for the distributed solution need to be removed. There are no "other" parts specific for the distributed solution. [HC] Some behaviors for the distributed solution/mode are described in draft-li-dynamic-flooding. For example, there are a few of places from page 27 to 30, which define the behaviors specific for the distributed solution/mode. draft-li-dyanmic-flooding defines: 1. the signalling that is common and used by both modes 2. distribution of the flooding-topology, which is specific to centralized mode 3. common behavior of the nodes that support the extension, which is independent of the mode of operation. [HC] In addition to these, draft-cc-lsr-flooding-reduction defines more, including concrete protections, operations, and algorithms for computing a flooding topology. Best Regards, Huaimo thanks, Peter > > > > Best Regards, > > Huaimo > > *From:* Acee Lindem (acee) [mailto:a...@cisco.com] > *Sent:* Sunday, February 3, 2019 11:45 AM > *To:* Huaimo Chen ; Christian Hopps > ; lsr@ietf.org > *Subject:* Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft > Redux] > > > > Hi Huaimo, > > > > See inline. > > > > *From: *Lsr mailto:lsr-boun...@ietf.org>> on > behalf of Huaimo Chen <mailto:huaimo.c...@huawei.com>> > *Date: *Saturday, February 2, 2019 at 12:27 AM > *To: *Christian Hopps mailto:cho...@chopps.org>>, > "lsr@ietf.org <mailto:lsr@ietf.org>" <mailto:lsr@ietf.org>> > *Subject: *Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft > Redux] > > > > Hi Everyone, > > > > We proposed the distributed solution first, and Tony proposed the > centralized solution first. Tony added the distributed solution > (except for the algorithms to compute flooding topology) into his > draft. And then we added the centralized solution into our draft. The > latest versions of the two drafts have largely converged at least at > the high level to a solution for solving the same problem. > > > > Our draft has multiple key technical advantages over Tony's draft as > we described in our email to the LSR list, which are summarized below: > > 1. It uses a fraction of flooding resource (i.e., it is multiple > times more efficient in flooding topology encoding); > > 2. It provides fault tolerance to multiple failures, minimizing > impact on network convergence, thus minimizing traffic lose; and > > 3. It is simpler and needs less processing time (i.e., faster and > more efficient) in multiple scenarios. > > Based on the technical merits, our draft should be moved forward. > However, Chair proposed to move Tony's draft forward and have us work > on a distributed algorithm as we started with. > > > > I think that the distributed solution in Tony's draft needs to be > removed and they work on the centralized solution. We remove the > centralized solution from our draft and work on the distributed solution. > > > > I'm against "cutting the baby in half" given that the signaling for > the distributed solution is a proper subset of what is required for > the centralized solution. It is undesirable to have different > signaling for the two modes. For the distributed algorithm you are > proposing, do see problems with the signaling? > > > > Thanks, > > Acee > > > > Best Regards, > > Huaimo > > > > -Original Message- > > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps > > Sent: Friday, February 1, 2019 7:26 AM > > To: lsr@ietf.org <mailto:lsr@ietf.org> > > Cc: cho...@chopps.org <mailto:cho...@chopps.org> > > Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] > > > > > > Summary of where we are at with dynamic flooding reduction: > > > > - We have a well written original work that came first and described > the problems as well as a TLVs to allow for a centralized solution > (draft-li-dyanmic-flooding). We do not need to standardize the > centralized algorithm. > > > > - A small change to this work allowed for distributed algorithms and > for outside work on distributed algorithms to continue in parallel.
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Hi Peter, Many thx for your comment. What I had in mind here was use of multi instance (=2) over very reach physical topologies. So when we construct flooding graph for each such instance - even in centralized mode - the intention was to avoid flooding to take common links (just to reduce the impact of any failure to have effect on both instances). Yes of course data paths are different from flooding graph so I was just talking about the latter. I know that perhaps this should be moved to a different thread - the only reason why I mentioned about it here was that it is not immediately obvious to me if extensions which we have today defined in draft-li will be sufficient. Perhaps for centralized indeed they would be just fine as central graph compute oracle could be smart enough to address it. For distributed I am not sure. I did not want to derail the main topic though so let's shift it for other chat. Kind regards, Robert. primary/backup topologies are used for transmitting user data, not > necessarily the flooding data. I don't see how they are related to the > flooding topology, which is used for flooding only. > > To the point, if a new distributed algorithm is defined that needs more > data to be signaled, then we will extend the existing signaling. I don't > see that being a problem. The way the signaling is defined in > draft-li-lsr-dynamic-flooding does allow for such thing. > > thanks, > Peter > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Hi Robert, On 03/02/2019 21:37 , Robert Raszuk wrote: I fully agree and support proceeding with draft-li-dyanmic-flooding and to include protocol extensions in it for centralized topology propagation as well as basic hooks like "execute dynamic protocol number X" for distributed calculations. However one may observe that separate distributed algorithms may define their own protocol extensions and they should not break the above in any way. Then there is already some requirements of building two disjoined topologies in any rich ECMP DC fabric one say for primary paths the other for backup flows. (Case of active-active dual streaming applications). Question arises if this would be addressed also as part of basic spec, be combined with one or many of distributed algorithms or will require yet one more document which in turn will "extend" all of the above ? primary/backup topologies are used for transmitting user data, not necessarily the flooding data. I don't see how they are related to the flooding topology, which is used for flooding only. To the point, if a new distributed algorithm is defined that needs more data to be signaled, then we will extend the existing signaling. I don't see that being a problem. The way the signaling is defined in draft-li-lsr-dynamic-flooding does allow for such thing. thanks, Peter And before anyone suggests multi instance approach with logical or physical link separation it is not the right direction here. If anything perhaps MTR or SR come a bit closer. Kind regards, Robert. On Sun, Feb 3, 2019 at 9:14 PM mailto:tony...@tony.li>> wrote: I think that this discussion would be greatly clarified if we clearly separated the discussion between a) the algorithm for computing the flooding topology, and b) the signaling to indicate how to proceed. I think that we are all in agreement that the algorithms can and should be separated from the signaling. I think that we are all in agreement that each algorithm should be independent. I’m of the opinion that the centralized signaling is a bit more extensive than the signaling for the distributed mode, but that there is also considerable overlap and that things would be unnecessarily redundant if we were to separate them. I believe that we are not in disagreement about the basics for the distributed signaling. If you disagree with this, please clearly articulate why you feel the signaling should be separated. Regards, Tony ___ 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] Moving Forward [Re: Flooding Reduction Draft Redux]
Hi Huaimo, On 03/02/2019 17:58 , Huaimo Chen wrote: Hi Acee, I agree with you on keeping the signaling for two modes. The other parts for the distributed solution need to be removed. There are no "other" parts specific for the distributed solution. draft-li-dyanmic-flooding defines: 1. the signalling that is common and used by both modes 2. distribution of the flooding-topology, which is specific to centralized mode 3. common behavior of the nodes that support the extension, which is independent of the mode of operation. thanks, Peter Best Regards, Huaimo *From:* Acee Lindem (acee) [mailto:a...@cisco.com] *Sent:* Sunday, February 3, 2019 11:45 AM *To:* Huaimo Chen ; Christian Hopps ; lsr@ietf.org *Subject:* Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Hi Huaimo, See inline. *From: *Lsr mailto:lsr-boun...@ietf.org>> on behalf of Huaimo Chen mailto:huaimo.c...@huawei.com>> *Date: *Saturday, February 2, 2019 at 12:27 AM *To: *Christian Hopps mailto:cho...@chopps.org>>, "lsr@ietf.org <mailto:lsr@ietf.org>" mailto:lsr@ietf.org>> *Subject: *Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Hi Everyone, We proposed the distributed solution first, and Tony proposed the centralized solution first. Tony added the distributed solution (except for the algorithms to compute flooding topology) into his draft. And then we added the centralized solution into our draft. The latest versions of the two drafts have largely converged at least at the high level to a solution for solving the same problem. Our draft has multiple key technical advantages over Tony’s draft as we described in our email to the LSR list, which are summarized below: 1. It uses a fraction of flooding resource (i.e., it is multiple times more efficient in flooding topology encoding); 2. It provides fault tolerance to multiple failures, minimizing impact on network convergence, thus minimizing traffic lose; and 3. It is simpler and needs less processing time (i.e., faster and more efficient) in multiple scenarios. Based on the technical merits, our draft should be moved forward. However, Chair proposed to move Tony’s draft forward and have us work on a distributed algorithm as we started with. I think that the distributed solution in Tony’s draft needs to be removed and they work on the centralized solution. We remove the centralized solution from our draft and work on the distributed solution. I’m against “cutting the baby in half” given that the signaling for the distributed solution is a proper subset of what is required for the centralized solution. It is undesirable to have different signaling for the two modes. For the distributed algorithm you are proposing, do see problems with the signaling? Thanks, Acee Best Regards, Huaimo -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps Sent: Friday, February 1, 2019 7:26 AM To: lsr@ietf.org <mailto:lsr@ietf.org> Cc: cho...@chopps.org <mailto:cho...@chopps.org> Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Summary of where we are at with dynamic flooding reduction: - We have a well written original work that came first and described the problems as well as a TLVs to allow for a centralized solution (draft-li-dyanmic-flooding). We do not need to standardize the centralized algorithm. - A small change to this work allowed for distributed algorithms and for outside work on distributed algorithms to continue in parallel. - We have another original work that started primarily as a distributed algorithm (draft-cc-ospf-flooding-reduction) - Finally we also have: - Cross-pollination of ideas. - Failed attempts at merging. - An authors list "Arms-Race". Moving forward: - During IETF 103 I proposed we have no conflict if we: 1) adopt draft-li-lsr-dyanmic-flooding as the base WG document. 2) have authors of draft-cc-lsr-flooding-reduction work on a distributed algorithm as they started with. - Acee agreed during the meeting (as chair) that this was the best way forward. We had some agreement form the floor as well.. - Any good ideas regarding the distribution of a centralized topology can be debated and added (with appropriate attribution) to the base document after we adopt one. - This is what happens when we adopt a document as WG work, we work on it. - The original authors of the distributed solution can continue to work on their distributed algorithm in a separate document which would also need standardization. Does anyone see a serious problem with this path forward? Thanks, Chris & Acee. LSR Chairs. Christian Hopps mailto:cho...@chopps.org>> writes: We've had the authors of the individual conflicting drafts take a shot at merging their work. This has failed.
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
I agree totally with Chris on these points. Furthermore, the choices that operators will have are with the flooding algorithms. We need work on the generalized signaling in order to allow the algorithm work to proceed. Thanks, Acee On 2/4/19, 8:21 AM, "Lsr on behalf of Christian Hopps" wrote: Aijun Wang writes: > Hi, Christian: > > Based on your information, it is more fair to adopt these two drafts as WG documents at the same time. The reasons are the followings: > 1. The centralized and distributed modes don’t conflict with each other. Anyone can contribute their thoughts on them at their interests. No we do not adopt 2 documents solving the same relatively simple problem (signaling, primarily for centralized mode), we adopt one and incorporate any improvements needed, this isn't that hard a problem and we certainly don't need multiple solutions. Work on algorithms *is* a hard problem and can and should continue to be done in parallel with no conflict. > 2. They are both aiming to solve the same problem, which can give the operators more choices once they have been standardized. There's literally *no* reason to do this. We need to do our jobs as a WG and produce a single standard for signaling. > 3. The technique disputes between these two drafts are undergoing on the mailing list. If they are not well solved, we still need to discuss them after the adoption. It’s too hurry to make the adoption conclusion at current time. We've had a *YEAR* of multiple author documents, we're not hurrying at all, it's time to move forward. Thanks, Chris. > > Aijun Wang > China Telecom > >> 在 2019年2月1日，20:25，Christian Hopps 写道： >> >> >> Summary of where we are at with dynamic flooding reduction: >> >> - We have a well written original work that came first and described the problems as well as a TLVs to allow for a centralized solution (draft-li-dyanmic-flooding). We do not need to standardize the centralized algorithm. >> >> - A small change to this work allowed for distributed algorithms and for outside work on distributed algorithms to continue in parallel. >> >> - We have another original work that started primarily as a distributed algorithm >> (draft-cc-ospf-flooding-reduction) >> >> - Finally we also have: >> - Cross-pollination of ideas. >> - Failed attempts at merging. >> - An authors list "Arms-Race". >> >> Moving forward: >> >> - During IETF 103 I proposed we have no conflict if we: >> >> 1) adopt draft-li-lsr-dyanmic-flooding as the base WG document. >> 2) have authors of draft-cc-lsr-flooding-reduction work on a distributed algorithm as they started with. >> >> - Acee agreed during the meeting (as chair) that this was the best way forward. We had some agreement form the floor as well. >> >> - Any good ideas regarding the distribution of a centralized topology can be debated and added (with appropriate attribution) to the base document after we adopt one. >> >> - This is what happens when we adopt a document as WG work, we work on it. >> >> - The original authors of the distributed solution can continue to work on their distributed algorithm in a separate document which would also need standardization. >> >> Does anyone see a serious problem with this path forward? >> >> Thanks, >> Chris & Acee. >> LSR Chairs. >> >> Christian Hopps writes: >> >>> We've had the authors of the individual conflicting drafts take a shot at merging their work. >>> >>> This has failed. >>> >>> Here is the full history (which I also summarized during IETF103 as well). I will send a second email discussing this. >>> >>> - Jan 2, 2018 Publication: draft-li-dynamic-flooding and drfat-li-dynamic-flooding-isis >>> published centralized solution. >>> >>> - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and draft-cc-ospf-flooding-reduction >>> published distributed solution. >>> - mention of centralized solution asserting it is not good choice. >>> >>> - IETF 101 (Mar 2018) >>> - Video: https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS >>> - Minutes: https://datatracker.ietf.org/meeting/101/materials/minutes-101-lsr-00 >>> - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101 >>>- Generally well received. >>> - draft-cc-ospf-flooding-reduction-00 (4 authors) presented. >>>- Serious problems immediately found during presentation -- not fully baked. >>> >>> - Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author) >>> - Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author) >>> - Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised >>> -
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Aijun Wang writes: Hi, Christian: Based on your information, it is more fair to adopt these two drafts as WG documents at the same time. The reasons are the followings: 1. The centralized and distributed modes don’t conflict with each other. Anyone can contribute their thoughts on them at their interests. No we do not adopt 2 documents solving the same relatively simple problem (signaling, primarily for centralized mode), we adopt one and incorporate any improvements needed, this isn't that hard a problem and we certainly don't need multiple solutions. Work on algorithms *is* a hard problem and can and should continue to be done in parallel with no conflict. 2. They are both aiming to solve the same problem, which can give the operators more choices once they have been standardized. There's literally *no* reason to do this. We need to do our jobs as a WG and produce a single standard for signaling. 3. The technique disputes between these two drafts are undergoing on the mailing list. If they are not well solved, we still need to discuss them after the adoption. It’s too hurry to make the adoption conclusion at current time. We've had a *YEAR* of multiple author documents, we're not hurrying at all, it's time to move forward. Thanks, Chris. Aijun Wang China Telecom 在 2019年2月1日，20:25，Christian Hopps 写道： Summary of where we are at with dynamic flooding reduction: - We have a well written original work that came first and described the problems as well as a TLVs to allow for a centralized solution (draft-li-dyanmic-flooding). We do not need to standardize the centralized algorithm. - A small change to this work allowed for distributed algorithms and for outside work on distributed algorithms to continue in parallel. - We have another original work that started primarily as a distributed algorithm (draft-cc-ospf-flooding-reduction) - Finally we also have: - Cross-pollination of ideas. - Failed attempts at merging. - An authors list "Arms-Race". Moving forward: - During IETF 103 I proposed we have no conflict if we: 1) adopt draft-li-lsr-dyanmic-flooding as the base WG document. 2) have authors of draft-cc-lsr-flooding-reduction work on a distributed algorithm as they started with. - Acee agreed during the meeting (as chair) that this was the best way forward. We had some agreement form the floor as well. - Any good ideas regarding the distribution of a centralized topology can be debated and added (with appropriate attribution) to the base document after we adopt one. - This is what happens when we adopt a document as WG work, we work on it. - The original authors of the distributed solution can continue to work on their distributed algorithm in a separate document which would also need standardization. Does anyone see a serious problem with this path forward? Thanks, Chris & Acee. LSR Chairs. Christian Hopps writes: We've had the authors of the individual conflicting drafts take a shot at merging their work. This has failed. Here is the full history (which I also summarized during IETF103 as well). I will send a second email discussing this. - Jan 2, 2018 Publication: draft-li-dynamic-flooding and drfat-li-dynamic-flooding-isis published centralized solution. - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and draft-cc-ospf-flooding-reduction published distributed solution. - mention of centralized solution asserting it is not good choice. - IETF 101 (Mar 2018) - Video: https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS - Minutes: https://datatracker.ietf.org/meeting/101/materials/minutes-101-lsr-00 - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101 - Generally well received. - draft-cc-ospf-flooding-reduction-00 (4 authors) presented. - Serious problems immediately found during presentation -- not fully baked. - Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author) - Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author) - Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised - Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors) - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*. - Does not specify distributed algorithm only how to indicate one in use, small change. - Jul 2, 2018 draft-cc-ospf-flooding-reduction-02 published - IETF 102 (Jul 14, 2018) - draft-li-dynamic-flooding-05 presented. - draft-cc-ospf-flooding-reduction-02 presented. - Sep 12, 2018 draft-cc-ospf-flooding-reduction-03 (4 authors) - *LARGE CHANGE ADDS NEW CENTRALIZED SOLUTION*. - Sep 20, 2018 draft-cc-ospf-flooding-reduction-04 (4 authors) - Oct 21, 2018 draft-li-lsr-dynamic-flooding-00 and -01 (5 authors) - IETF 103 (Nov 3, 2018) - Chairs give direction - draft-li-lsr-dynamic-flooding-05 having come first, being well written and not specifying a distributed algorithm (merely allowing for one) is the correct vehicle to adopt as
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Robert – Let’s please not introduce issues which are not relevant. ☺ Any flooding optimization solution only applies to a single LSDB – and the set of nodes/links which support flooding of that LSDB. This means (in IS-IS speak): · Level-1 is distinct from Level-2. I could choose to apply flooding optimizations to one level and not the other if I wished. Or use a different algorithm/level · One MI instance is distinct from another · MT is not relevant since all the MT specific advertisements for all supported topologies are contained within a single LSDB (I.e., we do not support MT specific flooding) HTH Les From: Lsr On Behalf Of Robert Raszuk Sent: Sunday, February 03, 2019 12:37 PM To: Tony Li Cc: Huaimo Chen ; cho...@chopps.org; David Allan I ; li_zhenqi...@hotmail.com; lsr@ietf.org Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] I fully agree and support proceeding with draft-li-dyanmic-flooding and to include protocol extensions in it for centralized topology propagation as well as basic hooks like "execute dynamic protocol number X" for distributed calculations. However one may observe that separate distributed algorithms may define their own protocol extensions and they should not break the above in any way. Then there is already some requirements of building two disjoined topologies in any rich ECMP DC fabric one say for primary paths the other for backup flows. (Case of active-active dual streaming applications). Question arises if this would be addressed also as part of basic spec, be combined with one or many of distributed algorithms or will require yet one more document which in turn will "extend" all of the above ? And before anyone suggests multi instance approach with logical or physical link separation it is not the right direction here. If anything perhaps MTR or SR come a bit closer. Kind regards, Robert. On Sun, Feb 3, 2019 at 9:14 PM mailto:tony...@tony.li>> wrote: I think that this discussion would be greatly clarified if we clearly separated the discussion between a) the algorithm for computing the flooding topology, and b) the signaling to indicate how to proceed. I think that we are all in agreement that the algorithms can and should be separated from the signaling. I think that we are all in agreement that each algorithm should be independent. I’m of the opinion that the centralized signaling is a bit more extensive than the signaling for the distributed mode, but that there is also considerable overlap and that things would be unnecessarily redundant if we were to separate them. I believe that we are not in disagreement about the basics for the distributed signaling. If you disagree with this, please clearly articulate why you feel the signaling should be separated. Regards, Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Makes sense to me, thanks for the clarity... Dave -Original Message- From: Tony Li On Behalf Of tony...@tony.li Sent: Sunday, February 3, 2019 12:14 PM To: Robert Raszuk Cc: Huaimo Chen ; lsr@ietf.org; cho...@chopps.org; li_zhenqi...@hotmail.com; David Allan I Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] I think that this discussion would be greatly clarified if we clearly separated the discussion between a) the algorithm for computing the flooding topology, and b) the signaling to indicate how to proceed. I think that we are all in agreement that the algorithms can and should be separated from the signaling. I think that we are all in agreement that each algorithm should be independent. I’m of the opinion that the centralized signaling is a bit more extensive than the signaling for the distributed mode, but that there is also considerable overlap and that things would be unnecessarily redundant if we were to separate them. I believe that we are not in disagreement about the basics for the distributed signaling. If you disagree with this, please clearly articulate why you feel the signaling should be separated. Regards, Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
I fully agree and support proceeding with draft-li-dyanmic-flooding and to include protocol extensions in it for centralized topology propagation as well as basic hooks like "execute dynamic protocol number X" for distributed calculations. However one may observe that separate distributed algorithms may define their own protocol extensions and they should not break the above in any way. Then there is already some requirements of building two disjoined topologies in any rich ECMP DC fabric one say for primary paths the other for backup flows. (Case of active-active dual streaming applications). Question arises if this would be addressed also as part of basic spec, be combined with one or many of distributed algorithms or will require yet one more document which in turn will "extend" all of the above ? And before anyone suggests multi instance approach with logical or physical link separation it is not the right direction here. If anything perhaps MTR or SR come a bit closer. Kind regards, Robert. On Sun, Feb 3, 2019 at 9:14 PM wrote: > > I think that this discussion would be greatly clarified if we clearly > separated the discussion between > > a) the algorithm for computing the flooding topology, and > b) the signaling to indicate how to proceed. > > I think that we are all in agreement that the algorithms can and should be > separated from the signaling. > > I think that we are all in agreement that each algorithm should be > independent. > > I’m of the opinion that the centralized signaling is a bit more extensive > than the signaling for the distributed mode, but that there is also > considerable overlap and that things would > be unnecessarily redundant if we were to separate them. I believe that we > are not in disagreement about the basics for the distributed signaling. > > If you disagree with this, please clearly articulate why you feel the > signaling should be separated. > > Regards, > Tony > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
I think that this discussion would be greatly clarified if we clearly separated the discussion between a) the algorithm for computing the flooding topology, and b) the signaling to indicate how to proceed. I think that we are all in agreement that the algorithms can and should be separated from the signaling. I think that we are all in agreement that each algorithm should be independent. I’m of the opinion that the centralized signaling is a bit more extensive than the signaling for the distributed mode, but that there is also considerable overlap and that things would be unnecessarily redundant if we were to separate them. I believe that we are not in disagreement about the basics for the distributed signaling. If you disagree with this, please clearly articulate why you feel the signaling should be separated. Regards, Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
> The former will have all the good parts for the centralized solution, and the latter will have all the good parts for the distributed solution. And in your view which draft should contain required protocol extensions to accommodate both solutions ? Or are you suggesting that we should have completely different protocol extensions for distribution of centralized computed graphs vs for propagating parameters allowing customized distributed computation of partial flooding topology ? Thx, R. On Sun, Feb 3, 2019 at 5:44 PM Huaimo Chen wrote: > Hi Dave, > > > > There are two drafts containing the centralized solution and distributed > solution already on the table too. If the two drafts are adopted, they need > to be updated for one draft to focus on the centralized solution and the > other on the distributed solution. The former will have all the good parts > for the centralized solution, and the latter will have all the good parts > for the distributed solution. > > > > Best Regards, > > Huaimo > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Hi Acee, I agree with you on keeping the signaling for two modes. The other parts for the distributed solution need to be removed. Best Regards, Huaimo From: Acee Lindem (acee) [mailto:a...@cisco.com] Sent: Sunday, February 3, 2019 11:45 AM To: Huaimo Chen ; Christian Hopps ; lsr@ietf.org Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Hi Huaimo, See inline. From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Huaimo Chen mailto:huaimo.c...@huawei.com>> Date: Saturday, February 2, 2019 at 12:27 AM To: Christian Hopps mailto:cho...@chopps.org>>, "lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>> Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Hi Everyone, We proposed the distributed solution first, and Tony proposed the centralized solution first. Tony added the distributed solution (except for the algorithms to compute flooding topology) into his draft. And then we added the centralized solution into our draft. The latest versions of the two drafts have largely converged at least at the high level to a solution for solving the same problem. Our draft has multiple key technical advantages over Tony’s draft as we described in our email to the LSR list, which are summarized below: 1. It uses a fraction of flooding resource (i.e., it is multiple times more efficient in flooding topology encoding); 2. It provides fault tolerance to multiple failures, minimizing impact on network convergence, thus minimizing traffic lose; and 3. It is simpler and needs less processing time (i.e., faster and more efficient) in multiple scenarios. Based on the technical merits, our draft should be moved forward. However, Chair proposed to move Tony’s draft forward and have us work on a distributed algorithm as we started with. I think that the distributed solution in Tony’s draft needs to be removed and they work on the centralized solution. We remove the centralized solution from our draft and work on the distributed solution. I’m against “cutting the baby in half” given that the signaling for the distributed solution is a proper subset of what is required for the centralized solution. It is undesirable to have different signaling for the two modes. For the distributed algorithm you are proposing, do see problems with the signaling? Thanks, Acee Best Regards, Huaimo -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps Sent: Friday, February 1, 2019 7:26 AM To: lsr@ietf.org<mailto:lsr@ietf.org> Cc: cho...@chopps.org<mailto:cho...@chopps.org> Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Summary of where we are at with dynamic flooding reduction: - We have a well written original work that came first and described the problems as well as a TLVs to allow for a centralized solution (draft-li-dyanmic-flooding). We do not need to standardize the centralized algorithm. - A small change to this work allowed for distributed algorithms and for outside work on distributed algorithms to continue in parallel. - We have another original work that started primarily as a distributed algorithm (draft-cc-ospf-flooding-reduction) - Finally we also have: - Cross-pollination of ideas. - Failed attempts at merging. - An authors list "Arms-Race". Moving forward: - During IETF 103 I proposed we have no conflict if we: 1) adopt draft-li-lsr-dyanmic-flooding as the base WG document. 2) have authors of draft-cc-lsr-flooding-reduction work on a distributed algorithm as they started with. - Acee agreed during the meeting (as chair) that this was the best way forward. We had some agreement form the floor as well.. - Any good ideas regarding the distribution of a centralized topology can be debated and added (with appropriate attribution) to the base document after we adopt one. - This is what happens when we adopt a document as WG work, we work on it. - The original authors of the distributed solution can continue to work on their distributed algorithm in a separate document which would also need standardization. Does anyone see a serious problem with this path forward? Thanks, Chris & Acee. LSR Chairs. Christian Hopps mailto:cho...@chopps.org>> writes: > We've had the authors of the individual conflicting drafts take a shot at > merging their work. > >This has failed. > > Here is the full history (which I also summarized during IETF103 as well). I > will send a second email discussing this. > > - Jan 2, 2018 Publication: draft-li-dynamic-flooding and > drfat-li-dynamic-flooding-isis > published centralized solution. > > - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and > draft-cc-ospf-flooding-reduction > published dis
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Hi Dave, There are two drafts containing the centralized solution and distributed solution already on the table too. If the two drafts are adopted, they need to be updated for one draft to focus on the centralized solution and the other on the distributed solution. The former will have all the good parts for the centralized solution, and the latter will have all the good parts for the distributed solution. Best Regards, Huaimo From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of David Allan I Sent: Sunday, February 3, 2019 10:32 AM To: li_zhenqi...@hotmail.com; rob...@raszuk.net; cho...@chopps.org Cc: lsr@ietf.org Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] With all respect, there are other distributed solutions on the table… Cheers Dave From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of li zhenqiang Sent: Sunday, February 3, 2019 1:28 AM To: Robert Raszuk mailto:rob...@raszuk.net>>; Christian Hopps mailto:cho...@chopps.org>> Cc: lsr mailto:lsr@ietf.org>> Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Hello all, At current situation, I think we'd better move both the two drafts foward in parallel keeping draft-li-dyanmic-flooding focus on the centralized solution and draft-cc-ospf-flooding-reduction on the distributed solution. Thanks. Best Regards, Zhenqiang Li li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com> From: Robert Raszuk<mailto:rob...@raszuk.net> Date: 2019-02-02 20:20 To: Christian Hopps<mailto:cho...@chopps.org> CC: lsr<mailto:lsr@ietf.org> Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Sound like best plan fwd. Thx, R. On Fri, Feb 1, 2019, 13:26 Christian Hopps mailto:cho...@chopps.org> wrote: Summary of where we are at with dynamic flooding reduction: - We have a well written original work that came first and described the problems as well as a TLVs to allow for a centralized solution (draft-li-dyanmic-flooding). We do not need to standardize the centralized algorithm. - A small change to this work allowed for distributed algorithms and for outside work on distributed algorithms to continue in parallel. - We have another original work that started primarily as a distributed algorithm (draft-cc-ospf-flooding-reduction) - Finally we also have: - Cross-pollination of ideas. - Failed attempts at merging. - An authors list "Arms-Race". Moving forward: - During IETF 103 I proposed we have no conflict if we: 1) adopt draft-li-lsr-dyanmic-flooding as the base WG document.. 2) have authors of draft-cc-lsr-flooding-reduction work on a distributed algorithm as they started with. - Acee agreed during the meeting (as chair) that this was the best way forward. We had some agreement form the floor as well. - Any good ideas regarding the distribution of a centralized topology can be debated and added (with appropriate attribution) to the base document after we adopt one. - This is what happens when we adopt a document as WG work, we work on it. - The original authors of the distributed solution can continue to work on their distributed algorithm in a separate document which would also need standardization. Does anyone see a serious problem with this path forward? Thanks, Chris & Acee. LSR Chairs. Christian Hopps mailto:cho...@chopps.org>> writes: > We've had the authors of the individual conflicting drafts take a shot at > merging their work. > >This has failed. > > Here is the full history (which I also summarized during IETF103 as well). I > will send a second email discussing this. > > - Jan 2, 2018 Publication: draft-li-dynamic-flooding and > drfat-li-dynamic-flooding-isis > published centralized solution. > > - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and > draft-cc-ospf-flooding-reduction > published distributed solution. > - mention of centralized solution asserting it is not good choice. > > - IETF 101 (Mar 2018) > - Video: > https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS > - Minutes: > https://datatracker.ietf.org/meeting/101/materials/minutes-101-lsr-00 > - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101 > - Generally well received. > - draft-cc-ospf-flooding-reduction-00 (4 authors) presented. > - Serious problems immediately found during presentation -- not fully > baked. > > - Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author) > - Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author) > - Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised > - Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors) > - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*. > - Does not specify distributed algorithm only
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Hi Huaimo, See inline. From: Lsr on behalf of Huaimo Chen Date: Saturday, February 2, 2019 at 12:27 AM To: Christian Hopps , "lsr@ietf.org" Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Hi Everyone, We proposed the distributed solution first, and Tony proposed the centralized solution first. Tony added the distributed solution (except for the algorithms to compute flooding topology) into his draft. And then we added the centralized solution into our draft. The latest versions of the two drafts have largely converged at least at the high level to a solution for solving the same problem. Our draft has multiple key technical advantages over Tony’s draft as we described in our email to the LSR list, which are summarized below: 1. It uses a fraction of flooding resource (i.e., it is multiple times more efficient in flooding topology encoding); 2. It provides fault tolerance to multiple failures, minimizing impact on network convergence, thus minimizing traffic lose; and 3. It is simpler and needs less processing time (i.e., faster and more efficient) in multiple scenarios. Based on the technical merits, our draft should be moved forward. However, Chair proposed to move Tony’s draft forward and have us work on a distributed algorithm as we started with. I think that the distributed solution in Tony’s draft needs to be removed and they work on the centralized solution. We remove the centralized solution from our draft and work on the distributed solution. I’m against “cutting the baby in half” given that the signaling for the distributed solution is a proper subset of what is required for the centralized solution. It is undesirable to have different signaling for the two modes. For the distributed algorithm you are proposing, do see problems with the signaling? Thanks, Acee Best Regards, Huaimo -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps Sent: Friday, February 1, 2019 7:26 AM To: lsr@ietf.org Cc: cho...@chopps.org Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Summary of where we are at with dynamic flooding reduction: - We have a well written original work that came first and described the problems as well as a TLVs to allow for a centralized solution (draft-li-dyanmic-flooding). We do not need to standardize the centralized algorithm. - A small change to this work allowed for distributed algorithms and for outside work on distributed algorithms to continue in parallel. - We have another original work that started primarily as a distributed algorithm (draft-cc-ospf-flooding-reduction) - Finally we also have: - Cross-pollination of ideas. - Failed attempts at merging. - An authors list "Arms-Race". Moving forward: - During IETF 103 I proposed we have no conflict if we: 1) adopt draft-li-lsr-dyanmic-flooding as the base WG document. 2) have authors of draft-cc-lsr-flooding-reduction work on a distributed algorithm as they started with. - Acee agreed during the meeting (as chair) that this was the best way forward. We had some agreement form the floor as well.. - Any good ideas regarding the distribution of a centralized topology can be debated and added (with appropriate attribution) to the base document after we adopt one. - This is what happens when we adopt a document as WG work, we work on it. - The original authors of the distributed solution can continue to work on their distributed algorithm in a separate document which would also need standardization. Does anyone see a serious problem with this path forward? Thanks, Chris & Acee. LSR Chairs. Christian Hopps writes: > We've had the authors of the individual conflicting drafts take a shot at > merging their work. > >This has failed. > > Here is the full history (which I also summarized during IETF103 as well). I > will send a second email discussing this. > > - Jan 2, 2018 Publication: draft-li-dynamic-flooding and > drfat-li-dynamic-flooding-isis > published centralized solution. > > - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and > draft-cc-ospf-flooding-reduction > published distributed solution. > - mention of centralized solution asserting it is not good choice. > > - IETF 101 (Mar 2018) > - Video: > https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS > - Minutes: > https://datatracker.ietf.org/meeting/101/materials/minutes-101-lsr-00 > - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101 > - Generally well received. > - draft-cc-ospf-flooding-reduction-00 (4 authors) presented. > - Serious problems immediately found during presentation -- not fully > baked. > > - Mar 18, 2018 draft
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
On Sat, Feb 2, 2019 at 11:06 AM Aijun Wang wrote: > Hi, Christian: > > Based on your information, it is more fair to adopt these two drafts as WG > documents at the same time. The reasons are the followings: > 1. The centralized and distributed modes don’t conflict with each other. > Anyone can contribute their thoughts on them at their interests. > I am not interested in two modes only if it is proved that they don't conflict, I think two modes can cause problems. > 2. They are both aiming to solve the same problem, which can give the > operators more choices once they have been standardized. > I am interested to adopt different works/drafts, not similar solving same problem within same WG, we need to work as a team and separate work. We can make two drafts merged into one, but IMHO having many authors working on two similar work is not good practice/process or not good adoption. 3. The technique disputes between these two drafts are undergoing on the > mailing list. If they are not well solved, we still need to discuss them > after the adoption. It’s too hurry to make the adoption conclusion at > current time. > Why we adopt if they are not well solved into one draft, having two not solved is worst than having only one, even in discussions in IETF, it is very very difficult to discuss with authors of an adopted draft, it is easier to discuss and change non adopted drafts. If I was IETF WG chair I will delay adoptions until we get authors to update their work and making things clear to be well solved before WG adoptions. > 在 2019年2月1日，20:25，Christian Hopps 写道： > > > Summary of where we are at with dynamic flooding reduction: > > - We have a well written original work that came first and described the problems as well as a TLVs to allow for a centralized solution (draft-li-dyanmic-flooding). We do not need to standardize the centralized algorithm. > > - A small change to this work allowed for distributed algorithms and for outside work on distributed algorithms to continue in parallel. > > - We have another original work that started primarily as a distributed algorithm > (draft-cc-ospf-flooding-reduction) > > > > - Finally we also have: > > - Cross-pollination of ideas. > > - Failed attempts at merging. > > - An authors list "Arms-Race". > > > > Moving forward: > > > > - During IETF 103 I proposed we have no conflict if we: > > > > 1) adopt draft-li-lsr-dyanmic-flooding as the base WG document. > > 2) have authors of draft-cc-lsr-flooding-reduction work on a > distributed algorithm as they started with. > > > > - Acee agreed during the meeting (as chair) that this was the best way > forward. We had some agreement form the floor as well. > > > > - Any good ideas regarding the distribution of a centralized topology > can be debated and added (with appropriate attribution) to the base > document after we adopt one. > This can create big debates and many discussions after adoption. Best way to discuss with-saving times is between authors and WG before adoptions especially when we have many similar solution-drafts .. > > > > - This is what happens when we adopt a document as WG work, we work on > it. > > > > - The original authors of the distributed solution can continue to work > on their distributed algorithm in a separate document which would also need > standardization. > > > > Does anyone see a serious problem with this path forward? > I think it is problem if we adopt without clear discussed-objectives of each draft/author-team under investigation. AB > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Hi, Christian: Based on your information, it is more fair to adopt these two drafts as WG documents at the same time. The reasons are the followings: 1. The centralized and distributed modes don’t conflict with each other. Anyone can contribute their thoughts on them at their interests. 2. They are both aiming to solve the same problem, which can give the operators more choices once they have been standardized. 3. The technique disputes between these two drafts are undergoing on the mailing list. If they are not well solved, we still need to discuss them after the adoption. It’s too hurry to make the adoption conclusion at current time. Aijun Wang China Telecom > 在 2019年2月1日，20:25，Christian Hopps 写道： > > > Summary of where we are at with dynamic flooding reduction: > > - We have a well written original work that came first and described the > problems as well as a TLVs to allow for a centralized solution > (draft-li-dyanmic-flooding). We do not need to standardize the centralized > algorithm. > > - A small change to this work allowed for distributed algorithms and for > outside work on distributed algorithms to continue in parallel. > > - We have another original work that started primarily as a distributed > algorithm > (draft-cc-ospf-flooding-reduction) > > - Finally we also have: > - Cross-pollination of ideas. > - Failed attempts at merging. > - An authors list "Arms-Race". > > Moving forward: > > - During IETF 103 I proposed we have no conflict if we: > > 1) adopt draft-li-lsr-dyanmic-flooding as the base WG document. > 2) have authors of draft-cc-lsr-flooding-reduction work on a distributed > algorithm as they started with. > > - Acee agreed during the meeting (as chair) that this was the best way > forward. We had some agreement form the floor as well. > > - Any good ideas regarding the distribution of a centralized topology can be > debated and added (with appropriate attribution) to the base document after > we adopt one. > > - This is what happens when we adopt a document as WG work, we work on it. > > - The original authors of the distributed solution can continue to work on > their distributed algorithm in a separate document which would also need > standardization. > > Does anyone see a serious problem with this path forward? > > Thanks, > Chris & Acee. > LSR Chairs. > > Christian Hopps writes: > >> We've had the authors of the individual conflicting drafts take a shot at >> merging their work. >> >> This has failed. >> >> Here is the full history (which I also summarized during IETF103 as well). I >> will send a second email discussing this. >> >> - Jan 2, 2018 Publication: draft-li-dynamic-flooding and >> drfat-li-dynamic-flooding-isis >> published centralized solution. >> >> - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and >> draft-cc-ospf-flooding-reduction >> published distributed solution. >> - mention of centralized solution asserting it is not good choice. >> >> - IETF 101 (Mar 2018) >> - Video: >> https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS >> - Minutes: >> https://datatracker.ietf.org/meeting/101/materials/minutes-101-lsr-00 >> - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101 >>- Generally well received. >> - draft-cc-ospf-flooding-reduction-00 (4 authors) presented. >>- Serious problems immediately found during presentation -- not fully >> baked. >> >> - Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author) >> - Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author) >> - Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised >> - Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors) >> - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*. >> - Does not specify distributed algorithm only how to indicate one in use, >> small change. >> >> - Jul 2, 2018 draft-cc-ospf-flooding-reduction-02 published >> >> - IETF 102 (Jul 14, 2018) >> - draft-li-dynamic-flooding-05 presented. >> - draft-cc-ospf-flooding-reduction-02 presented. >> >> - Sep 12, 2018 draft-cc-ospf-flooding-reduction-03 (4 authors) >> - *LARGE CHANGE ADDS NEW CENTRALIZED SOLUTION*. >> >> - Sep 20, 2018 draft-cc-ospf-flooding-reduction-04 (4 authors) >> >> - Oct 21, 2018 draft-li-lsr-dynamic-flooding-00 and -01 (5 authors) >> >> - IETF 103 (Nov 3, 2018) >> >> - Chairs give direction >> >>- draft-li-lsr-dynamic-flooding-05 having come first, being well written >> and not >> specifying a distributed algorithm (merely allowing for one) is the >> correct vehicle >> to adopt as a base document. >> >>- Distributed algorithm work (the original basis for >> draft-cc-ospf-flooding-reduction) >> should continue as a separate document form the base which would thus >> we have no >> conflicts. >> >> - In the meantime the authors try and merge work, this fails. >> >> - Dec 3, 2018 draft-li-lsr-dynamic-flooding-02 (7 authors)
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
In favor! Regards, Jeff > On Feb 1, 2019, at 08:02, Les Ginsberg (ginsberg) wrote: > > I am in favor of this proposal. > > Les > >> -Original Message- >> From: Lsr On Behalf Of Christian Hopps >> Sent: Friday, February 01, 2019 4:26 AM >> To: lsr@ietf.org >> Cc: cho...@chopps.org >> Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] >> >> >> Summary of where we are at with dynamic flooding reduction: >> >> - We have a well written original work that came first and described the >> problems as well as a TLVs to allow for a centralized solution (draft-li- >> dyanmic-flooding). We do not need to standardize the centralized algorithm. >> >> - A small change to this work allowed for distributed algorithms and for >> outside work on distributed algorithms to continue in parallel. >> >> - We have another original work that started primarily as a distributed >> algorithm >> (draft-cc-ospf-flooding-reduction) >> >> - Finally we also have: >> - Cross-pollination of ideas. >> - Failed attempts at merging. >> - An authors list "Arms-Race". >> >> Moving forward: >> >> - During IETF 103 I proposed we have no conflict if we: >> >> 1) adopt draft-li-lsr-dyanmic-flooding as the base WG document. >> 2) have authors of draft-cc-lsr-flooding-reduction work on a distributed >> algorithm as they started with. >> >> - Acee agreed during the meeting (as chair) that this was the best way >> forward. We had some agreement form the floor as well. >> >> - Any good ideas regarding the distribution of a centralized topology can be >> debated and added (with appropriate attribution) to the base document >> after we adopt one. >> >> - This is what happens when we adopt a document as WG work, we work on >> it. >> >> - The original authors of the distributed solution can continue to work on >> their distributed algorithm in a separate document which would also need >> standardization. >> >> Does anyone see a serious problem with this path forward? >> >> Thanks, >> Chris & Acee. >> LSR Chairs. >> >> Christian Hopps writes: >> >>> We've had the authors of the individual conflicting drafts take a shot at >> merging their work. >>> >>> This has failed. >>> >>> Here is the full history (which I also summarized during IETF103 as well). I >> will send a second email discussing this. >>> >>> - Jan 2, 2018 Publication: draft-li-dynamic-flooding and drfat-li-dynamic- >> flooding-isis >>> published centralized solution. >>> >>> - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and >>> draft-cc-ospf- >> flooding-reduction >>> published distributed solution. >>> - mention of centralized solution asserting it is not good choice. >>> >>> - IETF 101 (Mar 2018) >>> - Video: >> https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T- >> 6ZTP5j_HaBNdfPbgxGIp22cnaWS >>> - Minutes: https://datatracker.ietf.org/meeting/101/materials/minutes- >> 101-lsr-00 >>> - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101 >>>- Generally well received. >>> - draft-cc-ospf-flooding-reduction-00 (4 authors) presented. >>>- Serious problems immediately found during presentation -- not fully >> baked. >>> >>> - Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author) >>> - Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author) >>> - Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised >>> - Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors) >>> - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*. >>> - Does not specify distributed algorithm only how to indicate one in use, >> small change. >>> >>> - Jul 2, 2018 draft-cc-ospf-flooding-reduction-02 published >>> >>> - IETF 102 (Jul 14, 2018) >>> - draft-li-dynamic-flooding-05 presented. >>> - draft-cc-ospf-flooding-reduction-02 presented. >>> >>> - Sep 12, 2018 draft-cc-ospf-flooding-reduction-03 (4 authors) >>> - *LARGE CHANGE ADDS NEW CENTRALIZED SOLUTION*. >>> >>> - Sep 20, 2018 draft-cc-ospf-flooding-reduction-04 (4 authors) >>> >>> - Oct 21, 2018 draft-li-lsr-dynamic-flooding-00 and -01 (5 authors) >>> >>> - IETF 103 (Nov 3, 2018) >>> >>> - Chairs give direction >>> >>>- draft-li-lsr-dynamic-flooding-05 having come first, being well written >> and not >>> specifying a distributed algorithm (merely allowing for one) is the >>> correct >> vehicle >>> to adopt as a base document. >>> >>>- Distributed algorithm work (the original basis for >>> draft-cc-ospf-flooding- >> reduction) >>> should continue as a separate document form the base which would >> thus we have no >>> conflicts. >>> >>> - In the meantime the authors try and merge work, this fails. >>> >>> - Dec 3, 2018 draft-li-lsr-dynamic-flooding-02 (7 authors) >>> >>> - Dec 10, 2018 draft-cc-lsr-flooding-reduction-00 (4 authors) >>> >>> - Jan 7, 2019 draft-cc-lsr-flooding-reduction-01 (8 authors) > > ___ > Lsr mailing list > Lsr@ietf.org >
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Hi Chris, sounds good to me. thanks, Peter On 01/02/2019 13:25 , Christian Hopps wrote: Summary of where we are at with dynamic flooding reduction: - We have a well written original work that came first and described the problems as well as a TLVs to allow for a centralized solution (draft-li-dyanmic-flooding). We do not need to standardize the centralized algorithm. - A small change to this work allowed for distributed algorithms and for outside work on distributed algorithms to continue in parallel. - We have another original work that started primarily as a distributed algorithm (draft-cc-ospf-flooding-reduction) - Finally we also have: - Cross-pollination of ideas. - Failed attempts at merging. - An authors list "Arms-Race". Moving forward: - During IETF 103 I proposed we have no conflict if we: 1) adopt draft-li-lsr-dyanmic-flooding as the base WG document. 2) have authors of draft-cc-lsr-flooding-reduction work on a distributed algorithm as they started with. - Acee agreed during the meeting (as chair) that this was the best way forward. We had some agreement form the floor as well. - Any good ideas regarding the distribution of a centralized topology can be debated and added (with appropriate attribution) to the base document after we adopt one. - This is what happens when we adopt a document as WG work, we work on it. - The original authors of the distributed solution can continue to work on their distributed algorithm in a separate document which would also need standardization. Does anyone see a serious problem with this path forward? Thanks, Chris & Acee. LSR Chairs. Christian Hopps writes: We've had the authors of the individual conflicting drafts take a shot at merging their work. This has failed. Here is the full history (which I also summarized during IETF103 as well). I will send a second email discussing this. - Jan 2, 2018 Publication: draft-li-dynamic-flooding and drfat-li-dynamic-flooding-isis published centralized solution. - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and draft-cc-ospf-flooding-reduction published distributed solution. - mention of centralized solution asserting it is not good choice. - IETF 101 (Mar 2018) - Video: https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS - Minutes: https://datatracker.ietf.org/meeting/101/materials/minutes-101-lsr-00 - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101 - Generally well received. - draft-cc-ospf-flooding-reduction-00 (4 authors) presented. - Serious problems immediately found during presentation -- not fully baked. - Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author) - Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author) - Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised - Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors) - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*. - Does not specify distributed algorithm only how to indicate one in use, small change. - Jul 2, 2018 draft-cc-ospf-flooding-reduction-02 published - IETF 102 (Jul 14, 2018) - draft-li-dynamic-flooding-05 presented. - draft-cc-ospf-flooding-reduction-02 presented. - Sep 12, 2018 draft-cc-ospf-flooding-reduction-03 (4 authors) - *LARGE CHANGE ADDS NEW CENTRALIZED SOLUTION*. - Sep 20, 2018 draft-cc-ospf-flooding-reduction-04 (4 authors) - Oct 21, 2018 draft-li-lsr-dynamic-flooding-00 and -01 (5 authors) - IETF 103 (Nov 3, 2018) - Chairs give direction - draft-li-lsr-dynamic-flooding-05 having come first, being well written and not specifying a distributed algorithm (merely allowing for one) is the correct vehicle to adopt as a base document. - Distributed algorithm work (the original basis for draft-cc-ospf-flooding-reduction) should continue as a separate document form the base which would thus we have no conflicts. - In the meantime the authors try and merge work, this fails. - Dec 3, 2018 draft-li-lsr-dynamic-flooding-02 (7 authors) - Dec 10, 2018 draft-cc-lsr-flooding-reduction-00 (4 authors) - Jan 7, 2019 draft-cc-lsr-flooding-reduction-01 (8 authors) ___ 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] Moving Forward [Re: Flooding Reduction Draft Redux]
Agreed Cheers Dave -Original Message- From: Lsr On Behalf Of Christian Hopps Sent: Friday, February 1, 2019 4:26 AM To: lsr@ietf.org Cc: cho...@chopps.org Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Summary of where we are at with dynamic flooding reduction: - We have a well written original work that came first and described the problems as well as a TLVs to allow for a centralized solution (draft-li-dyanmic-flooding). We do not need to standardize the centralized algorithm. - A small change to this work allowed for distributed algorithms and for outside work on distributed algorithms to continue in parallel. - We have another original work that started primarily as a distributed algorithm (draft-cc-ospf-flooding-reduction) - Finally we also have: - Cross-pollination of ideas. - Failed attempts at merging. - An authors list "Arms-Race". Moving forward: - During IETF 103 I proposed we have no conflict if we: 1) adopt draft-li-lsr-dyanmic-flooding as the base WG document. 2) have authors of draft-cc-lsr-flooding-reduction work on a distributed algorithm as they started with. - Acee agreed during the meeting (as chair) that this was the best way forward. We had some agreement form the floor as well. - Any good ideas regarding the distribution of a centralized topology can be debated and added (with appropriate attribution) to the base document after we adopt one. - This is what happens when we adopt a document as WG work, we work on it. - The original authors of the distributed solution can continue to work on their distributed algorithm in a separate document which would also need standardization. Does anyone see a serious problem with this path forward? Thanks, Chris & Acee. LSR Chairs. Christian Hopps writes: > We've had the authors of the individual conflicting drafts take a shot at > merging their work. > >This has failed. > > Here is the full history (which I also summarized during IETF103 as well). I > will send a second email discussing this. > > - Jan 2, 2018 Publication: draft-li-dynamic-flooding and > drfat-li-dynamic-flooding-isis > published centralized solution. > > - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and > draft-cc-ospf-flooding-reduction > published distributed solution. > - mention of centralized solution asserting it is not good choice. > > - IETF 101 (Mar 2018) > - Video: > https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS > - Minutes: > https://datatracker.ietf.org/meeting/101/materials/minutes-101-lsr-00 > - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101 > - Generally well received. > - draft-cc-ospf-flooding-reduction-00 (4 authors) presented. > - Serious problems immediately found during presentation -- not fully > baked. > > - Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author) > - Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author) > - Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised > - Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors) > - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*. > - Does not specify distributed algorithm only how to indicate one in use, > small change. > > - Jul 2, 2018 draft-cc-ospf-flooding-reduction-02 published > > - IETF 102 (Jul 14, 2018) > - draft-li-dynamic-flooding-05 presented. > - draft-cc-ospf-flooding-reduction-02 presented. > > - Sep 12, 2018 draft-cc-ospf-flooding-reduction-03 (4 authors) > - *LARGE CHANGE ADDS NEW CENTRALIZED SOLUTION*. > > - Sep 20, 2018 draft-cc-ospf-flooding-reduction-04 (4 authors) > > - Oct 21, 2018 draft-li-lsr-dynamic-flooding-00 and -01 (5 authors) > > - IETF 103 (Nov 3, 2018) > > - Chairs give direction > > - draft-li-lsr-dynamic-flooding-05 having come first, being well written > and not > specifying a distributed algorithm (merely allowing for one) is the > correct vehicle > to adopt as a base document. > > - Distributed algorithm work (the original basis for > draft-cc-ospf-flooding-reduction) > should continue as a separate document form the base which would thus > we have no > conflicts. > > - In the meantime the authors try and merge work, this fails. > > - Dec 3, 2018 draft-li-lsr-dynamic-flooding-02 (7 authors) > > - Dec 10, 2018 draft-cc-lsr-flooding-reduction-00 (4 authors) > > - Jan 7, 2019 draft-cc-lsr-flooding-reduction-01 (8 authors) ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
+1 Tony > On Feb 1, 2019, at 5:18 AM, John E Drake wrote: > > Chris & Acee, > > This looks fine to me. > > Yours Irrespectively, > > John > >> -Original Message- >> From: Lsr On Behalf Of Christian Hopps >> Sent: Friday, February 1, 2019 7:26 AM >> To: lsr@ietf.org >> Cc: cho...@chopps.org >> Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] >> >> >> Summary of where we are at with dynamic flooding reduction: >> >> - We have a well written original work that came first and described the >> problems as well as a TLVs to allow for a centralized solution >> (draft-li-dyanmic- >> flooding). We do not need to standardize the centralized algorithm. >> >> - A small change to this work allowed for distributed algorithms and for >> outside >> work on distributed algorithms to continue in parallel. >> >> - We have another original work that started primarily as a distributed >> algorithm >> (draft-cc-ospf-flooding-reduction) >> >> - Finally we also have: >> - Cross-pollination of ideas. >> - Failed attempts at merging. >> - An authors list "Arms-Race". >> >> Moving forward: >> >> - During IETF 103 I proposed we have no conflict if we: >> >> 1) adopt draft-li-lsr-dyanmic-flooding as the base WG document. >> 2) have authors of draft-cc-lsr-flooding-reduction work on a distributed >> algorithm as they started with. >> >> - Acee agreed during the meeting (as chair) that this was the best way >> forward. >> We had some agreement form the floor as well. >> >> - Any good ideas regarding the distribution of a centralized topology can be >> debated and added (with appropriate attribution) to the base document after >> we >> adopt one. >> >> - This is what happens when we adopt a document as WG work, we work on it. >> >> - The original authors of the distributed solution can continue to work on >> their >> distributed algorithm in a separate document which would also need >> standardization. >> >> Does anyone see a serious problem with this path forward? >> >> Thanks, >> Chris & Acee. >> LSR Chairs. >> >> Christian Hopps writes: >> >>> We've had the authors of the individual conflicting drafts take a shot at >> merging their work. >>> >>> This has failed. >>> >>> Here is the full history (which I also summarized during IETF103 as well). >>> I will >> send a second email discussing this. >>> >>> - Jan 2, 2018 Publication: draft-li-dynamic-flooding and drfat-li-dynamic- >> flooding-isis >>> published centralized solution. >>> >>> - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and >>> draft-cc-ospf- >> flooding-reduction >>> published distributed solution. >>> - mention of centralized solution asserting it is not good choice. >>> >>> - IETF 101 (Mar 2018) >>> - Video: https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T- >> 6ZTP5j_HaBNdfPbgxGIp22cnaWS >>> - Minutes: https://datatracker.ietf.org/meeting/101/materials/minutes-101- >> lsr-00 >>> - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101 >>>- Generally well received. >>> - draft-cc-ospf-flooding-reduction-00 (4 authors) presented. >>>- Serious problems immediately found during presentation -- not fully >>> baked. >>> >>> - Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author) >>> - Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author) >>> - Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised >>> - Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors) >>> - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*. >>> - Does not specify distributed algorithm only how to indicate one in use, >>> small >> change. >>> >>> - Jul 2, 2018 draft-cc-ospf-flooding-reduction-02 published >>> >>> - IETF 102 (Jul 14, 2018) >>> - draft-li-dynamic-flooding-05 presented. >>> - draft-cc-ospf-flooding-reduction-02 presented. >>> >>> - Sep 12, 2018 draft-cc-ospf-flooding-reduction-03 (4 authors) >>> - *LARGE CHANGE ADDS NEW CENTRALIZED SOLUTION*. >>> >>> - Sep 20, 2018 draft-cc-ospf-flooding-reduction-04 (4 authors) >>> >>> - Oct 21, 2018 draft-li-lsr-dynamic-flooding-00 and -01 (5 authors) >>> >>> - IETF 103 (Nov 3, 2018) >>> >>> - Chairs give direction >>> >>>- draft-li-lsr-dynamic-flooding-05 having come first, being well written >>> and >> not >>> specifying a distributed algorithm (merely allowing for one) is the >>> correct >> vehicle >>> to adopt as a base document. >>> >>>- Distributed algorithm work (the original basis for >>> draft-cc-ospf-flooding- >> reduction) >>> should continue as a separate document form the base which would thus >> we have no >>> conflicts. >>> >>> - In the meantime the authors try and merge work, this fails. >>> >>> - Dec 3, 2018 draft-li-lsr-dynamic-flooding-02 (7 authors) >>> >>> - Dec 10, 2018 draft-cc-lsr-flooding-reduction-00 (4 authors) >>> >>> - Jan 7, 2019 draft-cc-lsr-flooding-reduction-01 (8 authors) > >
Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
Chris & Acee, This looks fine to me. Yours Irrespectively, John > -Original Message- > From: Lsr On Behalf Of Christian Hopps > Sent: Friday, February 1, 2019 7:26 AM > To: lsr@ietf.org > Cc: cho...@chopps.org > Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] > > > Summary of where we are at with dynamic flooding reduction: > > - We have a well written original work that came first and described the > problems as well as a TLVs to allow for a centralized solution > (draft-li-dyanmic- > flooding). We do not need to standardize the centralized algorithm. > > - A small change to this work allowed for distributed algorithms and for > outside > work on distributed algorithms to continue in parallel. > > - We have another original work that started primarily as a distributed > algorithm >(draft-cc-ospf-flooding-reduction) > > - Finally we also have: >- Cross-pollination of ideas. >- Failed attempts at merging. >- An authors list "Arms-Race". > > Moving forward: > > - During IETF 103 I proposed we have no conflict if we: > >1) adopt draft-li-lsr-dyanmic-flooding as the base WG document. >2) have authors of draft-cc-lsr-flooding-reduction work on a distributed > algorithm as they started with. > > - Acee agreed during the meeting (as chair) that this was the best way > forward. > We had some agreement form the floor as well. > > - Any good ideas regarding the distribution of a centralized topology can be > debated and added (with appropriate attribution) to the base document after we > adopt one. > > - This is what happens when we adopt a document as WG work, we work on it. > > - The original authors of the distributed solution can continue to work on > their > distributed algorithm in a separate document which would also need > standardization. > > Does anyone see a serious problem with this path forward? > > Thanks, > Chris & Acee. > LSR Chairs. > > Christian Hopps writes: > > > We've had the authors of the individual conflicting drafts take a shot at > merging their work. > > > >This has failed. > > > > Here is the full history (which I also summarized during IETF103 as well). > > I will > send a second email discussing this. > > > > - Jan 2, 2018 Publication: draft-li-dynamic-flooding and drfat-li-dynamic- > flooding-isis > > published centralized solution. > > > > - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and > > draft-cc-ospf- > flooding-reduction > > published distributed solution. > > - mention of centralized solution asserting it is not good choice. > > > > - IETF 101 (Mar 2018) > > - Video: https://www.youtube.com/watch?v=qHmT4ytMn4w=PLC86T- > 6ZTP5j_HaBNdfPbgxGIp22cnaWS > > - Minutes: https://datatracker.ietf.org/meeting/101/materials/minutes-101- > lsr-00 > > - draft-li-dynamic-flooding-02 presented (1 author). at IETF 101 > > - Generally well received. > > - draft-cc-ospf-flooding-reduction-00 (4 authors) presented. > > - Serious problems immediately found during presentation -- not fully > > baked. > > > > - Mar 18, 2018 draft-li-dynamic-flooding-03 published (1 author) > > - Mar 27, 2018 draft-li-dynamic-flooding-04 published (1 author) > > - Apr 20, 2018 draft-cc-ospf-flooding-reduction-01 revised > > - Jun 28, 2018 draft-li-dynamic-flooding-05 published (2 authors) > > - *SMALL CHANGE TO SUPPORT DISTRIBUTED ALGORITHM*. > > - Does not specify distributed algorithm only how to indicate one in use, > > small > change. > > > > - Jul 2, 2018 draft-cc-ospf-flooding-reduction-02 published > > > > - IETF 102 (Jul 14, 2018) > > - draft-li-dynamic-flooding-05 presented. > > - draft-cc-ospf-flooding-reduction-02 presented. > > > > - Sep 12, 2018 draft-cc-ospf-flooding-reduction-03 (4 authors) > > - *LARGE CHANGE ADDS NEW CENTRALIZED SOLUTION*. > > > > - Sep 20, 2018 draft-cc-ospf-flooding-reduction-04 (4 authors) > > > > - Oct 21, 2018 draft-li-lsr-dynamic-flooding-00 and -01 (5 authors) > > > > - IETF 103 (Nov 3, 2018) > > > > - Chairs give direction > > > > - draft-li-lsr-dynamic-flooding-05 having come first, being well > > written and > not > > specifying a distributed algorithm (merely allowing for one) is the > > correct > vehicle > > to adopt as a base document. > > > > - Distributed algorithm work (the original basis for > > draft-cc-ospf-flooding- > reduction) > > should continue as a separate document form the base which would thus > we have no > > conflicts. > > > > - In the meantime the authors try and merge work, this fails. > > > > - Dec 3, 2018 draft-li-lsr-dynamic-flooding-02 (7 authors) > > > > - Dec 10, 2018 draft-cc-lsr-flooding-reduction-00 (4 authors) > > > > - Jan 7, 2019 draft-cc-lsr-flooding-reduction-01 (8 authors) ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
