Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[John E Drake]

There is no virtually no difference between the two drafts in the way that 
distributed mode works and your draft currently has no description of how 
centralized mode works.

Yours Irrespectively,

John

From: Huaimo Chen 
Sent: Tuesday, September 4, 2018 12:30 PM
To: John E Drake ; Robert Raszuk 
Cc: tony...@tony.li; Acee Lindem (acee) ; 
lsr@ietf.org; Jeff Tantsura ; Tony Przygienda 
; Peter Psenak 
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi John,

Two drafts are presented in just two IETFs. For centralized mode and 
distributed one, one very important part is the their efficiency. It is better 
to give some time for others to propose some new or more efficient solutions. 
If one solution (say A) is much more efficient than another one (say B), which 
one (A or B) will you select?

Best Regards,
Huaimo
From: John E Drake [mailto:jdr...@juniper.net]
Sent: Tuesday, September 4, 2018 12:02 PM
To: Huaimo Chen mailto:huaimo.c...@huawei.com>>; Robert 
Raszuk mailto:rob...@raszuk.net>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>; Peter Psenak 
mailto:ppse...@cisco.com>>
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi,

I think we have circled back to the implicit point of my original email, viz, 
why do we need two drafts that solve the same problem in more or less the same 
way, especially given that one is much more robust and complete than the other?

Yours Irrespectively,

John

From: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Sent: Tuesday, September 4, 2018 11:24 AM
To: John E Drake mailto:jdr...@juniper.net>>; Robert Raszuk 
mailto:rob...@raszuk.net>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>; Peter Psenak 
mailto:ppse...@cisco.com>>
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi John,

See my comments inline below.

Best Regards,
Huaimo
From: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Sent: Tuesday, September 4, 2018 9:50 AM
To: John E Drake mailto:jdr...@juniper.net>>; Robert Raszuk 
mailto:rob...@raszuk.net>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>; Peter Psenak 
mailto:ppse...@cisco.com>>
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi John,

> I have reviewed both of the flood reduction drafts and the draft referenced 
> below, draft-cc-ospf-flooding-reduction-02, seems to me to be a derivative 
> document inferior in >quality to the draft, draft-li-dynamic-flooding-05, 
> from which it is derived.  For example, the referenced draft fails to include 
> a description of the message used to deliver the >flooding topology when 
> using centralized mode, it neglects to include any analysis of error 
> conditions, and it neglects to include any description of the interactions 
> with down->level nodes.
It seems that your word “derivative” is not correct. Our draft originally 
focuses on distributed solution, Tony’s on centralized one. It is not 
reasonable to say that a distributed solution is a derivative from a 
centralized one.

[JD]  Both discuss centralized and distributed
[HC] Both drafts talk about both now. It is not reasonable to say one is a 
derivative of another.

Regarding to missing message for centralized mode in our draft as you 
mentioned, it is for new ones to be added. We will fill this gap.

[JD] Please see:   
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-5<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D5=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=OtsOoYoplgrllQAM3IzPelpEFY22UOyVbTeCEZVKvfs=G1nxMx0mq-ML451DGEvEZ_QClKB6lWjXE6LJrkmxnds=>

Regarding to missing analysis of error conditions, we will consider and add it.

[JD] Please see:   
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-4.6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D4.6=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=OtsOoYoplgrllQAM3IzPelpEFY22UOyVbTeCEZVKvfs=BXGDgpp4d36n9mToUIVYpJ1jK70LFDdWv_G35532MtU=>
[HC] For this, our draft talks about it.

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Huaimo Chen]

Hi John,

Two drafts are presented in just two IETFs. For centralized mode and 
distributed one, one very important part is the their efficiency. It is better 
to give some time for others to propose some new or more efficient solutions. 
If one solution (say A) is much more efficient than another one (say B), which 
one (A or B) will you select?

Best Regards,
Huaimo
From: John E Drake [mailto:jdr...@juniper.net]
Sent: Tuesday, September 4, 2018 12:02 PM
To: Huaimo Chen ; Robert Raszuk 
Cc: tony...@tony.li; Acee Lindem (acee) ; 
lsr@ietf.org; Jeff Tantsura ; Tony Przygienda 
; Peter Psenak 
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi,

I think we have circled back to the implicit point of my original email, viz, 
why do we need two drafts that solve the same problem in more or less the same 
way, especially given that one is much more robust and complete than the other?

Yours Irrespectively,

John

From: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Sent: Tuesday, September 4, 2018 11:24 AM
To: John E Drake mailto:jdr...@juniper.net>>; Robert Raszuk 
mailto:rob...@raszuk.net>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>; Peter Psenak 
mailto:ppse...@cisco.com>>
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi John,

See my comments inline below.

Best Regards,
Huaimo
From: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Sent: Tuesday, September 4, 2018 9:50 AM
To: John E Drake mailto:jdr...@juniper.net>>; Robert Raszuk 
mailto:rob...@raszuk.net>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>; Peter Psenak 
mailto:ppse...@cisco.com>>
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi John,

> I have reviewed both of the flood reduction drafts and the draft referenced 
> below, draft-cc-ospf-flooding-reduction-02, seems to me to be a derivative 
> document inferior in >quality to the draft, draft-li-dynamic-flooding-05, 
> from which it is derived.  For example, the referenced draft fails to include 
> a description of the message used to deliver the >flooding topology when 
> using centralized mode, it neglects to include any analysis of error 
> conditions, and it neglects to include any description of the interactions 
> with down->level nodes.
It seems that your word “derivative” is not correct. Our draft originally 
focuses on distributed solution, Tony’s on centralized one. It is not 
reasonable to say that a distributed solution is a derivative from a 
centralized one.

[JD]  Both discuss centralized and distributed
[HC] Both drafts talk about both now. It is not reasonable to say one is a 
derivative of another.

Regarding to missing message for centralized mode in our draft as you 
mentioned, it is for new ones to be added. We will fill this gap.

[JD] Please see:   
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-5<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D5=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=OtsOoYoplgrllQAM3IzPelpEFY22UOyVbTeCEZVKvfs=G1nxMx0mq-ML451DGEvEZ_QClKB6lWjXE6LJrkmxnds=>

Regarding to missing analysis of error conditions, we will consider and add it.

[JD] Please see:   
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-4.6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D4.6=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=OtsOoYoplgrllQAM3IzPelpEFY22UOyVbTeCEZVKvfs=BXGDgpp4d36n9mToUIVYpJ1jK70LFDdWv_G35532MtU=>
[HC] For this, our draft talks about it. We will add more in details.

Regarding to interactions with down-level nodes, can you give more details?

[JD]  Please see:   
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-4<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D4=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=OtsOoYoplgrllQAM3IzPelpEFY22UOyVbTeCEZVKvfs=cQTQjUmBdJJJXLwNJuuICHOYwE09AmYdvM3tdz6JP5A=>,
 
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-4.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D4.1=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CR

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[John E Drake]

Hi,

I think we have circled back to the implicit point of my original email, viz, 
why do we need two drafts that solve the same problem in more or less the same 
way, especially given that one is much more robust and complete than the other?

Yours Irrespectively,

John

From: Huaimo Chen 
Sent: Tuesday, September 4, 2018 11:24 AM
To: John E Drake ; Robert Raszuk 
Cc: tony...@tony.li; Acee Lindem (acee) ; 
lsr@ietf.org; Jeff Tantsura ; Tony Przygienda 
; Peter Psenak 
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi John,

See my comments inline below.

Best Regards,
Huaimo
From: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Sent: Tuesday, September 4, 2018 9:50 AM
To: John E Drake mailto:jdr...@juniper.net>>; Robert Raszuk 
mailto:rob...@raszuk.net>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>; Peter Psenak 
mailto:ppse...@cisco.com>>
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi John,

> I have reviewed both of the flood reduction drafts and the draft referenced 
> below, draft-cc-ospf-flooding-reduction-02, seems to me to be a derivative 
> document inferior in >quality to the draft, draft-li-dynamic-flooding-05, 
> from which it is derived.  For example, the referenced draft fails to include 
> a description of the message used to deliver the >flooding topology when 
> using centralized mode, it neglects to include any analysis of error 
> conditions, and it neglects to include any description of the interactions 
> with down->level nodes.
It seems that your word “derivative” is not correct. Our draft originally 
focuses on distributed solution, Tony’s on centralized one. It is not 
reasonable to say that a distributed solution is a derivative from a 
centralized one.

[JD]  Both discuss centralized and distributed
[HC] Both drafts talk about both now. It is not reasonable to say one is a 
derivative of another.

Regarding to missing message for centralized mode in our draft as you 
mentioned, it is for new ones to be added. We will fill this gap.

[JD] Please see:   
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-5<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D5=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=OtsOoYoplgrllQAM3IzPelpEFY22UOyVbTeCEZVKvfs=G1nxMx0mq-ML451DGEvEZ_QClKB6lWjXE6LJrkmxnds=>

Regarding to missing analysis of error conditions, we will consider and add it.

[JD] Please see:   
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-4.6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D4.6=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=OtsOoYoplgrllQAM3IzPelpEFY22UOyVbTeCEZVKvfs=BXGDgpp4d36n9mToUIVYpJ1jK70LFDdWv_G35532MtU=>
[HC] For this, our draft talks about it. We will add more in details.

Regarding to interactions with down-level nodes, can you give more details?

[JD]  Please see:   
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-4<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D4=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=OtsOoYoplgrllQAM3IzPelpEFY22UOyVbTeCEZVKvfs=cQTQjUmBdJJJXLwNJuuICHOYwE09AmYdvM3tdz6JP5A=>,
 
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-4.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D4.1=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=OtsOoYoplgrllQAM3IzPelpEFY22UOyVbTeCEZVKvfs=7XTcJB8R7BWKwA6Gf9ZszZwlQUuVxDqnE-VkGBX2PPs=>
[HC] For this, our draft talks about it.
>Yours Irrespectively,
>
>John

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Huaimo Chen
Sent: Thursday, August 30, 2018 11:01 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>; Peter Psenak 
mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi Robert,

>> draft-cc-ospf-flooding-reduction-02 allows operators to select distributed 
>> mode, centralized one or static one smoothly.
>Aside from static approach can you summarize in purely technical 

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Huaimo Chen]

Hi John,

> I have reviewed both of the flood reduction drafts and the draft referenced 
> below, draft-cc-ospf-flooding-reduction-02, seems to me to be a derivative 
> document inferior in >quality to the draft, draft-li-dynamic-flooding-05, 
> from which it is derived.  For example, the referenced draft fails to include 
> a description of the message used to deliver the >flooding topology when 
> using centralized mode, it neglects to include any analysis of error 
> conditions, and it neglects to include any description of the interactions 
> with down->level nodes.
It seems that your word “derivative” is not correct. Our draft originally 
focuses on distributed solution, Tony’s on centralized one. It is not 
reasonable to say that a distributed solution is a derivative from a 
centralized one.
Regarding to missing message for centralized mode in our draft as you 
mentioned, it is for new ones to be added. We will fill this gap.
Regarding to missing analysis of error conditions, we will consider and add it.
Regarding to interactions with down-level nodes, can you give more details?

>Yours Irrespectively,
>
>John

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Huaimo Chen
Sent: Thursday, August 30, 2018 11:01 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>; Peter Psenak 
mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi Robert,

