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

From: Christian Hopps <[email-masked]>
Date: Mon, 11 Feb 2019 05:44:59 -0500

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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 11 Feb 2019 13:22:55 +0000

Speaking as a WG member:

I support adoption of draft-li-lsr-dynamic-flooding-02 as infrastructure for flooding reduction mechanisms based on a separate flooding topology. Work on individual flooding reduction/topology determination algorithms can proceed in separate drafts. 

Thanks,
Acee

On 2/11/19, 5:47 AM, "Christian Hopps" <[email-masked]> wrote:

    Hi Folks,

    

    
    Thanks,
    Chris & Acee.
    LSR WG Chairs.

---

From: [email-masked]
Date: Mon, 11 Feb 2019 07:08:51 -0800

+1 as author.

There is an IPR filing on this technology, specifying the “don’t sue us, we won’t sue you” language.  See https://datatracker.ietf.org/ipr/3361/ <https://datatracker.ietf.org/ipr/3361/>

We are very interested in moving forward together on this work.

Regards,
Tony

> On Feb 11, 2019, at 2:44 AM, Christian Hopps <[email-masked]> wrote:
> 
> 
> Hi Folks,
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 11 Feb 2019 16:14:58 +0100

Support.

r.

On Mon, Feb 11, 2019 at 11:47 AM Christian Hopps <[email-masked]> wrote:

> 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.
>
> 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.

---

From: Lizhenbin <[email-masked]>
Date: Mon, 11 Feb 2019 15:19:54 +0000

Hi Chris,
1. I have doubt about "The aim of this document is to describe the problem space and standardize a way to signal dynamic flooding information.". Does the aim mean the draft describes the problem space and standardize the way for the centralized solution or mean the draft will standardize the way used for both the centralized solutions and the distributed solutions?
2. I explained in the previous mail the distributed solution includes more than the algorithms defined in the draft-cc-lsr-flooding-reduction-00  and the overlapped signallings  defined in the draft-cc-lsr-flooding-reduction-00/draft-li-dynamic-flooding-03. For example, it may define the standardized procedures for the distributed solutions. If there is such part, is it defined by draft-li-lsr-dynamic-flooding-02 or draft-cc-lsr-flooding-reduction?

I hope you could clarify the above issues firstly for the adoption.

Thanks & Regards,
Zhenbin (Robin) 

________________________________________
发件人: Lsr [[email-masked]] 代表 Christian Hopps [[email-masked]]
发送时间: 2019年2月11日 18:44
收件人: [email-masked]
抄送: [email-masked]; [email-masked]; [email-masked]
主题: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

Hi Folks,

Thanks,
Chris & Acee.
LSR WG Chairs.

---

From: Edward <[email-masked]>
Date: Mon, 11 Feb 2019 10:07:20 -0800

Support.

---

From: Christian Hopps <[email-masked]>
Date: Mon, 11 Feb 2019 13:15:26 -0500

> On Feb 11, 2019, at 10:19 AM, Lizhenbin <[email-masked]> wrote:
> 
> Hi Chris,

It does not standardize any algorithms. For a centralized algorithm (unspecified) use one has to distribute the flooding topology it does specify this. It also supplies the means to signal what distributed algorithm is in use (a value).

> 2. I explained in the previous mail the distributed solution includes more than the algorithms defined in the draft-cc-lsr-flooding-reduction-00  and the overlapped signallings  defined in the draf…

How a distributed algorithm decides to implement itself is up to that algorithm. This is not part of the signaled information. Again, the only thing that I am aware of in draft-li-dynamic-flooding in regards to distributed algorithms is what's required for us to use them as they get defined in the future, i.e., a way to signal which one is in use.

Thanks,
Chris.

---

From: David Allan I <[email-masked]>
Date: Mon, 11 Feb 2019 18:41:39 +0000

Support

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Monday, February 11, 2019 5:23 AM
To: Christian Hopps <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

Speaking as a WG member:

Thanks,
Acee

    Hi Folks,

    Thanks,
    Chris & Acee.
    LSR WG Chairs.

---

From: steve ulrich <[email-masked]>
Date: Mon, 11 Feb 2019 12:46:38 -0600

support.

-- 
steve ulrich (sulrich@botwerks.*)

---

