date:20231126

[Lsr] 答复: New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

2023-11-26 Thread xuxiaohu_i...@hotmail.com

Hi Tony,

I agree that the mesh group feature described in RFC2973 is a relatively simple 
mechanism to reduce the flooding of LSPs. However, it’s still a little bit 
complex since 1) it relies on a correct static configuration on all links; 2) 
it also modifies the behavior in the transmission of generated LSPs; 3) it 
modifies the transmission behavior of CSNP; 4) mesh groups are required to be 
connected by "transit" circuits which are ‘meshInactive’.

In contrast, the flooding reduction mechanism as proposed in my draft is much 
simpler.

Best regards,
Xiaohu








发件人: Tony Li  代表 Tony Li 
日期: 星期五, 2023年11月24日 00:39
收件人: xuxiaohu_i...@hotmail.com 
抄送: lsr@ietf.org 
主题: Re: [Lsr] New Version Notification for 
draft-xu-lsr-flooding-reduction-in-clos-01.txt

Hi Xiaohu,

What you’re proposing is already described in IS-IS Mesh Groups 
(https://www.rfc-editor.org/rfc/rfc2973.html) and improved upon in Dynamic 
Flooding 
(https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding).

Regards,
Tony


On Nov 23, 2023, at 8:29 AM, xuxiaohu_i...@hotmail.com wrote:

Hi all,

Any comments or suggestions are welcome.

Best regards,
Xiaohu


发件人: internet-dra...@ietf.org 
日期: 星期三, 2023年11月22日 11:37
收件人: Xiaohu Xu 
主题: New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

A new version of Internet-Draft draft-xu-lsr-flooding-reduction-in-clos-01.txt
has been successfully submitted by Xiaohu Xu and posted to the
IETF repository.

Name: draft-xu-lsr-flooding-reduction-in-clos
Revision: 01
Title:Flooding Reduction in CLOS Networks
Date: 2023-11-22
Group:Individual Submission
Pages:6
URL:  
https://www.ietf.org/archive/id/draft-xu-lsr-flooding-reduction-in-clos-01.txt
Status:   
https://datatracker.ietf.org/doc/draft-xu-lsr-flooding-reduction-in-clos/
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-xu-lsr-flooding-reduction-in-clos
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-xu-lsr-flooding-reduction-in-clos-01

Abstract:

   In a CLOS topology, an OSPF (or ISIS) router may receive identical
   copies of an LSA (or LSP) from multiple OSPF (or ISIS) neighbors.
   Moreover, two OSPF (or ISIS) neighbors may exchange the same LSA (or
   LSP) simultaneously.  This results in unnecessary flooding of link-
   state information, which wastes the precious resources of OSPF (or
   ISIS) routers.  Therefore, this document proposes extensions to OSPF
   (or ISIS) to reduce this flooding within CLOS networks.  The
   reduction of OSPF (or ISIS) flooding is highly beneficial for
   improving the scalability of CLOS networks.



The IETF Secretariat


___
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] 答复: 答复: WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

2023-11-26 Thread Aijun Wang

Some additional questions:

 

The draft say “The contents of a multi-part TLV MUST be processed as if they 
were concatenated. If the internals of the TLV contain key information, then 
replication of the key information should be taken to indicate that subsequent 
data MUST be processed as if the subsequent data were concatenated after a 
single copy of the key information.”

 

1) How to deal with the TLV that has no key information? 

2) And, to support multi-part TLV,  the key information (if the TLV has 
such information) for each applied TLV must also be standardized, or else, 
there will be error.

The draft wants to just avoid to tackle such issues(as stated in draft “Having 
inconsistent information in different parts of a MP-TLV is an error and is out 
of scope for this document.), but it should be the MUST part of the solution. 

 

Or else, how to assure the interoperability?

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
Aijun Wang
发送时间: 2023年11月24日 16:11
收件人: 'Yingzhen Qu' ; 
draft-pkaneria-lsr-multi-...@ietf.org; 'lsr' 
主题: [Lsr] 答复: WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 
12/09/2023)

 

Do not support its adoption.

 

The draft just enumerate the requirements of MP-TLV support for relevant TLVs, 
it is not the general solution to the issue.

 

