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

Jeff Tantsura <jefftant.ietf@gmail.com> Sun, 26 November 2023 21:49 UTC

Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D2FC151069 for <lsr@ietfa.amsl.com>; Sun, 26 Nov 2023 13:49:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.105
X-Spam-Level:
X-Spam-Status: No, score=-6.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhbSPT1CMYvT for <lsr@ietfa.amsl.com>; Sun, 26 Nov 2023 13:49:29 -0800 (PST)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBC61C14CE29 for <lsr@ietf.org>; Sun, 26 Nov 2023 13:49:29 -0800 (PST)
Received: by mail-pf1-x42f.google.com with SMTP id d2e1a72fcca58-6b709048f32so2953392b3a.0 for <lsr@ietf.org>; Sun, 26 Nov 2023 13:49:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701035369; x=1701640169; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=mqu3iKw3fAHACRllqcYQu5gphkWgC7Ro/SnUGVmFetY=; b=MVNDYBCYwsOrMJ5MggbaPbSyMrig3EtOclg3fcSfG762/vf1Rrec9KMM+LA47QlFT7 Wvi8wdUletM69ogaN8G7TwkmH9n/W5qotiFe1xBxYYb8j2nTro4PBjo1vGbkow0x/sEa eIj+i+RN8hlRP/nrApKlf8SmZ0hHCPipKdI2MfZz62dYKS9bfuev5oRqz8NS7H7YwJXZ Y0Hk+kd2Vjn71K88YJYkW0wxTBPYgyMRHSLhRFtyR06fUDONdV3onYjHKYtqpgTQVn5F Lwk3M6dLVkERR9ljVF88TGLd0RoCEPTPd7VTsF4FhbHu0+F4BgJwCf65ftLXV4bT7vDq 8c7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701035369; x=1701640169; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mqu3iKw3fAHACRllqcYQu5gphkWgC7Ro/SnUGVmFetY=; b=RRuO+E9oNVhwOfxfOAMm7KM8R7nVDYVfOy8eVTmATiNMoyp4kHyKTedalSq/huRk2S yU8H203y9IOquU4GCkTDTKjMLPA2iUFF7a4CBzvS81qMmdgQ1AJdk/tutPRugfNAXD/+ 8OT3uLvCjwAiSDv1gNWtU1srZpQ4HCd705dAncWB4nKDRoTrABghUgEU47Dg0hUq+aOz BaYEfi7REep49E3yPoIl9t3F1oq+IxCTNB7W9t68JEcrsRMkjjwajN0dP/ITmI0Cb7lL aWKtcVF4tNza1tl62ffez89O6cOswr3YpRzjZG2oK6qsGK8uTfGhsOf/k/8Gmbv2h7oI +BQA==
X-Gm-Message-State: AOJu0YxUEJ26l5H3eVOydB1tOXbHL+hFSCgniCUXiMllBOpjtnrCIzcY L4Uyec4XqsPnlHkht+YWSck=
X-Google-Smtp-Source: AGHT+IElR7NzhhBhQNK9/YdeJlL0yip/iCu+hZ0yJd//3I/bZRCUqT2CaMXj3ISWXDXCtT+YXF3BTQ==
X-Received: by 2002:a05:6a21:6d8a:b0:18b:6192:f91a with SMTP id wl10-20020a056a216d8a00b0018b6192f91amr11248237pzb.9.1701035369170; Sun, 26 Nov 2023 13:49:29 -0800 (PST)
Received: from smtpclient.apple (c-67-164-29-73.hsd1.ca.comcast.net. [67.164.29.73]) by smtp.gmail.com with ESMTPSA id 16-20020a056a00071000b0068ffd4eb66dsm5962522pfl.35.2023.11.26.13.49.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Nov 2023 13:49:28 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Jeff Tantsura <jefftant.ietf@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 26 Nov 2023 13:49:17 -0800
Message-Id: <540AD227-3829-4C7C-8B2A-60E9F052027F@gmail.com>
References: <F93C6433-76C1-419A-9E8D-7054F9EF160A@gmail.com>
Cc: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, Tony Li <tony.li@tony.li>, xuxiaohu_ietf@hotmail.com, lsr@ietf.org
In-Reply-To: <F93C6433-76C1-419A-9E8D-7054F9EF160A@gmail.com>
To: Acee Lindem <acee.ietf@gmail.com>
X-Mailer: iPhone Mail (21B91)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/OQRapSGujHjTlGxOFDTzdDfdvZI>
Subject: Re: [Lsr] New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Nov 2023 21:49:33 -0000

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 <acee.ietf@gmail.com> 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=40cisco.com@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 <lsr-bounces@ietf.org> On Behalf Of Tony Li
>> Sent: Thursday, November 23, 2023 8:39 AM
>> To: xuxiaohu_ietf@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_ietf@hotmail.com wrote:
>> Hi all,
>> Any comments or suggestions are welcome.
>> Best regards,
>> Xiaohu
>> 发件人: internet-drafts@ietf.org <internet-drafts@ietf.org>
>> 日期: 星期三, 2023年11月22日 11:37
>> 收件人: Xiaohu Xu <xuxiaohu_ietf@hotmail.com>
>> 主题: 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