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; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
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; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
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; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
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

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
[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:   

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; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
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; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
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

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
[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://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-4.1
[HC] For this, our draft talks 

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; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
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

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
[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://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-4.1
[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; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
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. 

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; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
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]
Sent: Monday, August 27, 2018 11:31 AM
To: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Cc: tony...@tony.li; 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