There is no practical way in the draft to assure the current and future 
implementation conforms to the newly defined explicit requirements, because the 
MP-TLV Support sub-TLV is not per-TLV basis, and as stated in the draft, one 
implementation declares support “MP-TLV” can’t assure it supports all relevant 
TLVs. --“It is understood that in reality, a given implementation might 
limit MP-TLV support to particular TLVs based on the needs of the deployment 
scenarios in which it is used”-Will there be many interoperability issues 
arises then? And also varies loop accidents within the network when all of 
vendors declare they support “MP-TLV” but not all of the relevant TLVs?

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: forwardingalgori...@ietf.org   
[mailto:forwardingalgori...@ietf.org] 代表 Yingzhen Qu
发送时间: 2023年11月18日 1:24
收件人: draft-pkaneria-lsr-multi-...@ietf.org 
 ; lsr mailto:lsr@ietf.org> >
主题: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 
12/09/2023)

 

Hi,

 

This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: 
draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org) 
 

 

Please send your support or objection to the list before December 9th, 2023. An 
extra week is allowed for the US Thanksgiving holiday.

 

Thanks,

Yingzhen 

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

Re: [Lsr] IETF 118 LSR Minutes

2023-11-26 Thread Yingzhen Qu

Hi,

The meeting minutes have been updated to include the chat history:
minutes-118-lsr-202311060830-01.md
(ietf.org)


Please review and let us know if any changes need to be made.

Thanks,
Yingzhen

On Sun, Nov 26, 2023 at 3:29 PM Les Ginsberg (ginsberg) 
wrote:

> FWIW –
>
>
>
> The new format for the chatlog is much less readable than previous.
>
>
>
> Here is the format from IETF 116:
>
>
>
> 
>
> Ketan Talaulikar
> 00:39:39
> There is a WG draft for per-algo adj-sid :
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-algorithm-related-adjacency-sid/
>
> If we have large number of links, we are advertising many other
> attributes per link - so I am also missing the point of
> "compressing" only the adj-sid advertisement.
> * Weiqiang Cheng
> 00:41:58
> The similar solution for SRv6 is on the link:
> https://datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/
>
> …
>
> 
>
>
>
> Here is the format from IETF 118:
>
>
>
> 
>
> ", "time": "2023-11-06T09:06:17Z"}, {"author": "Christian Hopps", "text": "
>
> isn't this useful for OSPF too?
>
> ", "time": "2023-11-06T09:06:37Z"}, {"author": "Les Ginsberg", "text": "
>
> Could be - in which case you would have \"OSPF-Support\" module.
>
> ", "time": "2023-11-06T09:07:03Z"}, {"author": "Les Ginsberg", "text": "
>
> Different modules.
>
> …
>
> 
>
>
>
> (BTW, there seems to be no chat history in the minutes for IETF 117)
>
>
>
> If this is because of some meetecho change, please let them know the old
> format was better.
>
> If this is just a format change introduced by the way cut and paste was
> done  to the minutes, it would be nice to update it.
>
>
>
> Thanx.
>
>
>
>Les
>
>
>
> *From:* Lsr  *On Behalf Of * Yingzhen Qu
> *Sent:* Monday, November 20, 2023 6:18 AM
> *To:* lsr ; lsr-chairs 
> *Subject:* [Lsr] IETF 118 LSR Minutes
>
>
>
> Hi,
>
>
>
> The meeting minutes of IETF 118 LSR session is available: IETF-118 : lsr
> 
>
>
>
> Please review and let us know if any corrections are needed.
>
>
>
> Thanks,
>
> Yingzhen
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] IETF 118 LSR Minutes

2023-11-26 Thread Acee Lindem

Les - 
The LSR WG list is no place to vent on this topic. Open a ticket via 
supp...@ietf.org. Also, this would be a good issue to raise in your IETF 118 
survey response. 
Acee

> On Nov 26, 2023, at 18:29, Les Ginsberg (ginsberg)  wrote:
> 
> FWIW –
>  
> The new format for the chatlog is much less readable than previous.
>  
> Here is the format from IETF 116:
>  
> 
> Ketan Talaulikar
> 00:39:39
> There is a WG draft for per-algo adj-sid :
> https://datatracker.ietf.org/doc/draft-ietf-lsr-algorithm-related-adjacency-sid/
> 
> If we have large number of links, we are advertising many other
> attributes per link - so I am also missing the point of
> "compressing" only the adj-sid advertisement.
> * Weiqiang Cheng
> 00:41:58
> The similar solution for SRv6 is on the link:
> https://datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/
> 
> …
> 
>  
> Here is the format from IETF 118:
>  
> 
> ", "time": "2023-11-06T09:06:17Z"}, {"author": "Christian Hopps", "text": "
> isn't this useful for OSPF too?
> ", "time": "2023-11-06T09:06:37Z"}, {"author": "Les Ginsberg", "text": "
> Could be - in which case you would have \"OSPF-Support\" module.
> ", "time": "2023-11-06T09:07:03Z"}, {"author": "Les Ginsberg", "text": "
> Different modules.
> …
> 
>  
> (BTW, there seems to be no chat history in the minutes for IETF 117)
>  
> If this is because of some meetecho change, please let them know the old 
> format was better.
> If this is just a format change introduced by the way cut and paste was done  
> to the minutes, it would be nice to update it.
>  
> Thanx.
>  
>Les
>  
> From: Lsr  On Behalf Of Yingzhen Qu
> Sent: Monday, November 20, 2023 6:18 AM
> To: lsr ; lsr-chairs 
> Subject: [Lsr] IETF 118 LSR Minutes
>  
> Hi,
>  
> The meeting minutes of IETF 118 LSR session is available: IETF-118 : lsr 
> 
>  
> Please review and let us know if any corrections are needed.
>  
> Thanks,
> Yingzhen

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

Re: [Lsr] IETF 118 LSR Minutes

2023-11-26 Thread Les Ginsberg (ginsberg)

FWIW –

The new format for the chatlog is much less readable than previous.

Here is the format from IETF 116:



Ketan Talaulikar
00:39:39
There is a WG draft for per-algo adj-sid :
https://datatracker.ietf.org/doc/draft-ietf-lsr-algorithm-related-adjacency-sid/

If we have large number of links, we are advertising many other
attributes per link - so I am also missing the point of
"compressing" only the adj-sid advertisement.
* Weiqiang Cheng
00:41:58
The similar solution for SRv6 is on the link:
https://datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/
…


Here is the format from IETF 118:


", "time": "2023-11-06T09:06:17Z"}, {"author": "Christian Hopps", "text": "
isn't this useful for OSPF too?
", "time": "2023-11-06T09:06:37Z"}, {"author": "Les Ginsberg", "text": "
Could be - in which case you would have \"OSPF-Support\" module.
", "time": "2023-11-06T09:07:03Z"}, {"author": "Les Ginsberg", "text": "
Different modules.
…


(BTW, there seems to be no chat history in the minutes for IETF 117)

If this is because of some meetecho change, please let them know the old format 
was better.
If this is just a format change introduced by the way cut and paste was done  
to the minutes, it would be nice to update it.

Thanx.

   Les

From: Lsr  On Behalf Of Yingzhen Qu
Sent: Monday, November 20, 2023 6:18 AM
To: lsr ; lsr-chairs 
Subject: [Lsr] IETF 118 LSR Minutes

Hi,

The meeting minutes of IETF 118 LSR session is available: IETF-118 : 
lsr

Please review and let us know if any corrections are needed.

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

Re: [Lsr] New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

2023-11-26 Thread Robert Raszuk

Hey Jeff,

Could you be so kind and defined term: "scaled-out leaf-spine fabrics" ?

Specifically folks watching us here would highly appreciate if we state max
target nodes with vanilla ISIS and max target nodes when your ISIS
implementation supports draft-ietf-lsr-dynamic-flooding


While I am a BGP person I feel pretty strongly that BGP is not a best fit
for the vast majority of DC fabrics in use today.

Cheers,
Robert


On Sun, Nov 26, 2023 at 10:49 PM Jeff Tantsura 
wrote:

