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

["[e-mail]" <[e-mail]>]

Hi Jeff,

Open/R (https://engineering.fb.com/2017/11/15/connectivity/open-r-open-routing-for-modern-networks/ ) is actually an in-house link-state routing protocol.

The following text is quoted from the above article.

"For many years, Facebook has been operating these large-scale fabrics solely with Border Gateway Protocol (BGP). While BGP brings its strengths, especially with respect to policy enforcement and scale, we saw opportunities to improve and simplify the design by having Open/R and BGP work together."

"Open/R provides APIs allowing remote agents to learn the link state or subscribe to database updates, such as notifications of a link capacity change. For example, this could be used to compute label-switched paths and program them on the network from a central location. “

In short, don’t lose confidence in using link-state routing protocol in data centers:)

Best regards,
Xiaohu


发件人: Jeff Tantsura <[e-mail]>
日期: 星期一, 2023年11月27日 05:49
收件人: Acee Lindem <[e-mail]>
抄送: Les Ginsberg (ginsberg) <ginsberg=[e-mail]>, Tony Li <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
主题: Re: [Lsr] New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

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 <[e-mail]> 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) <ginsberg=[e-mail]> 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 <[e-mail]> On Behalf Of Tony Li
>> Sent: Thursday, November 23, 2023 8:39 AM
>> To: [e-mail]
>> Cc: [e-mail]
>> 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, [e-mail] wrote:
>> Hi all,
>> Any comments or suggestions are welcome.
>> Best regards,
>> Xiaohu
>> 发件人: [e-mail] <[e-mail]>
>> 日期: 星期三, 2023年11月22日 11:37
>> 收件人: Xiaohu Xu <[e-mail]>
>> 主题: 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lsr
>> _______________________________________________
>> Lsr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lsr
>
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr