Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

Robert Raszuk <robert@raszuk.net> Tue, 14 June 2022 23:20 UTC

Return-Path: <robert@raszuk.net>
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 B155AC15AAE5 for <lsr@ietfa.amsl.com>; Tue, 14 Jun 2022 16:20:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 5-41D9HVPJw9 for <lsr@ietfa.amsl.com>; Tue, 14 Jun 2022 16:20:41 -0700 (PDT)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 D0C79C15AACF for <lsr@ietf.org>; Tue, 14 Jun 2022 16:20:41 -0700 (PDT)
Received: by mail-ej1-x629.google.com with SMTP id m20so19922399ejj.10 for <lsr@ietf.org>; Tue, 14 Jun 2022 16:20:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VwLyZpsO8e/m3sUrGGogaPrPY9MGRZRMnpFtbI1yqEg=; b=HjiRb8gTlz+wpNv3wxLY4zOevofuuEKC0qyFi1V2FfxYO+/902zrYDFWuUGmNcKjor 8jZoHf7Uj/+q/Gb9URHl6k9CC2DeEQyeU6Td0ueWcGkoFxLvNY+5Iz8IUq5hFXnPS8d3 Rg8sNAwgM7KFzZBVb5FzYCUARPXB9ucA/nj7CwTTisnM8Xjc7Q+oj/+O/WPWxRT6pDz3 CE0PjQtWxorQmGo/n1lHjZhb467Ch0XaYqLS7EnE7bZbst5okz+WqkXlycz5qCOQkUbB ytL48qAdur4Q9oEbMEOmoD6vXMjt3nTftC9bAJJbphcewoxlUeBrVG+ideqL6Orwpprt J6LQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VwLyZpsO8e/m3sUrGGogaPrPY9MGRZRMnpFtbI1yqEg=; b=h0KYQuTv3qOlDBCEeDZ9N2Je8mi926hsbv68t0aO3BGh22Bscdn5UnAmsw9ajI/J4W yrylbddZHR/ZLpF31gYJ/6SK3sxfyBhrwbzpyledvjp78BJR5rJVDeaopWf4xiWwa/nf roHaDdZVcvZHIXe54nDTKo3ztS6/WzqQnk5JJUHOuhQx+JrBANpOW3oi56W9YnIq+Q8W kPRk098F6cnF0xKafhDzKFT/h3gKN0MHO4Sz+sEEJSB4WdTw4F+hxAh8WYlEjXU76gX2 xiNMzqR2OzaP6I+hQ68vopTWdiFJ24EZGUl3TJDP0NQY3Ud5+PC+xPDrAZM07x8ATWQu QAwg==
X-Gm-Message-State: AOAM530IQryMmJjboErQ10g6Lsqgqqd1YjvfZU3nANKe9y8lYmQr4MsA EhUak9sP35zD61roTyZN7W7gGuNJ9S2KqWSVgjuWTA==
X-Google-Smtp-Source: ABdhPJywk+OLXFIgL9wX2FEgKd3hYkTcA1L7BxA3GH8t96GdD5TakGx1c1ud+qoLsfhm5bwMinjJd0ydgfi8ZeGUl98=
X-Received: by 2002:a17:906:74cb:b0:712:2210:c951 with SMTP id z11-20020a17090674cb00b007122210c951mr6216718ejl.166.1655248839637; Tue, 14 Jun 2022 16:20:39 -0700 (PDT)
MIME-Version: 1.0
References: <AC1AF8B2-07D5-46CB-85B9-DC8607C5E88B@cisco.com> <AM7PR07MB6248CDBA763EF1A0BAF626ADA0AB9@AM7PR07MB6248.eurprd07.prod.outlook.com> <8C14FCF1-C477-4D9C-A7C2-2260F2B7B7A5@tony.li> <BY5PR11MB43377349791AE499BE49682DC1AB9@BY5PR11MB4337.namprd11.prod.outlook.com> <3E5027F4-5A78-4AC0-BB24-5A0E13D2F979@tony.li> <BY5PR11MB433717C52D1A960ED987EFA6C1AB9@BY5PR11MB4337.namprd11.prod.outlook.com> <0076DD08-6CCB-40F7-82F9-6A42257C0A50@juniper.net> <BY5PR11MB4337E1D6A9487B37DC600DE0C1AA9@BY5PR11MB4337.namprd11.prod.outlook.com> <BY3PR05MB8081E3E92BBD7AA4C28B433EC7AA9@BY3PR05MB8081.namprd05.prod.outlook.com> <BY5PR11MB4337AFA5277F57D824740835C1AA9@BY5PR11MB4337.namprd11.prod.outlook.com> <BY3PR05MB8081900E45C9E1CBFFD9C5B4C7AA9@BY3PR05MB8081.namprd05.prod.outlook.com> <CABNhwV2=-nqguuvgcrooeyBwkyPhNbAsqyE2J4+0PvYOEvXjWA@mail.gmail.com> <4AD1A78E-0EB9-401C-9A6F-91245C5B8B44@tony.li> <CAOj+MMEdZOhrWGmXkxxBQ3rgPaULbLLJn=FABHqZ0F-xQMXJtg@mail.gmail.com> <4E3FBCE0-277A-4CA7-872D-834916610D0A@tony.li>
In-Reply-To: <4E3FBCE0-277A-4CA7-872D-834916610D0A@tony.li>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 15 Jun 2022 01:20:34 +0200
Message-ID: <CAOj+MMGEDNCiDWF-o8DP8SQab0n09ZwbC3P4+NvtpsrQ8Vakcg@mail.gmail.com>
To: Tony Li <tony.li@tony.li>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>, John Scudder <jgs@juniper.net>, "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>, tom petch <ietfc@btconnect.com>
Content-Type: multipart/alternative; boundary="0000000000001a31ec05e170a7f5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/E_Z-uo8kZyQ-RD7OxvrLxrNCz8I>
Subject: Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding
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: Tue, 14 Jun 2022 23:20:45 -0000

> Well, we can blame marketing all we want.  All I know is that we, as a
> group, failed to come together and present a unified front with
> interoperable implementations. That left us in a position where marketing
> is pushing rocks up hills and customers are waiting for the dust to settle.


I am not blaming marketing here. Real engineers never listen to marketing.

The main issue why BGP won in some MSDCs was that it was much easier (and
cheaper) to deploy on OEM white boxes then any alternative scalable IGP
(read use open source).

So yes - link state IGPs were late for MSDCs. Petr's draft then RFC was
like a hammer to this as well. But many use BGP as an underlay without
fully realizing the pros and cons. Some run BGP purely from positioning
perspective as they can be seen "weaker" as the largest hyperscalers. Many
still run BGP services with no hierarchy and clean decoupling.

IMHO even for many DCs this is still not the lost battle if positioned IGPs
right. So let's progress this as Experimental and clearly explain the
benefits if given implementation supports this.

Regards,
R.