From: Peter Psenak <[email-masked]>
Date: Mon, 11 Feb 2019 21:21:09 +0100

Hi Chris,

support as coauthor.

Not aware of any IPR at this point.

thanks,
Peter

On 11/02/2019 11:44 , Christian Hopps wrote:
> 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.
>
> 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.
>
> 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.
>
>

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Mon, 11 Feb 2019 20:23:02 +0000

Support the adoption of the draft.

Regards,
- Naiming

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 11 Feb 2019 20:27:33 +0000

Support adoption (as co-author).

I am not aware of any relevant IPR.

   Les

> From: Lsr <[email-masked]> On Behalf Of Christian Hopps
> Sent: Monday, February 11, 2019 2:45 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.
> 
> 
> Hi Folks,
> 
> 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
> 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.
> 
> 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.

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 11 Feb 2019 13:24:21 -0800

Yes/support

Cheers,
Jeff

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 14 Feb 2019 10:37:34 +0800

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&D and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

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

Hi Folks,

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.

Thanks,
Chris & Acee.
LSR WG Chairs.

---

From: Lizhenbin <[email-masked]>
Date: Thu, 14 Feb 2019 06:20:39 +0000

Hi Chris & Acee,
I have explained my concerns the previous mails. In order to avoid unnecessary overlap, I supports the adoption of the drafts like follows:
- both drafts are adopted at the same time keeping draft-li-dynamic-flooding focus on the centralized solution and draft-cc-lsr-flooding-reduction on the distributed solution.
- draft-li-dynamic-flooding can keep on refining the centralized solution without mentioning distributed solutions.
- draft-cc-lsr-flooding-reduction can keep on refining the distributed solutions. For the signaling which can be shared by the two modes, the draft can indicate the distributed solutions reuse the signaling defined in draft-li-dynamic-flooding without defining new signaling. 
- both drafts change the draft names to reflect different solutions without causing confusion.

Thanks & Regards,
Zhenbin (Robin)

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

Hi Folks,

Thanks,
Chris & Acee.
LSR WG Chairs.

---

From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[email-masked]>
Date: Thu, 14 Feb 2019 06:33:14 +0000

Supports for the adoption of two drafts at the same time +1

BR,

Yunan

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Aijun Wang
Sent: Thursday, February 14, 2019 10:38 AM
To: 'Christian Hopps' <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Lsr] 答复: WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

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&D and Operation Support Department China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

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

Hi Folks,

Thanks,
Chris & Acee.
LSR WG Chairs.

---

From: Huzhibo <[email-masked]>
Date: Thu, 14 Feb 2019 06:56:20 +0000

Supports for the adoption of two drafts at the same time, IGP Reduce Flooding still have some problem needs to be solved, for example, how to ensure the reliability of Flooding in a multi-point failure scenario. The way to solve these problems in a distributed and centralized manner may be different. Therefore, it is recommended to promote separately and continue to conduct research in their respective directions.

Ths

Zhibo

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Aijun Wang
Sent: Thursday, February 14, 2019 10:38 AM
To: 'Christian Hopps' <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Lsr] 答复: WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

Hi, Christian:

Best Regards.

Aijun Wang

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

Hi Folks,

Thanks,
Chris & Acee.
LSR WG Chairs.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 14 Feb 2019 07:10:15 +0000

+1. 

Support to start the adoption poll on both drafts.

-Jie

> -----邮件原件-----
> 发件人: Lsr [mailto:[email-masked]] 代表 Aijun Wang
> 发送时间: 2019年2月14日 10:38
> 收件人: 'Christian Hopps' <[email-masked]>; [email-masked]
> 抄送: [email-masked]; [email-masked]
> 主题: [Lsr] 答复: WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR
> poll.
> 
> Hi, Christian:
> 
> Network R&D and Operation Support Department China Telecom Corporation
> Limited Beijing Research Institute,Beijing, China.
> 
> -----邮件原件-----

---

From: Yangang <[email-masked]>
Date: Thu, 14 Feb 2019 07:23:22 +0000

Support the adoption on these two drafts.

Yangang

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Lizhenbin
Sent: Thursday, February 14, 2019 2:21 PM
To: 'Christian Hopps' <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Lsr] 答复: WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

Hi Chris & Acee,