>> draft-cc-ospf-flooding-reduction-02 allows operators to select distributed 
>> mode, centralized one or static one smoothly.
>Aside from static approach can you summarize in purely technical points 
>advantages your draft proposes over draft-li-dynamic-flooding-05 ?
Initially, our draft focused on distributed solution for flooding reduction, 
and Tony’s on centralized way. This should be one advantage. Distributed 
solution is more practical.
In addition, we proposed the followings during the progress of our draft:

1)A method to allow flooding topology to be lean and to allow multiple 
failures in an area;

2)A procedure for establishing a new adjacency between a (new) node and  an 
existing node supporting flooding reduction;

3)A way in which one touch (or command) to enable flooding reduction in a 
whole area within a short time;

4)A way in which one touch (or command) to rollback flooding reduction to 
normal flooding in a whole area smoothly;

5)A TLV for distributing the priority of a node to become a leader;

6)Three algorithms for building a flooding topology.
Distributed solution for flooding reduction is stable after we resolve the 
issues raised by other experts during the last few IETFs.
BTW, as a service provider, which mode/solution (distributed or centralized) 
will you select to use in an operational network?

Best Regards,
Huaimo
>Many thx,
>R.



On Mon, Aug 27, 2018 at 6:41 PM, Huaimo Chen 
mailto:huaimo.c...@huawei.com>> wrote:
Hi Robert,

>Leader election happens automatically and procedures for that are to be vastly 
>similar to today's DR or DIS election. So with this in mind one may observe 
>that both OSPF and ISIS are pretty centralized on multiaccess networks today :)

Today’s DR or DIS election is local to a special interface/network such as a 
broadcast interface. Leader election in a network is global. Every node in the 
network depends on it (its flooding topology). These two seems different.

>Btw I don't think there is any problem here ... The text added to -05 version 
>allows very seamless choice of centralized vs distributed topology computation 
>by signalling either zero or non zero value in the added to version -05 area 
>leader sub-tlv.
>
>In other words I don't see any problem or room for debate .. adopting and 
>implementing -05 allows use of centralized or distributed optimal flooding 
>computation at the operator's discretion.

draft-cc-ospf-flooding-reduction-02 allows operators to select distributed 
mode, centralized one or static one smoothly.

Best Regards,
Huaimo

From: Robert Raszuk [mailto:rob...@raszuk.net<mailto:rob...@raszuk.net>]
Sent: Monday, August 27, 2018 11:31 AM
To: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; lsr@ietf.org<mailto:lsr@ietf.org>; 
Jeff Tantsura mailto:jefftant.i...@gmail.com>>; Acee 
Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; Peter 
Psenak mailto:ppse...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi Huaimo,

> Introducing centralized featu

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[John E Drake]

Hi,

I have reviewed both of the flood reduction drafts and the draft referenced 
below, draft-cc-ospf-flooding-reduction-02, seems to me to be a derivative 
document inferior in quality to the draft, draft-li-dynamic-flooding-05, from 
which it is derived.  For example, the referenced draft fails to include a 
description of the message used to deliver the flooding topology when using 
centralized mode, it neglects to include any analysis of error conditions, and 
it neglects to include any description of the interactions with down-level 
nodes.

Yours Irrespectively,

John

From: Lsr  On Behalf Of Huaimo Chen
Sent: Thursday, August 30, 2018 11:01 AM
To: Robert Raszuk 
Cc: tony...@tony.li; Acee Lindem (acee) ; 
lsr@ietf.org; Jeff Tantsura ; Tony Przygienda 
; Peter Psenak 
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi Robert,

>> draft-cc-ospf-flooding-reduction-02 allows operators to select distributed 
>> mode, centralized one or static one smoothly.
>Aside from static approach can you summarize in purely technical points 
>advantages your draft proposes over draft-li-dynamic-flooding-05 ?
Initially, our draft focused on distributed solution for flooding reduction, 
and Tony’s on centralized way. This should be one advantage. Distributed 
solution is more practical.
In addition, we proposed the followings during the progress of our draft:

1) A method to allow flooding topology to be lean and to allow multiple 
failures in an area;

2) A procedure for establishing a new adjacency between a (new) node and  
an existing node supporting flooding reduction;

3) A way in which one touch (or command) to enable flooding reduction in a 
whole area within a short time;

4) A way in which one touch (or command) to rollback flooding reduction to 
normal flooding in a whole area smoothly;

5) A TLV for distributing the priority of a node to become a leader;

6) Three algorithms for building a flooding topology.
Distributed solution for flooding reduction is stable after we resolve the 
issues raised by other experts during the last few IETFs.
BTW, as a service provider, which mode/solution (distributed or centralized) 
will you select to use in an operational network?

Best Regards,
Huaimo
>Many thx,
>R.



On Mon, Aug 27, 2018 at 6:41 PM, Huaimo Chen 
mailto:huaimo.c...@huawei.com>> wrote:
Hi Robert,

>Leader election happens automatically and procedures for that are to be vastly 
>similar to today's DR or DIS election. So with this in mind one may observe 
>that both OSPF and ISIS are pretty centralized on multiaccess networks today :)

Today’s DR or DIS election is local to a special interface/network such as a 
broadcast interface. Leader election in a network is global. Every node in the 
network depends on it (its flooding topology). These two seems different.

>Btw I don't think there is any problem here ... The text added to -05 version 
>allows very seamless choice of centralized vs distributed topology computation 
>by signalling either zero or non zero value in the added to version -05 area 
>leader sub-tlv.
>
>In other words I don't see any problem or room for debate .. adopting and 
>implementing -05 allows use of centralized or distributed optimal flooding 
>computation at the operator's discretion.

draft-cc-ospf-flooding-reduction-02 allows operators to select distributed 
mode, centralized one or static one smoothly.

Best Regards,
Huaimo

From: Robert Raszuk [mailto:rob...@raszuk.net<mailto:rob...@raszuk.net>]
Sent: Monday, August 27, 2018 11:31 AM
To: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; lsr@ietf.org<mailto:lsr@ietf.org>; 
Jeff Tantsura mailto:jefftant.i...@gmail.com>>; Acee 
Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; Peter 
Psenak mailto:ppse...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi Huaimo,

> Introducing centralized feature into IGP will break IGP's distributed nature

That clearly proves that word "centralized" has been significantly overloaded 
here.  To many indeed "centralized" means a controller (like OpenFlow or SDN) 
and that such device added to a network is to push information - typically 1RU 
linux blade -  here optimized flooding graph. But this never was the plan with 
this proposal from its start ie. -00 version.

Centralized means that optimized flooding graph comes from single redundant 
node.

Leader election happens automatically and procedures for that are to be vastly 
similar to today's DR or DIS election. So with this in mind one may observe 
that both OSPF and ISIS are pretty centralized on multiaccess networks today :)

To your point of multi-vendor networks true - and that is precisely why upgrade 
network wide to a release containing consist

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Huaimo Chen]

Hi Robert,

>> draft-cc-ospf-flooding-reduction-02 allows operators to select distributed 
>> mode, centralized one or static one smoothly.
>Aside from static approach can you summarize in purely technical points 
>advantages your draft proposes over draft-li-dynamic-flooding-05 ?
Initially, our draft focused on distributed solution for flooding reduction, 
and Tony’s on centralized way. This should be one advantage. Distributed 
solution is more practical.
In addition, we proposed the followings during the progress of our draft:

1)A method to allow flooding topology to be lean and to allow multiple 
failures in an area;

2)A procedure for establishing a new adjacency between a (new) node and  an 
existing node supporting flooding reduction;

3)A way in which one touch (or command) to enable flooding reduction in a 
whole area within a short time;

4)A way in which one touch (or command) to rollback flooding reduction to 
normal flooding in a whole area smoothly;

5)A TLV for distributing the priority of a node to become a leader;

6)Three algorithms for building a flooding topology.
Distributed solution for flooding reduction is stable after we resolve the 
issues raised by other experts during the last few IETFs.
BTW, as a service provider, which mode/solution (distributed or centralized) 
will you select to use in an operational network?

Best Regards,
Huaimo
>Many thx,
>R.



On Mon, Aug 27, 2018 at 6:41 PM, Huaimo Chen 
mailto:huaimo.c...@huawei.com>> wrote:
Hi Robert,

>Leader election happens automatically and procedures for that are to be vastly 
>similar to today's DR or DIS election. So with this in mind one may observe 
>that both OSPF and ISIS are pretty centralized on multiaccess networks today :)

Today’s DR or DIS election is local to a special interface/network such as a 
broadcast interface. Leader election in a network is global. Every node in the 
network depends on it (its flooding topology). These two seems different.

>Btw I don't think there is any problem here ... The text added to -05 version 
>allows very seamless choice of centralized vs distributed topology computation 
>by signalling either zero or non zero value in the added to version -05 area 
>leader sub-tlv.
>
>In other words I don't see any problem or room for debate .. adopting and 
>implementing -05 allows use of centralized or distributed optimal flooding 
>computation at the operator's discretion.

draft-cc-ospf-flooding-reduction-02 allows operators to select distributed 
mode, centralized one or static one smoothly.

Best Regards,
Huaimo

From: Robert Raszuk [mailto:rob...@raszuk.net<mailto:rob...@raszuk.net>]
Sent: Monday, August 27, 2018 11:31 AM
To: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; lsr@ietf.org<mailto:lsr@ietf.org>; 
Jeff Tantsura mailto:jefftant.i...@gmail.com>>; Acee 
Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; Peter 
Psenak mailto:ppse...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi Huaimo,

> Introducing centralized feature into IGP will break IGP's distributed nature

That clearly proves that word "centralized" has been significantly overloaded 
here.  To many indeed "centralized" means a controller (like OpenFlow or SDN) 
and that such device added to a network is to push information - typically 1RU 
linux blade -  here optimized flooding graph. But this never was the plan with 
this proposal from its start ie. -00 version.

Centralized means that optimized flooding graph comes from single redundant 
node.

Leader election happens automatically and procedures for that are to be vastly 
similar to today's DR or DIS election. So with this in mind one may observe 
that both OSPF and ISIS are pretty centralized on multiaccess networks today :)

To your point of multi-vendor networks true - and that is precisely why upgrade 
network wide to a release containing consistent algorithm from more then a 
single vendor (and even for single vendor) is practically a very time consuming 
and difficult process.

Btw I don't think there is any problem here ... The text added to -05 version 
allows very seamless choice of centralized vs distributed topology computation 
by signalling either zero or non zero value in the added to version -05 area 
leader sub-tlv.

In other words I don't see any problem or room for debate .. adopting and 
implementing -05 allows use of centralized or distributed optimal flooding 
computation at the operator's discretion.

Thx,
R.

On Mon, Aug 27, 2018 at 5:10 PM, Huaimo Chen 
mailto:huaimo.c...@huawei.com>> wrote:
>> I think distributed is more practical too.
>I would appreciate more detailed insights as to why you (and others) feel this 
>way.  It is not at all obvio

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[tony . li]

> Can we focus on finding one common algorithms that can deducing the optimized 
> flooding topology based on the initial synchronized LSDB for further LSA 
> flooding reduction?


We welcome proposals for algorithms that fulfill the requirements that have 
been discussed.

So far …. crickets.

Tony

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

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Christian Hopps]

tony...@tony.li writes:


so it's party like it's 1999, seems the peer group leader election gets rediscovered 
;-)  Interesting old new problems, interesting old new attack vectors like 
https://ieeexplore.ieee.org/document/822780/ 



No argument there.  There are no new problems or solutions.  Just us 
rediscovering the problems and approaches that others have used before.


Sheesh, that's giving me the Computer Blue[s].

Chris.