> I agree with all aforementioned comments.
>
> Wrt AI/ML networking - if a controller is used, what is required is link
> state exposure northbound and not link state protocol  in the fabric. (I
> could argue for RIFT though ;-))
> I’d urge you to take a look at Meta’s deployment  in their ML clusters
> (publicly available) - they use BGP as the routing protocol to exchange
> reachability (and build ECMP sets) and provide a backup if controller
> computed next hop goes away/before new one has been computed.
> Open R is used northbound to expose the topology (in exactly same way -
> BGP-LS could be used).
>
> To summarize: an LS protocol brings no additional value in scaled-out
> leaf-spine fabrics, without significant modifications -  it doesn’t work in
> irregular topologies such as DF, etc.
> Existing proposals - there are shipping implementations and experience in
> operating it, have proven their relative value in suitable deployments.
>
> Cheers,
> Jeff
>
> > On Nov 26, 2023, at 12:20, Acee Lindem  wrote:
> >
> > Speaking as WG member:
> >
> > I agree. The whole Data Center IGP flooding discussion went on years ago
> and the simplistic enhancement proposed in the subject draft is neither
> relevant or useful now.
> >
> > Thanks,
> > Acee
> >
> >> On Nov 24, 2023, at 11:55 PM, Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
> >>
> >> Xiaohu –
> >> I also point out that there are at least two existing drafts which
> specifically address IS-IS flooding reduction in CLOS networks and do so in
> greater detail and with more robustness than what is in your draft:
> >> https://datatracker.ietf.org/doc/draft-ietf-lsr-distoptflood/
> >> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-spine-leaf-ext/
> >> I do not see a need for yet another draft specifically aimed at CLOS
> networks.
> >> Note that work on draft-ietf-lsr-isis-spine-leaf-ext was suspended due
> to lack of interest in deploying an IGP solution in CLOS networks.
> >> You are suggesting in draft-xu-lsr-fare that AI is going to change
> this. Well, maybe, but if so I think we should return to the solutions
> already available and prioritize work on them.
> >>Les
> >>  From: Lsr  On Behalf Of Tony Li
> >> Sent: Thursday, November 23, 2023 8:39 AM
> >> To: xuxiaohu_i...@hotmail.com
> >> Cc: lsr@ietf.org
> >> Subject: Re: [Lsr] New Version Notification for
> draft-xu-lsr-flooding-reduction-in-clos-01.txt
> >> Hi,
> >> What you’re proposing is already described in IS-IS Mesh Groups (
> https://www.rfc-editor.org/rfc/rfc2973.html) and improved upon in Dynamic
> Flooding (
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding).
> >> Regards,
> >> Tony
> >>
> >>
> >> On Nov 23, 2023, at 8:29 AM, xuxiaohu_i...@hotmail.com wrote:
> >> Hi all,
> >> Any comments or suggestions are welcome.
> >> Best regards,
> >> Xiaohu
> >> 发件人: internet-dra...@ietf.org 
> >> 日期: 星期三, 2023年11月22日 11:37
> >> 收件人: Xiaohu Xu 
> >> 主题: New Version Notification for
> draft-xu-lsr-flooding-reduction-in-clos-01.txt
> >> A new version of Internet-Draft
> draft-xu-lsr-flooding-reduction-in-clos-01.txt
> >> has been successfully submitted by Xiaohu Xu and posted to the
> >> IETF repository.
> >>
> >> Name: draft-xu-lsr-flooding-reduction-in-clos
> >> Revision: 01
> >> Title:Flooding Reduction in CLOS Networks
> >> Date: 2023-11-22
> >> Group:Individual Submission
> >> Pages:6
> >> URL:
> https://www.ietf.org/archive/id/draft-xu-lsr-flooding-reduction-in-clos-01.txt
> >> Status:
> https://datatracker.ietf.org/doc/draft-xu-lsr-flooding-reduction-in-clos/
> >> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-xu-lsr-flooding-reduction-in-clos
> >> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-xu-lsr-flooding-reduction-in-clos-01
> >>
> >> Abstract:
> >>
> >>   In a CLOS topology, an OSPF (or ISIS) router may receive identical
> >>   copies of an LSA (or LSP) from multiple OSPF (or ISIS) neighbors.
> >>   Moreover, two OSPF (or ISIS) neighbors may exchange the same LSA (or
> >>   LSP) simultaneously.  This results in unnecessary flooding of link-
> >>   state information, which wastes the precious resources of OSPF (or
> >>   ISIS) routers.  Therefore, this document proposes extensions to OSPF
> >>   (or ISIS) to reduce this flooding within CLOS networks.  The
> >>   reduction of OSPF (or ISIS) flooding is highly beneficial for
> >>   improving the scalability of CLOS

Re: [Lsr] New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

2023-11-26 Thread Jeff Tantsura

I agree with all aforementioned comments.

Wrt AI/ML networking - if a controller is used, what is required is link state 
exposure northbound and not link state protocol  in the fabric. (I could argue 
for RIFT though ;-))
I’d urge you to take a look at Meta’s deployment  in their ML clusters 
(publicly available) - they use BGP as the routing protocol to exchange 
reachability (and build ECMP sets) and provide a backup if controller computed 
next hop goes away/before new one has been computed.
Open R is used northbound to expose the topology (in exactly same way - BGP-LS 
could be used).