Thanks & Regards,
Zhenbin (Robin)

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

Hi Folks,

Thanks,
Chris & Acee.
LSR WG Chairs.

---

From: Christian Hopps <[email-masked]>
Date: Thu, 14 Feb 2019 10:56:03 -0500

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.

---

From: John E Drake <[email-masked]>
Date: Thu, 14 Feb 2019 16:00:24 +0000

Chris,

Well put.

Yours Irrespectively,

John

> Sent: Thursday, February 14, 2019 10:56 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 'Christian Hopps'
> <[email-masked]>; Aijun Wang <[email-masked]>
> 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.
> 
> > 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
> > 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.

---

From: LEI LIU <[email-masked]>
Date: Thu, 14 Feb 2019 15:38:33 -0800

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

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Thu, 14 Feb 2019 23:43:35 +0000

Support. 

Thanks 
Mankamana 

-----Original Message-----
From: Lsr <[email-masked]> on behalf of Christian Hopps <[email-masked]>
Date: Monday, February 11, 2019 at 2:47 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

    Hi Folks,

    

    
    Thanks,
    Chris & Acee.
    LSR WG Chairs.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 22 Feb 2019 10:41:08 +0000

I support the adoption of this draft by the WG.

Thanks,
Ketan

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Christian Hopps
Sent: 11 February 2019 16:15
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

Hi Folks,

Thanks,
Chris & Acee.
LSR WG Chairs.

---

From: sridhar santhanam <[email-masked]>
Date: Fri, 22 Feb 2019 13:00:14 -0800

Hi All,
          I support the adoption of this draft.

Thanks,
Sridhar.S

---

From: Huaimo Chen <[email-masked]>
Date: Sun, 24 Feb 2019 05:34:34 +0000

Some issues with draft-li-lsr-dynamic-flooding-02 not fully addressed are briefed below.

1)           There is no concrete procedure/method for fault tolerance to multiple failures. When multiple failures happen and split the flooding topology, the convergence time will be increased significantly without fault tolerance. The longer the convergence time, the more the traffic lose.

2)           The extensions to Hello protocols for enabling "temporary flooding" over a new link is not needed.

3)           The extensions to Hello protocols for requesting/signaling "temporary flooding" for a connection does not work.

In addition, for signaling the distributed solution/mode or the centralized solution/mode, a user/operator needs to configure or select a solution/mode on a node via CLI or other approach first. Which node should the user/operator use to configure/select a mode?  If the user/operator can only use the leader node in the area to configure, then it is neither convenient nor reasonable. The leader node in the area is dynamically generated. But in the distributed mode/solution, there is no leader selection (i.e., no leader should be generated).

draft-cc-lsr-flooding-reduction-01 contains solutions for some of the above issues, which should be merged based on technical merits.

Best Regards,

Huaimo

-----Original Message-----

To: [email-masked]

Hi Folks,

Thanks,

Chris & Acee.

LSR WG Chairs.

Lsr mailing list

[email-masked]

---

From: Peter Psenak <[email-masked]>
Date: Sun, 24 Feb 2019 19:47:19 +0100

Huaimo,

On 24/02/2019 06:34 , Huaimo Chen wrote:
> 1)           There is no concrete procedure/method for fault tolerance
> to multiple failures. When multiple failures happen and split the
> flooding topology, the convergence time will be increased significantly
> without fault tolerance. The longer the convergence time, the more the
> traffic lose.

there is a solution for multiple failures - see section 6.7.11.

>
>
>
> 2)           The extensions to Hello protocols for enabling “temporary
> flooding” over a new link is not needed.

not if you do flooding on every link that comes up. If you want to be 
smarter, then you need to selectively enable flooding only under 
specific conditions and that must be done from both sides of the new link.

>
>
>
> 3)           The extensions to Hello protocols for requesting/signaling
> “temporary flooding” for a connection does not work.

sorry, but if you see a problem, please provide details, saying above is 
simply unproductive.

>
>
>
> In addition, for signaling the distributed solution/mode or the
> centralized solution/mode, a user/operator needs to configure or select
> a solution/mode on a node via CLI or other approach first. Which node
> should the user/operator use to configure/select a mode?  If the
> user/operator can only use the leader node in the area to configure,
> then it is neither convenient nor reasonable. The leader node in the
> area is dynamically generated. But in the distributed mode/solution,
> there is no leader selection (i.e., no leader should be generated).