That said, the solutions still need to be applied.  That is, after all, 
engineering.

Preferably in a Little Red Corvette.

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] LSR Flooding Reduction Drafts - Moving Forward

[tony . li]

> so it's party like it's 1999, seems the peer group leader election gets 
> rediscovered ;-)  Interesting old new problems, interesting old new attack 
> vectors like https://ieeexplore.ieee.org/document/822780/ 
> 

No argument there.  There are no new problems or solutions.  Just us 
rediscovering the problems and approaches that others have used before.

That said, the solutions still need to be applied.  That is, after all, 
engineering.

Preferably in a Little Red Corvette.

Tony


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

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Tony Przygienda]

On Mon, Aug 27, 2018 at 9:41 AM Huaimo Chen  wrote:

> Hi Robert,
>
>
>
> >Leader election happens automatically and procedures for that are to be
> vastly similar to today's DR or DIS election. So with this in mind one may
> observe that both OSPF and ISIS are pretty centralized on multiaccess
> networks today :)
>
>
>
> Today’s DR or DIS election is local to a special interface/network such as
> a broadcast interface. Leader election in a network is global. Every node
> in the network depends on it (its flooding topology). These two seems
> different.
>
>
>

so it's party like it's 1999, seems the peer group leader election gets
rediscovered ;-)  Interesting old new problems, interesting old new attack
vectors like https://ieeexplore.ieee.org/document/822780/

 tony

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

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Robert Raszuk]

> draft-cc-ospf-flooding-reduction-02 allows operators to select
distributed mode, centralized one or static one smoothly.

Aside from static approach can you summarize in purely technical points
advantages your draft proposes over draft-li-dynamic-flooding-05 ?

Many thx,
R.



On Mon, Aug 27, 2018 at 6:41 PM, Huaimo Chen  wrote:

> Hi Robert,
>
>
>
> >Leader election happens automatically and procedures for that are to be
> vastly similar to today's DR or DIS election. So with this in mind one may
> observe that both OSPF and ISIS are pretty centralized on multiaccess
> networks today :)
>
>
>
> Today’s DR or DIS election is local to a special interface/network such as
> a broadcast interface. Leader election in a network is global. Every node
> in the network depends on it (its flooding topology). These two seems
> different.
>
>
>
> >Btw I don't think there is any problem here ... The text added to -05
> version allows very seamless choice of centralized vs distributed topology
> computation by signalling either zero or non zero value in the added to
> version -05 area leader sub-tlv.
>
> >
>
> >In other words I don't see any problem or room for debate .. adopting and
> implementing -05 allows use of centralized or distributed optimal flooding
> computation at the operator's discretion.
>
>
>
> draft-cc-ospf-flooding-reduction-02 allows operators to select
> distributed mode, centralized one or static one smoothly.
>
>
>
> Best Regards,
>
> Huaimo
>
>
>
> *From:* Robert Raszuk [mailto:rob...@raszuk.net]
> *Sent:* Monday, August 27, 2018 11:31 AM
> *To:* Huaimo Chen 
> *Cc:* tony...@tony.li; lsr@ietf.org; Jeff Tantsura <
> jefftant.i...@gmail.com>; Acee Lindem (acee)  org>; Peter Psenak ; Tony Przygienda <
> tonysi...@gmail.com>
> *Subject:* Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward
>
>
>
> Hi Huaimo,
>
>
>
> > Introducing centralized feature into IGP will break IGP's distributed
> nature
>
>
>
> That clearly proves that word "centralized" has been significantly
> overloaded here.  To many indeed "centralized" means a controller (like
> OpenFlow or SDN) and that such device added to a network is to push
> information - typically 1RU linux blade -  here optimized flooding graph.
> But this never was the plan with this proposal from its start ie. -00
> version.
>
>
>
> Centralized means that optimized flooding graph comes from single
> redundant node.
>
>
>
> Leader election happens automatically and procedures for that are to be
> vastly similar to today's DR or DIS election. So with this in mind one may
> observe that both OSPF and ISIS are pretty centralized on multiaccess
> networks today :)
>
>
>
> To your point of multi-vendor networks true - and that is precisely why
> upgrade network wide to a release containing consistent algorithm from more
> then a single vendor (and even for single vendor) is practically a very
> time consuming and difficult process.
>
>
>
> Btw I don't think there is any problem here ... The text added to -05
> version allows very seamless choice of centralized vs distributed topology
> computation by signalling either zero or non zero value in the added to
> version -05 area leader sub-tlv.
>
>
>
> In other words I don't see any problem or room for debate .. adopting and
> implementing -05 allows use of centralized or distributed optimal flooding
> computation at the operator's discretion.
>
>
>
> Thx,
>
> R.
>
>
>
> On Mon, Aug 27, 2018 at 5:10 PM, Huaimo Chen 
> wrote:
>
> >> I think distributed is more practical too.
> >I would appreciate more detailed insights as to why you (and others) feel
> this way.  It is not at all obvious to me.
> IGP is distributed in nature. The distributed computation of flooding
> topology like distributed SPF will keep IGP still distributed in nature.
> Introducing centralized feature into IGP will break IGP's distributed
> nature, which may cause some issues/problems.
>
> >> For computing routes, we have been using distributed SPF on every node
> for many years.
> >True, but that algorithm is (and was) very well known and a fixed
> algorithm that would clearly solve the problem at the time. If we were in a
> similar situation, where we were ready to set an algorithm in >concrete, I
> might well agree, but it’s quite clear that we are NOT at that point yet.
> We will need to experiment and modify algorithms, and as discussed, that’s
> easier with a centralized approach.
> After flooding reduction is deployed in an operational (ISP) network, will
> we be allowed to do e

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[tony . li]

Hi Huaimo,


> After flooding reduction is deployed in an operational (ISP) network, will we 
> be allowed to do experiments on their network? 


Some may well permit it.  Certainly in lab scenarios they may be very willing.  
It all depends on their motivation to achieve improvements.

It should be remembered that we are where we are today because some people were 
willing to work towards better technology and understood that there would be 
issues while we worked out issues with implementations. All protocols, 
features, and implementations have growing pains. We are where we are because 
we work through them.


> After an algorithm is determined/selected, will it be changed to another 
> algorithm in a short time? 


Possibly. Someone may have an insight that produces theoretical breakthrough 
and gives us a completely different algorithm. Or, more likely, someone 
discovers a catastrophic bug in an algorithm and moves to fix it.


> In some existing networks, some nodes run IGPs from one vendor, some other 
> nodes run IGPs from another vendor, and so on. Some may use normal SPF, some 
> others may use incremental SPF. It seems that we have had these cases for 
> many years. 


I’m unaware of anyone trying to get EIGRP to interoperate with IS-IS at the 
protocol level.  ;-)

I’m also unaware of anyone trying to implement anything other than SPF.

And that’s what I think you’re proposing…

Tony


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

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Robert Raszuk]

Hi Huaimo,

> Introducing centralized feature into IGP will break IGP's distributed
nature

That clearly proves that word "centralized" has been significantly
overloaded here.  To many indeed "centralized" means a controller (like
OpenFlow or SDN) and that such device added to a network is to push
information - typically 1RU linux blade -  here optimized flooding graph.
But this never was the plan with this proposal from its start ie. -00
version.

Centralized means that optimized flooding graph comes from single redundant
node.

Leader election happens automatically and procedures for that are to be
vastly similar to today's DR or DIS election. So with this in mind one may
observe that both OSPF and ISIS are pretty centralized on multiaccess
networks today :)

To your point of multi-vendor networks true - and that is precisely why
upgrade network wide to a release containing consistent algorithm from more
then a single vendor (and even for single vendor) is practically a very
time consuming and difficult process.

Btw I don't think there is any problem here ... The text added to -05
version allows very seamless choice of centralized vs distributed topology
computation by signalling either zero or non zero value in the added to
version -05 area leader sub-tlv.

In other words I don't see any problem or room for debate .. adopting and
implementing -05 allows use of centralized or distributed optimal flooding
computation at the operator's discretion.

Thx,
R.

On Mon, Aug 27, 2018 at 5:10 PM, Huaimo Chen  wrote:

> >> I think distributed is more practical too.
> >I would appreciate more detailed insights as to why you (and others) feel
> this way.  It is not at all obvious to me.
> IGP is distributed in nature. The distributed computation of flooding
> topology like distributed SPF will keep IGP still distributed in nature.
> Introducing centralized feature into IGP will break IGP's distributed
> nature, which may cause some issues/problems.
>
> >> For computing routes, we have been using distributed SPF on every node
> for many years.
> >True, but that algorithm is (and was) very well known and a fixed
> algorithm that would clearly solve the problem at the time. If we were in a
> similar situation, where we were ready to set an algorithm in >concrete, I
> might well agree, but it’s quite clear that we are NOT at that point yet.
> We will need to experiment and modify algorithms, and as discussed, that’s
> easier with a centralized approach.
> After flooding reduction is deployed in an operational (ISP) network, will
> we be allowed to do experiments on their network?
> After an algorithm is determined/selected, will it be changed to another
> algorithm in a short time?
>
> >> In fact, we may not need to run the exact algorithm on every node. As
> long as the algorithms running on different nodes generate the same result,
> that would work.
> >Insuring a globally consistent result without running the exact same
> algorithm on the exact same data will be quite a trick.  Debugging
> distributed problems at scale is already a hard problem.  Having >different
> algorithms in different locations would add another order of magnitude in
> difficulty.  No thank you.
> In some existing networks, some nodes run IGPs from one vendor, some other
> nodes run IGPs from another vendor, and so on. Some may use normal SPF,
> some others may use incremental SPF. It seems that we have had these cases
> for many years.
> >Tony
>
> Best Regards,
> Huaimo
> ___
> 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] LSR Flooding Reduction Drafts - Moving Forward

[Robert Raszuk]

Tonys / Everyone,