To summarize: an LS protocol brings no additional value in scaled-out 
leaf-spine fabrics, without significant modifications -  it doesn’t work in 
irregular topologies such as DF, etc.
Existing proposals - there are shipping implementations and experience in 
operating it, have proven their relative value in suitable deployments.

Cheers,
Jeff

> On Nov 26, 2023, at 12:20, Acee Lindem  wrote:
> 
> Speaking as WG member:
> 
> I agree. The whole Data Center IGP flooding discussion went on years ago and 
> the simplistic enhancement proposed in the subject draft is neither relevant 
> or useful now.
> 
> Thanks,
> Acee
> 
>> On Nov 24, 2023, at 11:55 PM, Les Ginsberg (ginsberg) 
>>  wrote:
>> 
>> Xiaohu –
>> I also point out that there are at least two existing drafts which 
>> specifically address IS-IS flooding reduction in CLOS networks and do so in 
>> greater detail and with more robustness than what is in your draft:
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-distoptflood/
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-spine-leaf-ext/
>> I do not see a need for yet another draft specifically aimed at CLOS 
>> networks.
>> Note that work on draft-ietf-lsr-isis-spine-leaf-ext was suspended due to 
>> lack of interest in deploying an IGP solution in CLOS networks.
>> You are suggesting in draft-xu-lsr-fare that AI is going to change this. 
>> Well, maybe, but if so I think we should return to the solutions already 
>> available and prioritize work on them.
>>Les
>>  From: Lsr  On Behalf Of Tony Li
>> Sent: Thursday, November 23, 2023 8:39 AM
>> To: xuxiaohu_i...@hotmail.com
>> Cc: lsr@ietf.org
>> Subject: Re: [Lsr] New Version Notification for 
>> draft-xu-lsr-flooding-reduction-in-clos-01.txt
>> Hi,
>> What you’re proposing is already described in IS-IS Mesh Groups 
>> (https://www.rfc-editor.org/rfc/rfc2973.html) and improved upon in Dynamic 
>> Flooding 
>> (https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding).
>> Regards,
>> Tony
>> 
>> 
>> On Nov 23, 2023, at 8:29 AM, xuxiaohu_i...@hotmail.com wrote:
>> Hi all,
>> Any comments or suggestions are welcome.
>> Best regards,
>> Xiaohu
>> 发件人: internet-dra...@ietf.org 
>> 日期: 星期三, 2023年11月22日 11:37
>> 收件人: Xiaohu Xu 
>> 主题: New Version Notification for 
>> draft-xu-lsr-flooding-reduction-in-clos-01.txt
>> A new version of Internet-Draft 
>> draft-xu-lsr-flooding-reduction-in-clos-01.txt
>> has been successfully submitted by Xiaohu Xu and posted to the
>> IETF repository.
>> 
>> Name: draft-xu-lsr-flooding-reduction-in-clos
>> Revision: 01
>> Title:Flooding Reduction in CLOS Networks
>> Date: 2023-11-22
>> Group:Individual Submission
>> Pages:6
>> URL:  
>> https://www.ietf.org/archive/id/draft-xu-lsr-flooding-reduction-in-clos-01.txt
>> Status:   
>> https://datatracker.ietf.org/doc/draft-xu-lsr-flooding-reduction-in-clos/
>> HTMLized: 
>> https://datatracker.ietf.org/doc/html/draft-xu-lsr-flooding-reduction-in-clos
>> Diff: 
>> https://author-tools.ietf.org/iddiff?url2=draft-xu-lsr-flooding-reduction-in-clos-01
>> 
>> Abstract:
>> 
>>   In a CLOS topology, an OSPF (or ISIS) router may receive identical
>>   copies of an LSA (or LSP) from multiple OSPF (or ISIS) neighbors.
>>   Moreover, two OSPF (or ISIS) neighbors may exchange the same LSA (or
>>   LSP) simultaneously.  This results in unnecessary flooding of link-
>>   state information, which wastes the precious resources of OSPF (or
>>   ISIS) routers.  Therefore, this document proposes extensions to OSPF
>>   (or ISIS) to reduce this flooding within CLOS networks.  The
>>   reduction of OSPF (or ISIS) flooding is highly beneficial for
>>   improving the scalability of CLOS networks.
>> 
>> 
>> 
>> The IETF Secretariat
>> 
>> ___
>> 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] New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