there is an area leader in both modes. In distributed mode the area 
leader is the one that advertises the algorithm that is used by all 
nodes that participates in dynamic flooding.

regards,
Peter

>
>
>
> draft-cc-lsr-flooding-reduction-01 contains solutions for some of the
> above issues, which should be merged based on technical merits.
>
>
>
> Best Regards,
>
> Huaimo
>
>
>

---

From: Christian Hopps <[email-masked]>
Date: Sun, 24 Feb 2019 18:14:12 -0500

Peter Psenak <[email-masked]> writes:

> there is an area leader in both modes. In distributed mode the area leader is
> the one that advertises the algorithm that is used by all nodes that
> participates in dynamic flooding.

I'd like to suggest that as this point is discussed we are careful to not try and replace the standard configuration mechanisms.

Thanks,
Chris.

---

From: Sri <[email-masked]>
Date: Sun, 24 Feb 2019 18:18:47 -0800

Support.

-
Sri

---

From: Tony Li <[email-masked]>
Date: Sun, 24 Feb 2019 19:40:16 -0800

> On Feb 24, 2019, at 3:14 PM, Christian Hopps <[email-masked]> wrote:
> 
>>  In distributed mode the area leader is

I appreciate the suggestion. The concern is that configuration of the algorithm selection is extremely challenging.  Suppose that
an administrator wishes to change algorithms.  If manual, individual configuration is the only possible way, then the network is
at risk while the configuration is in progress. At scale, this seemed inadvisable.  A clear, signaled change seemed like a clean and
simple synchronization point.

Tony

---

From: Christian Hopps <[email-masked]>
Date: Mon, 25 Feb 2019 07:35:08 -0500

The support was strong for adoption -- the draft-li-lsr-dynamic-flooding is adopted as a WG document.

Authors please re-issue this document using the new name 'draft-ietf-lsr-dynamic-flooding'.

We will probably need to reduce the front-page author list. Normally this needs to be 5 or less authors, or justification is required prior to publication.

Thanks,
Chris & Acee
LSR WG Chairs.

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 27 Feb 2019 05:15:46 +0000

Hi Peter,

> From: Peter Psenak [mailto:[email-masked]]
> Sent: Sunday, February 24, 2019 1:47 PM
> To: Huaimo Chen <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
> > flooding topology, the convergence time will be increased
> > significantly without fault tolerance. The longer the convergence
> > time, the more the traffic lose.
>

Section 6.7.11 just briefly mentions that the edges of split parts will determine and repair the split after the split of the flooding topology happens. However, there is not any details or description on how to determine or repair the split. This is not useful for implementers.

> not if you do flooding on every link that comes up. If you want to be smarter, then you need to
> selectively enable flooding only under specific conditions and that must be done from both sides of
> the new link.

There are only a limited number of conditions (or cases).  In each condition/case, it is deterministic whether we need to enable "temporary flooding" for a new link when it is up.  Thus there is no need for any extensions to Hello protocols for enabling "temporary flooding" on a new link.

For example, suppose that we have a current flooding topology containing all live nodes in an area, when a new link comes up, we may just have two conditions/cases. One condition/case is that the new link is attached to a new node not on the current flooding topology. In this condition/case, the new link needs to be enabled for "temporary flooding" after it is up. The other condition/case is that the new link is attached to nodes on the current flooding topology. In this condition/case, there is no need to enable "temporary flooding" on the link.

> > "temporary flooding" for a connection does not work.
>

"The nodes ... will try to repair the flooding topology locally by enabling temporary flooding towards the nodes that they consider disconnected from the flooding topology ..."

The above quoted text is from draft-li-lsr-dynamic-flooding-02, where "enabling temporary flooding towards the nodes" is to request/signal "temporary flooding" for a connection to connect partitioned/disconnected flooding topology into one through the extensions to Hello protocols described in draft-li-lsr-dynamic-flooding-02. Right?

The extensions to Hello protocols for requesting/signaling "temporary flooding" for a connection to connect partitioned/disconnected flooding topology into one does not work since the connection may have two or more hops and a Hello packet may get lost.

> nodes that participates in dynamic flooding.

