Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

[Mankamana Mishra (mankamis)]

Support. 

Thanks 
Mankamana 
 

-Original Message-
From: Lsr  on behalf of Christian Hopps 

Date: Monday, February 11, 2019 at 2:47 AM
To: "lsr@ietf.org" 
Cc: "lsr-cha...@ietf.org" , "lsr-...@ietf.org" 
, "cho...@chopps.org" 
Subject: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.


Hi Folks,

We are starting a 2 week adoption call on draft-li-lsr-dynamic-flooding-02.

The aim of this document is to describe the problem space and standardize a 
way to signal dynamic flooding information. It does not standardize any 
specific algorithm for flooding topology creation.

Authors please respond indicating if you are aware of any IPR related to 
this work.

We also have another draft (draft-cc-lsr-flooding-reduction-01) that 
started as a distributed flooding topology algorithm and morphed into that plus 
competing ideas on signaling of flooding topology information. The intent after 
adoption of draft-li-lsr-dynamic-flooding-02 is two-fold. One, the WG can 
discuss adding any signaling ideas from this work to the adopted signaling 
draft (with proper attribution given as appropriate), and two, for the authors 
of draft-cc-lsr-flooding-reduction-01 to publish a new document without the 
signaling portion and instead focus on their flooding topology algorithm. This 
new focused document can be considered in parallel along with the other 
algorithm work that has been proposed.

Flooding topology creation is seen as a hard problem for which we don't 
expect a one-size-fits-all solution. Taking the steps outlined above will help 
us move forward on the solutions.

Thanks,
Chris & Acee.
LSR WG Chairs.


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

[LEI LIU]

Hi All,

In favor of adopting both drafts in parallel, and then one draft focuses on
the centralized solution and the other on the distributed solution.

Best regards,
Lei

On Mon, Feb 11, 2019 at 2:47 AM Christian Hopps  wrote:

>
> Hi Folks,
>
> We are starting a 2 week adoption call on draft-li-lsr-dynamic-flooding-02.
>
> The aim of this document is to describe the problem space and standardize
> a way to signal dynamic flooding information. It does not standardize any
> specific algorithm for flooding topology creation.
>
> Authors please respond indicating if you are aware of any IPR related to
> this work.
>
> We also have another draft (draft-cc-lsr-flooding-reduction-01) that
> started as a distributed flooding topology algorithm and morphed into that
> plus competing ideas on signaling of flooding topology information. The
> intent after adoption of draft-li-lsr-dynamic-flooding-02 is two-fold. One,
> the WG can discuss adding any signaling ideas from this work to the adopted
> signaling draft (with proper attribution given as appropriate), and two,
> for the authors of draft-cc-lsr-flooding-reduction-01 to publish a new
> document without the signaling portion and instead focus on their flooding
> topology algorithm. This new focused document can be considered in parallel
> along with the other algorithm work that has been proposed.
>
> Flooding topology creation is seen as a hard problem for which we don't
> expect a one-size-fits-all solution. Taking the steps outlined above will
> help us move forward on the solutions.
>
> Thanks,
> Chris & Acee.
> LSR WG Chairs.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

[Acee Lindem (acee)]

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  >> >
> >> *Date: *Saturday, February 2, 2019 at 12:27 AM
> >> *To: *Christian Hopps mailto:cho...@chopps.org>>,
> >> "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 

Re: [Lsr] 答复: WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

[John E Drake]

Chris,

Well put.

Yours Irrespectively,

John

> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Thursday, February 14, 2019 10:56 AM
> To: lsr@ietf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; 'Christian Hopps'
> ; Aijun Wang 
> Subject: Re: [Lsr] 答复: WG Adoption Call for draft-li-lsr-dynamic-flooding-02 +
> IPR poll.
> 
> 
> Hi folks,
> 
> It's not useful for people to be adding a bunch of extra qualifications and
> caveats to the adoption poll.
> 
> This is not a dual adoption poll. We are not calling for adoption of an 
> unwritten,
> unfinished algorithm document. That makes no sense; we adopt reviewed
> acceptable work, not the promise of it. We're also not going to hold up
> standardizing the signaling work waiting on unfinished algorithm work, that's
> literally the opposite of the goal here which is to un-tie these two things 
> so we
> can make progress on both in parallel.
> 
> Thanks,
> Chris.
> 
> Aijun Wang  writes:
> 
> > Hi, Christian:
> >
> > Supports for the adoption of two drafts at the same time, in which
> > one(draft-li-lsr-dynamic-flooding-02) focuses on the centralized mode
> > and the other(draft-cc-lsr-flooding-reduction-01) focuses on the
> > distributed mode.
> >
> > The centralized mode for is one straightforward way to realize the
> > flooding reduction, and I admire Tony Li give his solution first. But
> > from the consideration of solution robustness, the distributed mode
> > may be more promising.
> > My consideration for distributed mode is that it should not cover only
> > the algorithm, more contents need to be standardized in future. Huaimo
> > has one good start point for distributed mode, and he also gives
> > abundant thoughts for the centralized mode that the current version of
> > draft-li-lsr-dynamic-flooding-02 has not covered yet.
> >
> > Proposal for the name of two drafts may be
> > draft-ietf-lsr-flooding-reduction-centralized-mode and
> > draft-ietf-lsr-flooding-reduction-distributed-mode.
> >
> >
> > Best Regards.
> >
> > Aijun Wang
> > Network R and Operation Support Department China Telecom Corporation
> > Limited Beijing Research Institute,Beijing, China.
> >
> > -邮件原件-
> > 发件人: Christian Hopps [mailto:cho...@chopps.org]
> > 发送时间: 2019年2月11日 18:45
> > 收件人: lsr@ietf.org
> > 抄送: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org
> > 主题: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR
> > poll.
> >
> >
> > Hi Folks,
> >
> > We are starting a 2 week adoption call on draft-li-lsr-dynamic-flooding-02.
> >
> > The aim of this document is to describe the problem space and
> > standardize a way to signal dynamic flooding information. It does not
> > standardize any specific algorithm for flooding topology creation.
> >
> > Authors please respond indicating if you are aware of any IPR related
> > to this work.
> >
> > We also have another draft (draft-cc-lsr-flooding-reduction-01) that
> > started as a distributed flooding topology algorithm and morphed into
> > that plus competing ideas on signaling of flooding topology
> > information. The intent after adoption of
> > draft-li-lsr-dynamic-flooding-02 is two-fold. One, the WG can discuss
> > adding any signaling ideas from this work to the adopted signaling
> > draft (with proper attribution given as appropriate), and two, for the
> > authors of draft-cc-lsr-flooding-reduction-01 to publish a new
> > document without the signaling portion and instead focus on their
> > flooding topology algorithm. This new focused document can be considered in
> parallel along with the other algorithm work that has been proposed.
> >
> > Flooding topology creation is seen as a hard problem for which we
> > don't expect a one-size-fits-all solution. Taking the steps outlined
> > above will help us move forward on the solutions.
> >
> > Thanks,
> > Chris & Acee.
> > LSR WG Chairs.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 答复: WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

[Christian Hopps]

Hi folks,

It's not useful for people to be adding a bunch of extra qualifications and 
caveats to the adoption poll.

This is not a dual adoption poll. We are not calling for adoption of an 
unwritten, unfinished algorithm document. That makes no sense; we adopt 
reviewed acceptable work, not the promise of it. We're also not going to hold 
up standardizing the signaling work waiting on unfinished algorithm work, 
that's literally the opposite of the goal here which is to un-tie these two 
things so we can make progress on both in parallel.

Thanks,
Chris.

Aijun Wang  writes:


Hi, Christian:

Supports for the adoption of two drafts at the same time, in which
one(draft-li-lsr-dynamic-flooding-02) focuses on the centralized mode and
the other(draft-cc-lsr-flooding-reduction-01) focuses on the distributed
mode.

The centralized mode for is one straightforward way to realize the flooding
reduction, and I admire Tony Li give his solution first. But from the
consideration of solution robustness, the distributed mode may be more
promising.
My consideration for distributed mode is that it should not cover only the
algorithm, more contents need to be standardized in future. Huaimo has one
good start point for distributed mode, and he also gives abundant thoughts
for the centralized mode that the current version of
draft-li-lsr-dynamic-flooding-02 has not covered yet.

Proposal for the name of two drafts may be
draft-ietf-lsr-flooding-reduction-centralized-mode and
draft-ietf-lsr-flooding-reduction-distributed-mode.


Best Regards.

Aijun Wang
Network R and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

-邮件原件-
发件人: Christian Hopps [mailto:cho...@chopps.org]
发送时间: 2019年2月11日 18:45
收件人: lsr@ietf.org
抄送: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org
主题: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR
poll.


Hi Folks,

We are starting a 2 week adoption call on draft-li-lsr-dynamic-flooding-02.

The aim of this document is to describe the problem space and standardize a
way to signal dynamic flooding information. It does not standardize any
specific algorithm for flooding topology creation.

Authors please respond indicating if you are aware of any IPR related to
this work.

We also have another draft (draft-cc-lsr-flooding-reduction-01) that started
as a distributed flooding topology algorithm and morphed into that plus
competing ideas on signaling of flooding topology information. The intent
after adoption of draft-li-lsr-dynamic-flooding-02 is two-fold. One, the WG
can discuss adding any signaling ideas from this work to the adopted
signaling draft (with proper attribution given as appropriate), and two, for
the authors of draft-cc-lsr-flooding-reduction-01 to publish a new document
without the signaling portion and instead focus on their flooding topology
algorithm. This new focused document can be considered in parallel along
with the other algorithm work that has been proposed.

Flooding topology creation is seen as a hard problem for which we don't
expect a one-size-fits-all solution. Taking the steps outlined above will
help us move forward on the solutions.

Thanks,
Chris & Acee.
LSR WG Chairs.


signature.asc
Description: PGP signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

[John E Drake]

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  >> >
> >> *Date: *Saturday, February 2, 2019 at 12:27 AM
> >> *To: *Christian Hopps mailto:cho...@chopps.org>>,
> >> "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?
> >>
> >>
> >>