2023-11-26 Thread Acee Lindem

Speaking as WG member: 

I agree. The whole Data Center IGP flooding discussion went on years ago and 
the simplistic enhancement proposed in the subject draft is neither relevant or 
useful now.

Thanks,
Acee

> On Nov 24, 2023, at 11:55 PM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> Xiaohu –
>  I also point out that there are at least two existing drafts which 
> specifically address IS-IS flooding reduction in CLOS networks and do so in 
> greater detail and with more robustness than what is in your draft:
>  https://datatracker.ietf.org/doc/draft-ietf-lsr-distoptflood/
>  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-spine-leaf-ext/
>  I do not see a need for yet another draft specifically aimed at CLOS 
> networks.
>  Note that work on draft-ietf-lsr-isis-spine-leaf-ext was suspended due to 
> lack of interest in deploying an IGP solution in CLOS networks.
> You are suggesting in draft-xu-lsr-fare that AI is going to change this. 
> Well, maybe, but if so I think we should return to the solutions already 
> available and prioritize work on them.
> Les
>   From: Lsr  On Behalf Of Tony Li
> Sent: Thursday, November 23, 2023 8:39 AM
> To: xuxiaohu_i...@hotmail.com
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for 
> draft-xu-lsr-flooding-reduction-in-clos-01.txt
>  Hi,
>  What you’re proposing is already described in IS-IS Mesh Groups 
> (https://www.rfc-editor.org/rfc/rfc2973.html) and improved upon in Dynamic 
> Flooding 
> (https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding).
>  Regards,
> Tony
>  
> 
> On Nov 23, 2023, at 8:29 AM, xuxiaohu_i...@hotmail.com wrote:
>  Hi all,
>  Any comments or suggestions are welcome.
>  Best regards,
> Xiaohu
>  发件人: internet-dra...@ietf.org 
> 日期: 星期三, 2023年11月22日 11:37
> 收件人: Xiaohu Xu 
> 主题: New Version Notification for 
> draft-xu-lsr-flooding-reduction-in-clos-01.txt
> A new version of Internet-Draft draft-xu-lsr-flooding-reduction-in-clos-01.txt
> has been successfully submitted by Xiaohu Xu and posted to the
> IETF repository.
> 
> Name: draft-xu-lsr-flooding-reduction-in-clos
> Revision: 01
> Title:Flooding Reduction in CLOS Networks
> Date: 2023-11-22
> Group:Individual Submission
> Pages:6
> URL:  
> https://www.ietf.org/archive/id/draft-xu-lsr-flooding-reduction-in-clos-01.txt
> Status:   
> https://datatracker.ietf.org/doc/draft-xu-lsr-flooding-reduction-in-clos/
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-xu-lsr-flooding-reduction-in-clos
> Diff: 
> https://author-tools.ietf.org/iddiff?url2=draft-xu-lsr-flooding-reduction-in-clos-01
> 
> Abstract:
> 
>In a CLOS topology, an OSPF (or ISIS) router may receive identical
>copies of an LSA (or LSP) from multiple OSPF (or ISIS) neighbors.
>Moreover, two OSPF (or ISIS) neighbors may exchange the same LSA (or
>LSP) simultaneously.  This results in unnecessary flooding of link-
>state information, which wastes the precious resources of OSPF (or
>ISIS) routers.  Therefore, this document proposes extensions to OSPF
>(or ISIS) to reduce this flooding within CLOS networks.  The
>reduction of OSPF (or ISIS) flooding is highly beneficial for
>improving the scalability of CLOS networks.
> 
> 
> 
> The IETF Secretariat
> 
> ___
> 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] 答复: New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

[Lsr] 答复: 答复: WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

Re: [Lsr] IETF 118 LSR Minutes

Re: [Lsr] IETF 118 LSR Minutes

Re: [Lsr] IETF 118 LSR Minutes

Re: [Lsr] New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

Re: [Lsr] New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

Re: [Lsr] New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

8 matches

Site Navigation

Mail list logo

Footer information