It is not convenient for a user/operator to configure on an area leader since the leader is dynamically selected. How do you address this?

After the user/operator does some configurations on the (designated) leader, will the backup leader takes over the configurations after the designated leader is down?

Best Regards,
Huaimo

> From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Christian Hopps
>
> To: [email-masked]<mailto:[email-masked]>
>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>
> [email-masked]<mailto:[email-masked]>
>
> [email-masked]<mailto:[email-masked]>

---

From: Tony Li <[email-masked]>
Date: Tue, 26 Feb 2019 23:07:06 -0800

Hi Huaimo,

> Section 6.7.11 just briefly mentions that the edges of split parts will determine and repair the split after the split of the flooding topology happens. However, there is not any details or descrip…

I’m sorry that you don’t find it useful. Determining the split is trivial: when you receive an IIH, it has a system ID of the another system in it. If that other system is not currently part of the flooding topology, then it is quite clear that it is disconnected from the flooding topology. Repairing the split is done by enabling temporary flooding on the new link.

There is an issue here that we have not yet resolved, which is the rate that new links should be temporarily added to the flooding topology.  Some believe that adding any new link is the correct thing to do as it minimizes the recovery time. Others feel that enabling too many links could cause a flooding collapse, so link addition should be highly constrained. We are still discussing this and invite the WG’s opinions.

> There are only a limited number of conditions (or cases).  In each condition/case, it is deterministic whether we need to enable “temporary flooding” for a new link when it is up.  Thus there is no need for any extensions to Hello protocols for enabling “temporary flooding” on a new link.

We know of only two cases: (1) the neighbor is not part of the flooding topology and we feel that we can add more temporary flooding. (2) The neighbor is not part of the flooding topology and we cannot add more temporary flooding.

Obviously, in the case where we want to add temporary flooding, that TLV is needed in the IIH.

> For example, suppose that we have a current flooding topology containing all live nodes in an area, when a new link comes up, we may just have two conditions/cases. One condition/case is that the new link is attached to a new node not on the current flooding topology. In this condition/case, the new link needs to be enabled for “temporary flooding” after it is up.

Agreed, which is why we need the TLV.

> The other condition/case is that the new link is attached to nodes on the current flooding topology. In this condition/case, there is no need to enable “temporary flooding” on the link.

Agreed.

Note that there are some additional corner cases.  Since the two neighbors may not have the exact same information, one may consider the other to be on the flooding topology when in fact it is not.  This might happen in the case of a node reboot. The IIH TLV gives us an explicit way of signaling, rather than simply guessing and sometimes getting it wrong.

> “The nodes … will try to repair the flooding topology locally by enabling temporary flooding towards the nodes that they consider disconnected from the flooding topology ...”
>  
> The above quoted text is from draft-li-lsr-dynamic-flooding-02, where “enabling temporary flooding towards the nodes” is to request/signal “temporary flooding” for a connection to connect partitioned/disconnected flooding topology into one through the extensions to Hello protocols described in draft-li-lsr-dynamic-flooding-02. Right?
>  
> The extensions to Hello protocols for requesting/signaling “temporary flooding” for a connection to connect partitioned/disconnected flooding topology into one does not work since the connection may have two or more hops and a Hello packet may get lost.

All adjacencies are a single hop in both IS-IS and OSPF.  Yes, Hello packets may be lost. Fortunately, they are periodically transmitted, thus the next transmission will also contain the TLV.  If IIH’s are getting lost at a significant rate, then the adjacency will not (and should not) come up.  Thus, the request for temporary flooding will propagate to the neighbor in all cases that matter.

> It is not convenient for a user/operator to configure on an area leader since the leader is dynamically selected. How do you address this?

No configuration is required.  The election algorithm selects the area leader.  The rules are in the draft.  An implementation may have a default priority and a default algorithm setting, so no configuration is mandatory.  If the operator desires a specific node to become area leader, then configuration may be required to adjust the priority.  FWIW, we have this already working in our implementation.  It Just Works.

> After the user/operator does some configurations on the (designated) leader, will the backup leader takes over the configurations after the designated leader is down?

There is no need for a backup leader.  If the area leader is partitioned from the topology, then leader election is repeated, resulting in a new leader.  Again, no configuration is required.

Tony