> moreover, I observe that IME ISIS is much more robust under such
optimizations since the CSNPs catch (@ a somehow ugly delay cost)
> any corner cases whereas OSPF after IDBE will happily stay out of sync
forever if flooding skips something (that may actually become a
> reason to introduce periodic stuff on OSPF to do CSNP equivalent

Do we really need for DC use case to have flooding reduction standardized
for all three protocols ? ISIS, OSPFv2 & OSPFv3 ? Would just focusing on
ISIS not be sufficient ?

I am not sure if OSPF folks will feel offended or left behind if this work
proceeds for ISIS only - well at least for now till we get more experience
with the algorithm.

There is no shortage of protocols for MSDC use (M meaning Massive or
apparently Mid-size or even as reality shows Mini as well :)

Sure IGP flooding reduction can be useful beyond DCs, but do we have line
of people which are keen on trying this out outside of DC or DC like campus
environments ?

Thx,
R.

















On Fri, Aug 24, 2018 at 6:06 PM, Tony Przygienda 
wrote:

> OK, good, real work. So from some scar tissue here's one question
>
> a) we are talking any kind of topology for the solution, i.e. generic
> graph?
>
> and then suggestion for IME realistic, operational MUST requirements
>
> b) req a): the solution should support distributed and centralized
> algorithm to compute/signal reduced mesh(es). I personally think
> distributed is the more practical choice for something like this but it's
> my 2c from having lived the telephony controller fashion, the distributed
> fashion and the controller fashion now again ;-)
> c) req b): the solution should include redundancy (i.e. @ least 2
> maximally disjoint vertex covers/lifts) to deal with single link failure
> (unless the link is unavoidably a minimal cut on the graph)
> d) req c): the solution should guarantee disruption free flooding in case
> of
>   i) single link failure
>  ii) single node failure
>  iii) change in one of the vertex lifts
> e) the solution should not lead to "hot-spot" or "minimal-cut" links which
> will disrupt flooding between two partitions on failure or lead to flood
> throughput bottlenecks
>
> I am agnostic to Tony L's thinking about diameter and so on. It makes
> sense but is not necessarily easy to pull into the solution.
>
> moreover, I observe that IME ISIS is much more robust under such
> optimizations since the CSNPs catch (@ a somehow ugly delay cost) any
> corner cases whereas OSPF after IDBE will happily stay out of sync forever
> if flooding skips something (that may actually become a reason to introduce
> periodic stuff on OSPF to do CSNP equivalent albeit it won't be trivial in
> backwards compatible way on my first thought, I was thinking a bit about
> cut/snapshot consistency check [in practical terms OSPF hellos could carry
> a checksum on the DB headers] but we never have that luxury on a link-state
> routing protocol [i.e. we always operate under unbounded epsilon
> consistency ;-) and in case of BGP stable oscialltions BTW not even that
> ;^} ]).
>
> --- tony
>
>
> On Fri, Aug 24, 2018 at 8:36 AM Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
>
>> Speaking as WG member:
>>
>> I agree on this and don't believe we need a separate document or a
>> protracted discussion.
>> Additionally, I don't think we should worry about anything going on in
>> other WGs.
>> Thanks,
>> Acee
>> P.S. I'll provide more input to the discussion as well. As luck would
>> have it, I initiated the discussion and then had a couple more pressing
>> matters (including the cable company's fiber installation contractor
>> messing up my irrigation system ;^(
>>
>> On 8/24/18, 11:04 AM, "Lsr on behalf of tony...@tony.li" <
>> lsr-boun...@ietf.org on behalf of tony...@tony.li> wrote:
>>
>>
>> So, going Old Skool here:
>>
>> Since everyone agrees that this is a reasonable direction, how about
>> we have a real discussion on the list?
>>
>> Requirement number 1 is straightforward: a significant reduction in
>> flooding overhead.
>>
>> The basis for this requirement is the understanding that in a dense
>> topology, there is a great deal of redundancy due to flooding, and that it
>> is this redundancy that supersaturates the control plane.
>>
>> Do we agree on this?
>>
>> 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
>>
>
> ___
> 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] LSR Flooding Reduction Drafts - Moving Forward

[Huaimo Chen]

I think distributed is more practical too. 
For computing routes, we have been using distributed SPF on every node for many 
years.
In fact, we may not need to run the exact algorithm on every node. As long as 
the algorithms running on different nodes generate the same result, that would 
work. 

Best Regards,
Huaimo
-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
Sent: Friday, August 24, 2018 12:29 PM
To: Tony Przygienda 
Cc: lsr@ietf.org; Jeff Tantsura ; Peter Psenak 
; Acee Lindem (acee) 
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

> a) we are talking any kind of topology for the solution, i.e. generic graph? 


Well, the problem with a topology restriction is that mistakes happen.  If we 
have a solution for a pure bipartite graph (i.e., a leaf-spine topology) and 
someone mistakenly inserts a leaf to leaf link, what happens?  Having the 
entire DC implode would be a Bad Thing, IMHO.


> and then suggestion for IME realistic, operational MUST requirements 
> 
> b) req a): the solution should support distributed and centralized algorithm 
> to compute/signal reduced mesh(es). I personally think distributed is the 
> more practical choice for something like this but it's my 2c from having 
> lived the telephony controller fashion, the distributed fashion and the 
> controller fashion now again ;-)


Well, I did think long and hard about this.

Being distributed would be very nice.  However, that implies that all nodes are 
going to get to the exact same solution. Which implies that they all must 
execute the same algorithm, presumably with the same inputs.

That’s all well and good, but we don’t have an algorithm to really put on the 
table yet.  We need experience with one.  We know we want to tweak things based 
on biconnectivity, performance, and degree because doing it right day one seems 
unlikely.  Changing algorithms is going to be VERY painful if it’s distributed. 
 

However, if it’s centralized, it’s completely trivial.

So, my strong preference is to start centralized.  Iterate on the algorithm 
until we have it where we want it.  And then take it distributed if there’s a 
point to it.  However, at that point, we have something working.  So why fix it?


> c) req b): the solution should include redundancy (i.e. @ least 2 maximally 
> disjoint vertex covers/lifts) to deal with single link failure (unless the 
> link is unavoidably a minimal cut on the graph) 


Not everyone agrees with this, but some do.  This seems like one possible input 
to the algorithm.


> d) req c): the solution should guarantee disruption free flooding in case of 
>   i) single link failure
>  ii) single node failure
>  iii) change in one of the vertex lifts 


Sorry, I don’t understand point iii).


> e) the solution should not lead to "hot-spot" or "minimal-cut" links which 
> will disrupt flooding between two partitions on failure or lead to flood 
> throughput bottlenecks 


Agreed.

> I am agnostic to Tony L's thinking about diameter and so on. It makes sense 
> but is not necessarily easy to pull into the solution. 


It all boils down to the point that Peter just made about performance.  A 
topology with a high diameter is going to require many flooding hops and hurt 
performance.  To be avoided...


> moreover, I observe that IME ISIS is much more robust under such 
> optimizations since the CSNPs catch (@ a somehow ugly delay cost) any corner 
> cases whereas OSPF after IDBE will happily stay out of sync forever if 
> flooding skips something (that may actually become a reason to introduce 
> periodic stuff on OSPF to do CSNP equivalent albeit it won't be trivial in 
> backwards compatible way on my first thought, I was thinking a bit about 
> cut/snapshot consistency check [in practical terms OSPF hellos could carry a 
> checksum on the DB headers] but we never have that luxury on a link-state 
> routing protocol [i.e. we always operate under unbounded epsilon consistency 
> ;-) and in case of BGP stable oscialltions BTW not even that ;^} ]). 

Emacs

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] LSR Flooding Reduction Drafts - Moving Forward

[Tony Przygienda]

Hey Tony,

as to miscabling: yepp, the protocol has either to prevent adjacencies
coming up or one has to deal with generic topologies. If you don't want to
design miscabling prevention/topology ZTP into protocol (like ROLL or RIFT
did) you have to deal with generic graph as you say. I think that if you
have 99.99% of the time a predictable graph it's easier to restrict wrong
cabling than deal with arbitrary topology when tackling this problem but
that's my read.

Then I get you on the centralized story ;-)  But again, if you're willing
to restrict the graph then stuff like RIFT distributed solution is
implemented and works fine (yes, it took 2 scraps of the approach until
Pascal had the flash of intuition fueled by my-bad-ideas how to use MANET
concepts in a novel way with hashes). BTW implementation experience there
changed bunch of things on what's published in -02 due to interesting
effects, that will be put out in -03 ;-)

Another observation though would be that if you have a single mesh then
centralized controller delay on failure becomes your delay bound how long
flooding is disrupted possibly (unless your single covering graph has
enough redundancy to deal with single llink failure, but then you're really
having two as I suggest ;-). That could get ugly since you'll need
make-before-break if installing a new mesh from controller me thinks with a
round-trip from possibly a lot of nodes ...

Overall, I'm agnostic and watch how things will play out and what people
decide needs be done ...

>  iii) change in one of the vertex lifts
>
>
> Sorry, I don’t understand point iii).
>

A mildly stuffed (or mathematically concise ;-) way to say that if you have
one or two covering graphs (and vertex lift is the more precise word here
since "covering graph" can be also an edge lift which is irrelevant here)
and one of those subgraphs gets recomputed & distributed (due to failures,
changes in some metrics, _whatever_) then this should not lead to
disruption. Basically make-before-break as one possible design point,
harder to achieve of course in distributed fashion ...


>
>
>
> > moreover, I observe that IME ISIS is much more robust under such
> optimizations since the CSNPs catch (@ a somehow ugly delay cost) any
> corner cases whereas OSPF after IDBE will happily stay out of sync forever
> if flooding skips something (that may actually become a reason to introduce
> periodic stuff on OSPF to do CSNP equivalent albeit it won't be trivial in
> backwards compatible way on my first thought, I was thinking a bit about
> cut/snapshot consistency check [in practical terms OSPF hellos could carry
> a checksum on the DB headers] but we never have that luxury on a link-state
> routing protocol [i.e. we always operate under unbounded epsilon
> consistency ;-) and in case of BGP stable oscialltions BTW not even that
> ;^} ]).
>
> Emacs
>
>
And that I cannot parse. Emacs? You want LISP code? But then, Dino may get
offended ;-)

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

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[tony . li]

> a) we are talking any kind of topology for the solution, i.e. generic graph? 


Well, the problem with a topology restriction is that mistakes happen.  If we 
have a solution for a pure bipartite graph (i.e., a leaf-spine topology) and 
someone mistakenly inserts a leaf to leaf link, what happens?  Having the 
entire DC implode would be a Bad Thing, IMHO.


> and then suggestion for IME realistic, operational MUST requirements 
> 
> b) req a): the solution should support distributed and centralized algorithm 
> to compute/signal reduced mesh(es). I personally think distributed is the 
> more practical choice for something like this but it's my 2c from having 
> lived the telephony controller fashion, the distributed fashion and the 
> controller fashion now again ;-)


Well, I did think long and hard about this.

Being distributed would be very nice.  However, that implies that all nodes are 
going to get to the exact same solution. Which implies that they all must 
execute the same algorithm, presumably with the same inputs.

That’s all well and good, but we don’t have an algorithm to really put on the 
table yet.  We need experience with one.  We know we want to tweak things based 
on biconnectivity, performance, and degree because doing it right day one seems 
unlikely.  Changing algorithms is going to be VERY painful if it’s distributed. 
 

However, if it’s centralized, it’s completely trivial.

So, my strong preference is to start centralized.  Iterate on the algorithm 
until we have it where we want it.  And then take it distributed if there’s a 
point to it.  However, at that point, we have something working.  So why fix it?


> c) req b): the solution should include redundancy (i.e. @ least 2 maximally 
> disjoint vertex covers/lifts) to deal with single link failure (unless the 
> link is unavoidably a minimal cut on the graph) 


Not everyone agrees with this, but some do.  This seems like one possible input 
to the algorithm.


> d) req c): the solution should guarantee disruption free flooding in case of 
>   i) single link failure
>  ii) single node failure
>  iii) change in one of the vertex lifts 


Sorry, I don’t understand point iii).


> e) the solution should not lead to "hot-spot" or "minimal-cut" links which 
> will disrupt flooding between two partitions on failure or lead to flood 
> throughput bottlenecks 


Agreed.

> I am agnostic to Tony L's thinking about diameter and so on. It makes sense 
> but is not necessarily easy to pull into the solution. 


It all boils down to the point that Peter just made about performance.  A 
topology with a high diameter is going to require many flooding hops and hurt 
performance.  To be avoided...


> moreover, I observe that IME ISIS is much more robust under such 
> optimizations since the CSNPs catch (@ a somehow ugly delay cost) any corner 
> cases whereas OSPF after IDBE will happily stay out of sync forever if 
> flooding skips something (that may actually become a reason to introduce 
> periodic stuff on OSPF to do CSNP equivalent albeit it won't be trivial in 
> backwards compatible way on my first thought, I was thinking a bit about 
> cut/snapshot consistency check [in practical terms OSPF hellos could carry a 
> checksum on the DB headers] but we never have that luxury on a link-state 
> routing protocol [i.e. we always operate under unbounded epsilon consistency 
> ;-) and in case of BGP stable oscialltions BTW not even that ;^} ]). 

Emacs

Tony


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

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Peter Psenak]

Hi Tony,

On 24/08/18 17:03 , tony...@tony.li wrote:


So, going Old Skool here:

Since everyone agrees that this is a reasonable direction, how about we have a 
real discussion on the list?

Requirement number 1 is straightforward: a significant reduction in flooding 
overhead.

The basis for this requirement is the understanding that in a dense topology, 
there is a great deal of redundancy due to flooding, and that it is this 
redundancy that supersaturates the control plane.

Do we agree on this?


absolutely.

I would add that the flooding reduction should not add significant delay 
to the flooding time compared to the regular flooding case.


thanks,
Peter



Tony

.



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

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Tony Przygienda]

OK, good, real work. So from some scar tissue here's one question

a) we are talking any kind of topology for the solution, i.e. generic
graph?

and then suggestion for IME realistic, operational MUST requirements

b) req a): the solution should support distributed and centralized
algorithm to compute/signal reduced mesh(es). I personally think
distributed is the more practical choice for something like this but it's
my 2c from having lived the telephony controller fashion, the distributed
fashion and the controller fashion now again ;-)
c) req b): the solution should include redundancy (i.e. @ least 2 maximally
disjoint vertex covers/lifts) to deal with single link failure (unless the
link is unavoidably a minimal cut on the graph)
d) req c): the solution should guarantee disruption free flooding in case
of
  i) single link failure
 ii) single node failure
 iii) change in one of the vertex lifts
e) the solution should not lead to "hot-spot" or "minimal-cut" links which
will disrupt flooding between two partitions on failure or lead to flood
throughput bottlenecks

I am agnostic to Tony L's thinking about diameter and so on. It makes sense
but is not necessarily easy to pull into the solution.

moreover, I observe that IME ISIS is much more robust under such
optimizations since the CSNPs catch (@ a somehow ugly delay cost) any
corner cases whereas OSPF after IDBE will happily stay out of sync forever
if flooding skips something (that may actually become a reason to introduce
periodic stuff on OSPF to do CSNP equivalent albeit it won't be trivial in
backwards compatible way on my first thought, I was thinking a bit about
cut/snapshot consistency check [in practical terms OSPF hellos could carry
a checksum on the DB headers] but we never have that luxury on a link-state
routing protocol [i.e. we always operate under unbounded epsilon
consistency ;-) and in case of BGP stable oscialltions BTW not even that
;^} ]).

--- tony


On Fri, Aug 24, 2018 at 8:36 AM Acee Lindem (acee)  wrote:

> Speaking as WG member:
>
> I agree on this and don't believe we need a separate document or a
> protracted discussion.
> Additionally, I don't think we should worry about anything going on in
> other WGs.
> Thanks,
> Acee
> P.S. I'll provide more input to the discussion as well. As luck would have
> it, I initiated the discussion and then had a couple more pressing matters
> (including the cable company's fiber installation contractor messing up my
> irrigation system ;^(
>
> On 8/24/18, 11:04 AM, "Lsr on behalf of tony...@tony.li" <
> lsr-boun...@ietf.org on behalf of tony...@tony.li> wrote:
>
>
> So, going Old Skool here:
>
> Since everyone agrees that this is a reasonable direction, how about
> we have a real discussion on the list?
>
> Requirement number 1 is straightforward: a significant reduction in
> flooding overhead.
>
> The basis for this requirement is the understanding that in a dense
> topology, there is a great deal of redundancy due to flooding, and that it
> is this redundancy that supersaturates the control plane.
>
> Do we agree on this?
>
> 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
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Acee Lindem (acee)]

Speaking as WG member:

I agree on this and don't believe we need a separate document or a protracted 
discussion. 
Additionally, I don't think we should worry about anything going on in other 
WGs. 
Thanks,
Acee
P.S. I'll provide more input to the discussion as well. As luck would have it, 
I initiated the discussion and then had a couple more pressing matters 
(including the cable company's fiber installation contractor messing up my 
irrigation system ;^( 

On 8/24/18, 11:04 AM, "Lsr on behalf of tony...@tony.li"  wrote:


So, going Old Skool here:

Since everyone agrees that this is a reasonable direction, how about we 
have a real discussion on the list?

Requirement number 1 is straightforward: a significant reduction in 
flooding overhead.

The basis for this requirement is the understanding that in a dense 
topology, there is a great deal of redundancy due to flooding, and that it is 
this redundancy that supersaturates the control plane.

Do we agree on this?

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] LSR Flooding Reduction Drafts - Moving Forward

[tony . li]

So, going Old Skool here:

Since everyone agrees that this is a reasonable direction, how about we have a 
real discussion on the list?

Requirement number 1 is straightforward: a significant reduction in flooding 
overhead.

The basis for this requirement is the understanding that in a dense topology, 
there is a great deal of redundancy due to flooding, and that it is this 
redundancy that supersaturates the control plane.

Do we agree on this?

Tony

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

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Peter Psenak]

Hi Jeff,

On 24/08/18 00:59 , Jeff Tantsura wrote:

Peter,

As previously stated - I'm against gating, it should be developed in parallel 
and with cooperation with the ongoing/existing work.
Note - there's a document (albeit expired, it played its role) that talks about 
generic DC Routing requirements, work in LSR would be scooped to LSR only.
So no going into religious discussions - new vs old/ls vs pv, etc, but focusing 
on ospf/isis and what is needed for DC specifically.
I think it would be good to do some gain/complexity mental exercise...


fair enough. I'm willing to contribute.

thanks,
Peter



Cheers,
Jeff

On 8/23/18, 02:05, "Peter Psenak"  wrote:

 Jeff, All,

 we have added many extensions to IGP protocols over the years. Many
 times multiple solutions were proposed for the same or similar problem
 and WG picked from the set, many times multiple solutions were merged or
 combined together. We never asked for a requirement document. Even for
 more significant changes then we are talking about here.

 I understand that the area of DC routing using IGPs is a broader area,
 but it does not fundamentally change IGPs to warrant the need for
 requirement document as a prerequisite to move forward with any work
 that is related to any optimization that may be applicable to DC
 environment.

 So while I'm not against the existence of the document that would cover
 the requirements for IGPs in DC environments , I don't believe we should
 gate all proposed work in this space by such a document. And to be
 completely honest, the requirements are pretty straightforward for
 anyone that is familiar with the protocols' operation.

 my 2c,
 Peter

 On 22/08/18 18:42 , Jeff Tantsura wrote:
 > +1 Tony
 >
 > We could start with a document, similar to dc-routing requirements one
 > we did in RTGWG before chartering RIFT and LSVR.
 > Would help to disambiguate requirements from claims and have apple to
 > apple comparison.
 > Doing it on github was a good experience.
 >
 >
 > Regards,
 > Jeff
 >
 > On Aug 22, 2018, at 09:27, Tony Li  > wrote:
 >
 >>
 >>
 >>> At IETF 102, there was no dearth of flooding reduction proposals.  In
 >>> fact, we have so many proposals that there wasn’t agree as how to
 >>> move forward and we agreed to discuss on the list. This Email is to
 >>> initiate that discussion (which I intend to participate in but as a
 >>> WG member).
 >>
 >>
 >> Hi Acee,
 >>
 >> Perhaps a useful starting point of the discussion is to talk about
 >> requirements.  There seem to many different perceptions.
 >>
 >> 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
 >




.



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

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Jeff Tantsura]

Peter,

As previously stated - I'm against gating, it should be developed in parallel 
and with cooperation with the ongoing/existing work.
Note - there's a document (albeit expired, it played its role) that talks about 
generic DC Routing requirements, work in LSR would be scooped to LSR only.
So no going into religious discussions - new vs old/ls vs pv, etc, but focusing 
on ospf/isis and what is needed for DC specifically.
I think it would be good to do some gain/complexity mental exercise...  

Cheers,
Jeff

On 8/23/18, 02:05, "Peter Psenak"  wrote:

Jeff, All,

we have added many extensions to IGP protocols over the years. Many 
times multiple solutions were proposed for the same or similar problem 
and WG picked from the set, many times multiple solutions were merged or 
combined together. We never asked for a requirement document. Even for 
more significant changes then we are talking about here.

I understand that the area of DC routing using IGPs is a broader area, 
but it does not fundamentally change IGPs to warrant the need for 
requirement document as a prerequisite to move forward with any work 
that is related to any optimization that may be applicable to DC 
environment.

So while I'm not against the existence of the document that would cover 
the requirements for IGPs in DC environments , I don't believe we should 
gate all proposed work in this space by such a document. And to be 
completely honest, the requirements are pretty straightforward for 
anyone that is familiar with the protocols' operation.

my 2c,
Peter

On 22/08/18 18:42 , Jeff Tantsura wrote:
> +1 Tony
>
> We could start with a document, similar to dc-routing requirements one
> we did in RTGWG before chartering RIFT and LSVR.
> Would help to disambiguate requirements from claims and have apple to
> apple comparison.
> Doing it on github was a good experience.
>
>
> Regards,
> Jeff
>
> On Aug 22, 2018, at 09:27, Tony Li  > wrote:
>
>>
>>
>>> At IETF 102, there was no dearth of flooding reduction proposals.  In
>>> fact, we have so many proposals that there wasn’t agree as how to
>>> move forward and we agreed to discuss on the list. This Email is to
>>> initiate that discussion (which I intend to participate in but as a
>>> WG member).
>>
>>
>> Hi Acee,
>>
>> Perhaps a useful starting point of the discussion is to talk about
>> requirements.  There seem to many different perceptions.
>>
>> 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
>




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

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Huaimo Chen]

Hi Tony,

Regarding to the issues/problems you mentioned for flooding reduction 
(using distributed algorithm), can you give some more details?

Best Regards,
Huaimo
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Tony Przygienda
Sent: Wednesday, August 22, 2018 2:59 PM
To: ginsberg=40cisco@dmarc.ietf.org
Cc: lsr@ietf.org; Jeff Tantsura ; Tony Li 
; acee=40cisco@dmarc.ietf.org
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

I do think it is a good idea in a sense to somehow outline WHAT problem is 
being solved via some write-down or mind-melt

a) I hope it's captured in the meeting notes but otherwise running the danger 
of repeating myself, the problem splits along the line of "directed graphs" 
(basically lattices) which DC topologies are today and generic graphs. In first 
case problem can be solved quite well (Pascal's idea based loosely on MANET in 
RIFT that could be stretched to flat flooding as well), in 2nd it's much harder.
b) Beside pure reduction, aspects like redundancy of the resulting mesh(es), 
minimal-cut properties and load balancing aspects emerge from practical pursuit 
of the problem (let's not even mention the dynamic re-convergence problems no 
matter whether some centralized instance floods or async distributed algorithm 
is run). Hence the scope or scopes of what needs being done seems prudent.
c) ultimately, other things like link properties and resulting meshes play a 
big role (MANET). In sparse networks we lived quite well without reduction but 
MANET/DSR had to deal with it already AFAIR & IP fabric seem to cause a 
different variation of the limitation to rear its head

2c

--- tony

On Wed, Aug 22, 2018 at 11:04 AM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
In the discussions which led to the creation of LSVR and RIFT WGs, considerable 
interest was expressed in working on enhancements to existing Link State 
protocols. You can peruse the dcrouting mailing list archives.

https://mailarchive.ietf.org/arch/browse/dcrouting/

It is rather befuddling to me that the IETF seems to have decided to move 
forward on two new protocols (no objection from me) but seems to feel there is 
insufficient reason to move forward on proposals to extend existing IGPs.
I think the suggestion that we need to write (yet another)  requirements 
document before doing so is a recipe for delay – not for progress.

Multiple drafts have been presented over the course of the past two years and 
discussed on the list as well.
In the case of two of the drafts:

draft-shen-isis-spine-leaf-ext
draft-li-dynamic-flooding

WG adoption was requested in Montreal..

Please explain why we cannot proceed with “business as usual” as regards these 
drafts.


   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Jeff 
Tantsura
Sent: Wednesday, August 22, 2018 9:43 AM
To: Tony Li mailto:tony1ath...@gmail.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Acee Lindem (acee) 
mailto:40cisco....@dmarc.ietf.org>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

+1 Tony

We could start with a document, similar to dc-routing requirements one we did 
in RTGWG before chartering RIFT and LSVR.
Would help to disambiguate requirements from claims and have apple to apple 
comparison.
Doing it on github was a good experience.

Regards,
Jeff

On Aug 22, 2018, at 09:27, Tony Li 
mailto:tony1ath...@gmail.com>> wrote:


At IETF 102, there was no dearth of flooding reduction proposals.  In fact, we 
have so many proposals that there wasn’t agree as how to move forward and we 
agreed to discuss on the list. This Email is to initiate that discussion (which 
I intend to participate in but as a WG member).


Hi Acee,

Perhaps a useful starting point of the discussion is to talk about 
requirements.  There seem to many different perceptions..

Regards,
Tony


___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www..ietf.org/mailman/listinfo/lsr<https://www.ietf.org/mailman/listinfo/lsr>
___
Lsr mailing list
Lsr@ietf.org<mailto: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] LSR Flooding Reduction Drafts - Moving Forward

[Tony Przygienda]

On Thu, Aug 23, 2018 at 2:05 AM Peter Psenak  wrote:

> ...
>   And to be
> completely honest, the requirements are pretty straightforward for
> anyone that is familiar with the protocols' operation.
>
>
The signalling is quite simple as often the case, good quality algorithms,
especially distributed versions, anything but IME ...

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

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Peter Psenak]

Jeff, All,

we have added many extensions to IGP protocols over the years. Many 
times multiple solutions were proposed for the same or similar problem 
and WG picked from the set, many times multiple solutions were merged or 
combined together. We never asked for a requirement document. Even for 
more significant changes then we are talking about here.


I understand that the area of DC routing using IGPs is a broader area, 
but it does not fundamentally change IGPs to warrant the need for 
requirement document as a prerequisite to move forward with any work 
that is related to any optimization that may be applicable to DC 
environment.


So while I'm not against the existence of the document that would cover 
the requirements for IGPs in DC environments , I don't believe we should 
gate all proposed work in this space by such a document. And to be 
completely honest, the requirements are pretty straightforward for 
anyone that is familiar with the protocols' operation.


my 2c,
Peter

On 22/08/18 18:42 , Jeff Tantsura wrote:

+1 Tony

We could start with a document, similar to dc-routing requirements one
we did in RTGWG before chartering RIFT and LSVR.
Would help to disambiguate requirements from claims and have apple to
apple comparison.
Doing it on github was a good experience.


Regards,
Jeff

On Aug 22, 2018, at 09:27, Tony Li mailto:tony1ath...@gmail.com>> wrote:





At IETF 102, there was no dearth of flooding reduction proposals.  In
fact, we have so many proposals that there wasn’t agree as how to
move forward and we agreed to discuss on the list. This Email is to
initiate that discussion (which I intend to participate in but as a
WG member).



Hi Acee,

Perhaps a useful starting point of the discussion is to talk about
requirements.  There seem to many different perceptions.

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



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

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Dean cheng]

Yes – there are improvements desired (e.g., flooding reduction)
for DC environment but also beneficial in general; but there may
require scenario specific solutions (optional & pluggable?).
Dean

From: Naiming Shen (naiming) [mailto:naim...@cisco.com]
Sent: Wednesday, August 22, 2018 5:42 PM
To: Dean cheng 
Cc: Les Ginsberg (ginsberg) ; lsr@ietf.org; Jeff Tantsura 
; Tony Li ; Acee Lindem (acee) 

Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward


Agreed. Also for the relatively-long term solution, I doubt there is
an one-size-fits-all solution. We need to have enough building blocks
in protocols and any data center design/operation can utilize with
to achieve their operational goal.

Regards,
- Naiming

On Aug 22, 2018, at 5:22 PM, Dean cheng 
mailto:dean.ch...@huawei.com>> wrote:

This two-approach approach makes sense, since it tends to provide a solution
in a short term but also lay out a foundation for the relatively-long term. And
hopefully some elements deployed in the short term can be leveraged and
further tuned for the long term solution.

Dean

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Naiming Shen (naiming)
Sent: Wednesday, August 22, 2018 12:19 PM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Li 
mailto:tony1ath...@gmail.com>>; Acee Lindem (acee) 
mailto:acee=40cisco....@dmarc.ietf.org>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward


I do think to solve all the data centers (massive or small) requirement,
this discussion is very useful. If we can list all the requirements and see
what technical approaches we can do to achieve them.

But incremental improvements on existing protocols is useful also. They may not
solve the complete set of “requirements”, but they do help data center
and also non-data center deployments to improve their operations.

I would think this group can proceed with both approaches.

Regards,
- Naiming

On Aug 22, 2018, at 11:02 AM, Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
 wrote:

In the discussions which led to the creation of LSVR and RIFT WGs, considerable 
interest was expressed in working on enhancements to existing Link State 
protocols. You can peruse the dcrouting mailing list archives.

https://mailarchive.ietf.org/arch/browse/dcrouting/

It is rather befuddling to me that the IETF seems to have decided to move 
forward on two new protocols (no objection from me) but seems to feel there is 
insufficient reason to move forward on proposals to extend existing IGPs.
I think the suggestion that we need to write (yet another)  requirements 
document before doing so is a recipe for delay – not for progress.

Multiple drafts have been presented over the course of the past two years and 
discussed on the list as well.
In the case of two of the drafts:

draft-shen-isis-spine-leaf-ext
draft-li-dynamic-flooding

WG adoption was requested in Montreal.

Please explain why we cannot proceed with “business as usual” as regards these 
drafts.


   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Jeff 
Tantsura
Sent: Wednesday, August 22, 2018 9:43 AM
To: Tony Li mailto:tony1ath...@gmail.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

+1 Tony

We could start with a document, similar to dc-routing requirements one we did 
in RTGWG before chartering RIFT and LSVR.
Would help to disambiguate requirements from claims and have apple to apple 
comparison.
Doing it on github was a good experience.

Regards,
Jeff

On Aug 22, 2018, at 09:27, Tony Li 
mailto:tony1ath...@gmail.com>> wrote:





At IETF 102, there was no dearth of flooding reduction proposals.  In fact, we 
have so many proposals that there wasn’t agree as how to move forward and we 
agreed to discuss on the list. This Email is to initiate that discussion (which 
I intend to participate in but as a WG member).


Hi Acee,

Perhaps a useful starting point of the discussion is to talk about 
requirements.  There seem to many different perceptions.

Regards,
Tony


___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www..ietf.org/mailman/listinfo/lsr<https://www.ietf.org/mailman/listinfo/lsr>
___
Lsr mailing list
Lsr@ietf.org<mailto: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] LSR Flooding Reduction Drafts - Moving Forward

[Naiming Shen (naiming)]

Agreed. Also for the relatively-long term solution, I doubt there is
an one-size-fits-all solution. We need to have enough building blocks
in protocols and any data center design/operation can utilize with
to achieve their operational goal.

Regards,
- Naiming

On Aug 22, 2018, at 5:22 PM, Dean cheng 
mailto:dean.ch...@huawei.com>> wrote:

This two-approach approach makes sense, since it tends to provide a solution
in a short term but also lay out a foundation for the relatively-long term. And
hopefully some elements deployed in the short term can be leveraged and
further tuned for the long term solution.

Dean

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Naiming Shen (naiming)
Sent: Wednesday, August 22, 2018 12:19 PM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Li 
mailto:tony1ath...@gmail.com>>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward


I do think to solve all the data centers (massive or small) requirement,
this discussion is very useful. If we can list all the requirements and see
what technical approaches we can do to achieve them.

But incremental improvements on existing protocols is useful also. They may not
solve the complete set of “requirements”, but they do help data center
and also non-data center deployments to improve their operations.

I would think this group can proceed with both approaches.

Regards,
- Naiming

On Aug 22, 2018, at 11:02 AM, Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
 wrote:

In the discussions which led to the creation of LSVR and RIFT WGs, considerable 
interest was expressed in working on enhancements to existing Link State 
protocols. You can peruse the dcrouting mailing list archives.

https://mailarchive.ietf.org/arch/browse/dcrouting/

It is rather befuddling to me that the IETF seems to have decided to move 
forward on two new protocols (no objection from me) but seems to feel there is 
insufficient reason to move forward on proposals to extend existing IGPs.
I think the suggestion that we need to write (yet another)  requirements 
document before doing so is a recipe for delay – not for progress.

Multiple drafts have been presented over the course of the past two years and 
discussed on the list as well.
In the case of two of the drafts:

draft-shen-isis-spine-leaf-ext
draft-li-dynamic-flooding

WG adoption was requested in Montreal.

Please explain why we cannot proceed with “business as usual” as regards these 
drafts.


   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Jeff 
Tantsura
Sent: Wednesday, August 22, 2018 9:43 AM
To: Tony Li mailto:tony1ath...@gmail.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Acee Lindem (acee) 
mailto:acee=40cisco....@dmarc.ietf.org>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

+1 Tony

We could start with a document, similar to dc-routing requirements one we did 
in RTGWG before chartering RIFT and LSVR.
Would help to disambiguate requirements from claims and have apple to apple 
comparison.
Doing it on github was a good experience.

Regards,
Jeff

On Aug 22, 2018, at 09:27, Tony Li 
mailto:tony1ath...@gmail.com>> wrote:




At IETF 102, there was no dearth of flooding reduction proposals.  In fact, we 
have so many proposals that there wasn’t agree as how to move forward and we 
agreed to discuss on the list. This Email is to initiate that discussion (which 
I intend to participate in but as a WG member).


Hi Acee,

Perhaps a useful starting point of the discussion is to talk about 
requirements.  There seem to many different perceptions.

Regards,
Tony


___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www..ietf.org/mailman/listinfo/lsr<https://www.ietf.org/mailman/listinfo/lsr>
___
Lsr mailing list
Lsr@ietf.org<mailto: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] LSR Flooding Reduction Drafts - Moving Forward

[Dean cheng]

This two-approach approach makes sense, since it tends to provide a solution
in a short term but also lay out a foundation for the relatively-long term. And
hopefully some elements deployed in the short term can be leveraged and
further tuned for the long term solution.

Dean

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Naiming Shen (naiming)
Sent: Wednesday, August 22, 2018 12:19 PM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Li 
mailto:tony1ath...@gmail.com>>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward


I do think to solve all the data centers (massive or small) requirement,
this discussion is very useful. If we can list all the requirements and see
what technical approaches we can do to achieve them.

But incremental improvements on existing protocols is useful also. They may not
solve the complete set of “requirements”, but they do help data center
and also non-data center deployments to improve their operations.

I would think this group can proceed with both approaches.

Regards,
- Naiming

On Aug 22, 2018, at 11:02 AM, Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
 wrote:

In the discussions which led to the creation of LSVR and RIFT WGs, considerable 
interest was expressed in working on enhancements to existing Link State 
protocols. You can peruse the dcrouting mailing list archives.

https://mailarchive.ietf.org/arch/browse/dcrouting/

It is rather befuddling to me that the IETF seems to have decided to move 
forward on two new protocols (no objection from me) but seems to feel there is 
insufficient reason to move forward on proposals to extend existing IGPs.
I think the suggestion that we need to write (yet another)  requirements 
document before doing so is a recipe for delay – not for progress.

Multiple drafts have been presented over the course of the past two years and 
discussed on the list as well.
In the case of two of the drafts:

draft-shen-isis-spine-leaf-ext
draft-li-dynamic-flooding

WG adoption was requested in Montreal.

Please explain why we cannot proceed with “business as usual” as regards these 
drafts.


   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Jeff 
Tantsura
Sent: Wednesday, August 22, 2018 9:43 AM
To: Tony Li mailto:tony1ath...@gmail.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

+1 Tony

We could start with a document, similar to dc-routing requirements one we did 
in RTGWG before chartering RIFT and LSVR.
Would help to disambiguate requirements from claims and have apple to apple 
comparison.
Doing it on github was a good experience.

Regards,
Jeff

On Aug 22, 2018, at 09:27, Tony Li 
mailto:tony1ath...@gmail.com>> wrote:




At IETF 102, there was no dearth of flooding reduction proposals.  In fact, we 
have so many proposals that there wasn’t agree as how to move forward and we 
agreed to discuss on the list. This Email is to initiate that discussion (which 
I intend to participate in but as a WG member).


Hi Acee,

Perhaps a useful starting point of the discussion is to talk about 
requirements.  There seem to many different perceptions.

Regards,
Tony


___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www..ietf.org/mailman/listinfo/lsr<https://www.ietf.org/mailman/listinfo/lsr>
___
Lsr mailing list
Lsr@ietf.org<mailto: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] LSR Flooding Reduction Drafts - Moving Forward

[Les Ginsberg (ginsberg)]

Works for me.

Thanx Jeff.

Les


From: Jeff Tantsura 
Sent: Wednesday, August 22, 2018 1:21 PM
To: Les Ginsberg (ginsberg) ; Tony Przygienda 

Cc: Tony Li ; lsr@ietf.org; Acee Lindem (acee) 

Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Les,

Not going to repeat Tony P. points, however I don’t think anyone said – 
requirement document should be a gating factor,  personally, I’d do it same way 
we did in RTGWG – to have a unbiased reference point others can reference to. 
Development of such document should go in parallel with other work and be a 
wg/design team effort.

Hope this clarifies.

Cheers,
Jeff

From: "Les Ginsberg (ginsberg)" mailto:ginsb...@cisco.com>>
Date: Wednesday, August 22, 2018 at 13:10
To: Tony Przygienda mailto:tonysi...@gmail.com>>
Cc: Jeff Tantsura mailto:jefftant.i...@gmail.com>>, 
Tony Li mailto:tony1ath...@gmail.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, "Acee 
Lindem (acee)" mailto:a...@cisco.com>>
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Tony –

The points you make below are good and need to be considered.

But let’s examine what work we have that we could do now.

1)draft-li-dynamic-flooding

This defines modest protocol extensions to support use of flooding reduction 
algorithms in  any type of topology. Note that it does not (not yet anyway…) 
specify any algorithms.
Adopting this draft would allow us to define the extensions necessary to enable 
the use of alternate algorithms and to get immediate benefits from the use of 
some well known algorithms. Since it does not preclude (and is a necessary 
infra for)  the use of any algorithm, and it allows support for many algorithms 
(NOT simultaneously though ☺ ) it does not prevent any future algorithmic 
solutions from being used.

In parallel with this, discussion/research of points such as you mention below 
can be done, but I do not see why we should not proceed with this work 
immediately.

2)Flooding reduction drafts specific to Clos topologies

There are multiple candidates – and I am obviously biased since I have a horse 
in the race (draft-shen-isis-spine-leaf-ext),  but the point is we have 
proposals that have practical benefits and have received support. So long as 
they are compatible with draft-li-dynamic-flooding I again do not see why these 
cannot move forward now.

Further research/discussion is a fine thing, but that should not prevent us 
from realizing real benefits now – especially since we can do so in a way that 
is future-proofed.

   Les



From: Tony Przygienda mailto:tonysi...@gmail.com>>
Sent: Wednesday, August 22, 2018 11:59 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Cc: Jeff Tantsura mailto:jefftant.i...@gmail.com>>; 
Tony Li mailto:tony1ath...@gmail.com>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Acee Lindem (acee) 
mailto:a...@cisco.com>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

I do think it is a good idea in a sense to somehow outline WHAT problem is 
being solved via some write-down or mind-melt

a) I hope it's captured in the meeting notes but otherwise running the danger 
of repeating myself, the problem splits along the line of "directed graphs" 
(basically lattices) which DC topologies are today and generic graphs. In first 
case problem can be solved quite well (Pascal's idea based loosely on MANET in 
RIFT that could be stretched to flat flooding as well), in 2nd it's much harder.
b) Beside pure reduction, aspects like redundancy of the resulting mesh(es), 
minimal-cut properties and load balancing aspects emerge from practical pursuit 
of the problem (let's not even mention the dynamic re-convergence problems no 
matter whether some centralized instance floods or async distributed algorithm 
is run). Hence the scope or scopes of what needs being done seems prudent.
c) ultimately, other things like link properties and resulting meshes play a 
big role (MANET). In sparse networks we lived quite well without reduction but 
MANET/DSR had to deal with it already AFAIR & IP fabric seem to cause a 
different variation of the limitation to rear its head

2c

--- tony

On Wed, Aug 22, 2018 at 11:04 AM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
In the discussions which led to the creation of LSVR and RIFT WGs, considerable 
interest was expressed in working on enhancements to existing Link State 
protocols. You can peruse the dcrouting mailing list archives.

https://mailarchive.ietf.org/arch/browse/dcrouting/

It is rather befuddling to me that the IETF seems to have decided to move 
forward on two new protocols (no objection from me) but seems to feel there is 
insufficient reason to move forward on proposals to extend existing IGPs.
I think the suggestion that we need to write (yet another)  requirements 
document befo

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Jeff Tantsura]

Naiming,

 

That’s would be the goal, not to boil the ocean (again)the constrain part would 
be “improvements on existing protocols”, since we are in LSR, perhaps further 
scoped to ISIS/OSPF.

 

Cheers,

Jeff

 

From: "Naiming Shen (naiming)" 
Date: Wednesday, August 22, 2018 at 12:19
To: "Les Ginsberg (ginsberg)" 
Cc: Jeff Tantsura , Tony Li , 
"lsr@ietf.org" , "Acee Lindem (acee)" 

Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

 

 

I do think to solve all the data centers (massive or small) requirement, 

this discussion is very useful. If we can list all the requirements and see

what technical approaches we can do to achieve them.

 

But incremental improvements on existing protocols is useful also. They may not

solve the complete set of “requirements”, but they do help data center

and also non-data center deployments to improve their operations.

 

I would think this group can proceed with both approaches.

 

Regards,

- Naiming

 

On Aug 22, 2018, at 11:02 AM, Les Ginsberg (ginsberg) 
 wrote:

 

In the discussions which led to the creation of LSVR and RIFT WGs, considerable 
interest was expressed in working on enhancements to existing Link State 
protocols. You can peruse the dcrouting mailing list archives.

 

https://mailarchive.ietf.org/arch/browse/dcrouting/

 

It is rather befuddling to me that the IETF seems to have decided to move 
forward on two new protocols (no objection from me) but seems to feel there is 
insufficient reason to move forward on proposals to extend existing IGPs.

I think the suggestion that we need to write (yet another)  requirements 
document before doing so is a recipe for delay – not for progress.

 

Multiple drafts have been presented over the course of the past two years and 
discussed on the list as well.

In the case of two of the drafts:

 

draft-shen-isis-spine-leaf-ext

draft-li-dynamic-flooding

 

WG adoption was requested in Montreal.

 

Please explain why we cannot proceed with “business as usual” as regards these 
drafts.

 

 

   Les

 

 

From: Lsr  On Behalf Of Jeff Tantsura
Sent: Wednesday, August 22, 2018 9:43 AM
To: Tony Li 
Cc: lsr@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

 

+1 Tony

 

We could start with a document, similar to dc-routing requirements one we did 
in RTGWG before chartering RIFT and LSVR.

Would help to disambiguate requirements from claims and have apple to apple 
comparison.

Doing it on github was a good experience.

 

Regards,

Jeff


On Aug 22, 2018, at 09:27, Tony Li  wrote:

 




At IETF 102, there was no dearth of flooding reduction proposals.  In fact, we 
have so many proposals that there wasn’t agree as how to move forward and we 
agreed to discuss on the list. This Email is to initiate that discussion (which 
I intend to participate in but as a WG member). 

 

 

Hi Acee,

 

Perhaps a useful starting point of the discussion is to talk about 
requirements.  There seem to many different perceptions.

 

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

 

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

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Jeff Tantsura]

Les,

 

Not going to repeat Tony P. points, however I don’t think anyone said – 
requirement document should be a gating factor,  personally, I’d do it same way 
we did in RTGWG – to have a unbiased reference point others can reference to. 
Development of such document should go in parallel with other work and be a 
wg/design team effort. 

 

Hope this clarifies.

 

Cheers,

Jeff

 

From: "Les Ginsberg (ginsberg)" 
Date: Wednesday, August 22, 2018 at 13:10
To: Tony Przygienda 
Cc: Jeff Tantsura , Tony Li , 
"lsr@ietf.org" , "Acee Lindem (acee)" 
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

 

Tony –

 

The points you make below are good and need to be considered.

 

But let’s examine what work we have that we could do now.

 

1)draft-li-dynamic-flooding

 

This defines modest protocol extensions to support use of flooding reduction 
algorithms in  any type of topology. Note that it does not (not yet anyway…) 
specify any algorithms.

Adopting this draft would allow us to define the extensions necessary to enable 
the use of alternate algorithms and to get immediate benefits from the use of 
some well known algorithms. Since it does not preclude (and is a necessary 
infra for)  the use of any algorithm, and it allows support for many algorithms 
(NOT simultaneously though J ) it does not prevent any future algorithmic 
solutions from being used.

 

In parallel with this, discussion/research of points such as you mention below 
can be done, but I do not see why we should not proceed with this work 
immediately. 

 

2)Flooding reduction drafts specific to Clos topologies

 

There are multiple candidates – and I am obviously biased since I have a horse 
in the race (draft-shen-isis-spine-leaf-ext),  but the point is we have 
proposals that have practical benefits and have received support. So long as 
they are compatible with draft-li-dynamic-flooding I again do not see why these 
cannot move forward now.

 

Further research/discussion is a fine thing, but that should not prevent us 
from realizing real benefits now – especially since we can do so in a way that 
is future-proofed.

 

   Les

 

 

 

From: Tony Przygienda  
Sent: Wednesday, August 22, 2018 11:59 AM
To: Les Ginsberg (ginsberg) 
Cc: Jeff Tantsura ; Tony Li ; 
lsr@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

 

I do think it is a good idea in a sense to somehow outline WHAT problem is 
being solved via some write-down or mind-melt 

 

a) I hope it's captured in the meeting notes but otherwise running the danger 
of repeating myself, the problem splits along the line of "directed graphs" 
(basically lattices) which DC topologies are today and generic graphs. In first 
case problem can be solved quite well (Pascal's idea based loosely on MANET in 
RIFT that could be stretched to flat flooding as well), in 2nd it's much 
harder. 

b) Beside pure reduction, aspects like redundancy of the resulting mesh(es), 
minimal-cut properties and load balancing aspects emerge from practical pursuit 
of the problem (let's not even mention the dynamic re-convergence problems no 
matter whether some centralized instance floods or async distributed algorithm 
is run). Hence the scope or scopes of what needs being done seems prudent.

c) ultimately, other things like link properties and resulting meshes play a 
big role (MANET). In sparse networks we lived quite well without reduction but 
MANET/DSR had to deal with it already AFAIR & IP fabric seem to cause a 
different variation of the limitation to rear its head

 

2c

 

--- tony 

 

On Wed, Aug 22, 2018 at 11:04 AM Les Ginsberg (ginsberg) 
 wrote:

In the discussions which led to the creation of LSVR and RIFT WGs, considerable 
interest was expressed in working on enhancements to existing Link State 
protocols. You can peruse the dcrouting mailing list archives.

 

https://mailarchive.ietf.org/arch/browse/dcrouting/

 

It is rather befuddling to me that the IETF seems to have decided to move 
forward on two new protocols (no objection from me) but seems to feel there is 
insufficient reason to move forward on proposals to extend existing IGPs.

I think the suggestion that we need to write (yet another)  requirements 
document before doing so is a recipe for delay – not for progress.

 

Multiple drafts have been presented over the course of the past two years and 
discussed on the list as well.

In the case of two of the drafts:

 

draft-shen-isis-spine-leaf-ext

draft-li-dynamic-flooding

 

WG adoption was requested in Montreal..

 

Please explain why we cannot proceed with “business as usual” as regards these 
drafts.

 

 

   Les

 

 

From: Lsr  On Behalf Of Jeff Tantsura
Sent: Wednesday, August 22, 2018 9:43 AM
To: Tony Li 
Cc: lsr@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

 

+1 Tony

 

We could start with a docu

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Huaimo Chen]

It is better to have some short discussions about the requirements. Some 
requirements were presented and discussed in RTGWG. With some new additions and 
discussions , we should have a good set of requirements.

Best Regards,
Huaimo
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Naiming Shen (naiming)
Sent: Wednesday, August 22, 2018 3:19 PM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org; Jeff Tantsura ; Tony Li 
; Acee Lindem (acee) 
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward


I do think to solve all the data centers (massive or small) requirement,
this discussion is very useful. If we can list all the requirements and see
what technical approaches we can do to achieve them.

But incremental improvements on existing protocols is useful also. They may not
solve the complete set of “requirements”, but they do help data center
and also non-data center deployments to improve their operations.

I would think this group can proceed with both approaches.

Regards,
- Naiming

On Aug 22, 2018, at 11:02 AM, Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
 wrote:

In the discussions which led to the creation of LSVR and RIFT WGs, considerable 
interest was expressed in working on enhancements to existing Link State 
protocols. You can peruse the dcrouting mailing list archives.

https://mailarchive.ietf.org/arch/browse/dcrouting/

It is rather befuddling to me that the IETF seems to have decided to move 
forward on two new protocols (no objection from me) but seems to feel there is 
insufficient reason to move forward on proposals to extend existing IGPs.
I think the suggestion that we need to write (yet another)  requirements 
document before doing so is a recipe for delay – not for progress.

Multiple drafts have been presented over the course of the past two years and 
discussed on the list as well.
In the case of two of the drafts:

draft-shen-isis-spine-leaf-ext
draft-li-dynamic-flooding

WG adoption was requested in Montreal.

Please explain why we cannot proceed with “business as usual” as regards these 
drafts.


   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Jeff 
Tantsura
Sent: Wednesday, August 22, 2018 9:43 AM
To: Tony Li mailto:tony1ath...@gmail.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

+1 Tony

We could start with a document, similar to dc-routing requirements one we did 
in RTGWG before chartering RIFT and LSVR.
Would help to disambiguate requirements from claims and have apple to apple 
comparison.
Doing it on github was a good experience.

Regards,
Jeff

On Aug 22, 2018, at 09:27, Tony Li 
mailto:tony1ath...@gmail.com>> wrote:




At IETF 102, there was no dearth of flooding reduction proposals.  In fact, we 
have so many proposals that there wasn’t agree as how to move forward and we 
agreed to discuss on the list. This Email is to initiate that discussion (which 
I intend to participate in but as a WG member).


Hi Acee,

Perhaps a useful starting point of the discussion is to talk about 
requirements.  There seem to many different perceptions.

Regards,
Tony


___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www..ietf.org/mailman/listinfo/lsr<https://www.ietf.org/mailman/listinfo/lsr>
___
Lsr mailing list
Lsr@ietf.org<mailto: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] LSR Flooding Reduction Drafts - Moving Forward

[Tony Przygienda]

I do think it is a good idea in a sense to somehow outline WHAT problem is
being solved via some write-down or mind-melt

a) I hope it's captured in the meeting notes but otherwise running the
danger of repeating myself, the problem splits along the line of "directed
graphs" (basically lattices) which DC topologies are today and generic
graphs. In first case problem can be solved quite well (Pascal's idea based
loosely on MANET in RIFT that could be stretched to flat flooding as well),
in 2nd it's much harder.
b) Beside pure reduction, aspects like redundancy of the resulting
mesh(es), minimal-cut properties and load balancing aspects emerge from
practical pursuit of the problem (let's not even mention the dynamic
re-convergence problems no matter whether some centralized instance floods
or async distributed algorithm is run). Hence the scope or scopes of what
needs being done seems prudent.
c) ultimately, other things like link properties and resulting meshes play
a big role (MANET). In sparse networks we lived quite well without
reduction but MANET/DSR had to deal with it already AFAIR & IP fabric seem
to cause a different variation of the limitation to rear its head

2c

--- tony

On Wed, Aug 22, 2018 at 11:04 AM Les Ginsberg (ginsberg)  wrote:

> In the discussions which led to the creation of LSVR and RIFT WGs,
> considerable interest was expressed in working on enhancements to existing
> Link State protocols. You can peruse the dcrouting mailing list archives.
>
>
>
> https://mailarchive.ietf.org/arch/browse/dcrouting/
>
>
>
> It is rather befuddling to me that the IETF seems to have decided to move
> forward on two new protocols (no objection from me) but seems to feel there
> is insufficient reason to move forward on proposals to extend existing IGPs.
>
> I think the suggestion that we need to write (yet another)  requirements
> document before doing so is a recipe for delay – not for progress..
>
>
>
> Multiple drafts have been presented over the course of the past two years
> and discussed on the list as well.
>
> In the case of two of the drafts:
>
>
>
> draft-shen-isis-spine-leaf-ext
>
> draft-li-dynamic-flooding
>
>
>
> WG adoption was requested in Montreal.
>
>
>
> Please explain why we cannot proceed with “business as usual” as regards
> these drafts.
>
>
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of *Jeff Tantsura
> *Sent:* Wednesday, August 22, 2018 9:43 AM
> *To:* Tony Li 
> *Cc:* lsr@ietf.org; Acee Lindem (acee) 
> *Subject:* Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward
>
>
>
> +1 Tony
>
>
>
> We could start with a document, similar to dc-routing requirements one we
> did in RTGWG before chartering RIFT and LSVR.
>
> Would help to disambiguate requirements from claims and have apple to
> apple comparison.
>
> Doing it on github was a good experience.
>
>
>
> Regards,
>
> Jeff
>
>
> On Aug 22, 2018, at 09:27, Tony Li  wrote:
>
>
>
>
>
> At IETF 102, there was no dearth of flooding reduction proposals.  In
> fact, we have so many proposals that there wasn’t agree as how to move
> forward and we agreed to discuss on the list. This Email is to initiate
> that discussion (which I intend to participate in but as a WG member).
>
>
>
>
>
> Hi Acee,
>
>
>
> Perhaps a useful starting point of the discussion is to talk about
> requirements.  There seem to many different perceptions.
>
>
>
> Regards,
>
> Tony
>
>
>
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www..ietf.org/mailman/listinfo/lsr
> <https://www.ietf.org/mailman/listinfo/lsr>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Les Ginsberg (ginsberg)]

In the discussions which led to the creation of LSVR and RIFT WGs, considerable 
interest was expressed in working on enhancements to existing Link State 
protocols. You can peruse the dcrouting mailing list archives.

https://mailarchive.ietf.org/arch/browse/dcrouting/

It is rather befuddling to me that the IETF seems to have decided to move 
forward on two new protocols (no objection from me) but seems to feel there is 
insufficient reason to move forward on proposals to extend existing IGPs.
I think the suggestion that we need to write (yet another)  requirements 
document before doing so is a recipe for delay – not for progress.

Multiple drafts have been presented over the course of the past two years and 
discussed on the list as well.
In the case of two of the drafts:

draft-shen-isis-spine-leaf-ext
draft-li-dynamic-flooding

WG adoption was requested in Montreal.

Please explain why we cannot proceed with “business as usual” as regards these 
drafts.


   Les


From: Lsr  On Behalf Of Jeff Tantsura
Sent: Wednesday, August 22, 2018 9:43 AM
To: Tony Li 
Cc: lsr@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

+1 Tony

We could start with a document, similar to dc-routing requirements one we did 
in RTGWG before chartering RIFT and LSVR.
Would help to disambiguate requirements from claims and have apple to apple 
comparison.
Doing it on github was a good experience.

Regards,
Jeff

On Aug 22, 2018, at 09:27, Tony Li 
mailto:tony1ath...@gmail.com>> wrote:



At IETF 102, there was no dearth of flooding reduction proposals.  In fact, we 
have so many proposals that there wasn’t agree as how to move forward and we 
agreed to discuss on the list. This Email is to initiate that discussion (which 
I intend to participate in but as a WG member).


Hi Acee,

Perhaps a useful starting point of the discussion is to talk about 
requirements.  There seem to many different perceptions.

Regards,
Tony


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

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Jeff Tantsura]

+1 Tony

We could start with a document, similar to dc-routing requirements one we did 
in RTGWG before chartering RIFT and LSVR.
Would help to disambiguate requirements from claims and have apple to apple 
comparison.
Doing it on github was a good experience.


Regards,
Jeff

> On Aug 22, 2018, at 09:27, Tony Li  wrote:
> 
> 
> 
>> At IETF 102, there was no dearth of flooding reduction proposals.  In fact, 
>> we have so many proposals that there wasn’t agree as how to move forward and 
>> we agreed to discuss on the list. This Email is to initiate that discussion 
>> (which I intend to participate in but as a WG member). 
> 
> 
> Hi Acee,
> 
> Perhaps a useful starting point of the discussion is to talk about 
> requirements.  There seem to many different perceptions.
> 
> 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] LSR Flooding Reduction Drafts - Moving Forward

[Tony Li]

> At IETF 102, there was no dearth of flooding reduction proposals.  In fact, 
> we have so many proposals that there wasn’t agree as how to move forward and 
> we agreed to discuss on the list. This Email is to initiate that discussion 
> (which I intend to participate in but as a WG member). 


Hi Acee,

Perhaps a useful starting point of the discussion is to talk about 
requirements.  There seem to many different perceptions.

Regards,
Tony


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