Re: [Idr] [Can] Proposed CAN WG charter for discussion

Robert Raszuk <robert@raszuk.net> Mon, 30 January 2023 08:41 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF34EC1524DD for <idr@ietfa.amsl.com>; Mon, 30 Jan 2023 00:41:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 4v_Do1nRrij4 for <idr@ietfa.amsl.com>; Mon, 30 Jan 2023 00:41:11 -0800 (PST)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 BE051C1524AC for <idr@ietf.org>; Mon, 30 Jan 2023 00:41:11 -0800 (PST)
Received: by mail-wr1-x431.google.com with SMTP id h12so10252305wrv.10 for <idr@ietf.org>; Mon, 30 Jan 2023 00:41:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KspWd0HAbaDhAZ57zn67J8SCcleP/6o4jX6LkYsYZHg=; b=C2p3LJMd4qOfDE4I2oqDOmXaW4t/ZVSxqg278Bt/jqQrrIDViwGL7TvBPO3losufpr ddknlu/Xp1y7fEmzTO90eXzYpsdPhL6VxYTQiJ1FTK6rk2ErbZ2C8q+6CcsRQ23pYS6A zMjX/1whWIW4vC9Mq4tn1NCU57rULvoRwJCPmLzUDY/I5lq2+gLy5bd0VsH/iX9tV4x9 eDU1a3W38FW1MqLBjN72biwnSS4I2QdPzUCIGNg9NxpVLzekrY4B5TjjzbntGbgKFNgh rFYLzdTBpGHL+8lDDnWEqT9mIe5y17Epe3oZK7sapyXv+FrmN2tVQitkDe/OF+2mkYgk NpSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KspWd0HAbaDhAZ57zn67J8SCcleP/6o4jX6LkYsYZHg=; b=Ay5uupT/IcETua7ipA65+Nl8r7tF6GwGxlsonHpZdI4SFg0i92w+cjSxlp9TTK+7RP 9YKfBqiQrl7Sy7iACSAlKQ8Rp5RH29Cmsvf7tINUMKa86SJSORNSyx15pqQz9noKPPCO oC87v/nXXlyeDm8If9aN8k5QFzk8telFMCquGmL3h9K27nF8mGMD1foAxFXrhT4uI/nn zDWdhONj+GohCqr281N0jVVHoACQFISIdnH/jjlbkKnqbbBtxE8u2fte4/oWov+vbvQc qF68URkAieBUoNIcyo8VUkK04YYG6XOkxMou06xglQn3WvUaaK0mnaUHa7FIoMXMpLRS AZGw==
X-Gm-Message-State: AO0yUKXrgKYJos4TKPNnfYdeMjW862znMNES7T1i3TgvuLR3gRgxwJxO ykubucm/FKoxJpQDri8y9HEqci1LKYI7vkjevs0G+ew1oWIh0g==
X-Google-Smtp-Source: AK7set/0ljHWgCzXJJVVhN9hCuPVvs0C0SnMLrXR6rUn4oXgcwVECQ7oQS3C9u7qr1UIIPLXXcWLag8AI+RPak/mAd8=
X-Received: by 2002:a5d:45cc:0:b0:2bf:ee08:5bff with SMTP id b12-20020a5d45cc000000b002bfee085bffmr118606wrs.378.1675068069931; Mon, 30 Jan 2023 00:41:09 -0800 (PST)
MIME-Version: 1.0
References: <957acbb4-7590-1c07-d0bd-c0970e21bbec@joelhalpern.com> <29e540a2652de0cf2773fffcb38edf59fc548f6e.51de7303.2fed.42db.8869.d322b43457a7@feishu.cn> <CAOj+MME_zjJ903jHrbBLUWU3J+aRZd5HLAsieQmKshz2NrHb-A@mail.gmail.com> <CO1PR13MB4920051D9B209F3C0952731085D29@CO1PR13MB4920.namprd13.prod.outlook.com> <d11874d2-0fdc-c4cf-da3a-d15d333f7dbb@joelhalpern.com>
In-Reply-To: <d11874d2-0fdc-c4cf-da3a-d15d333f7dbb@joelhalpern.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 30 Jan 2023 09:40:58 +0100
Message-ID: <CAOj+MMGTW=7k0Q=hos6J_=bPFmuwSEUtvYt-e2H2FwteK1NjpQ@mail.gmail.com>
To: Joel Halpern <jmh@joelhalpern.com>
Cc: Linda Dunbar <linda.dunbar@futurewei.com>, can <can@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000048883405f3772d28"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/JCL_3gu6RS9-6_wwa6GHoyiprIQ>
Subject: Re: [Idr] [Can] Proposed CAN WG charter for discussion
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jan 2023 08:41:15 -0000

Hi Joel,

I am not sure what is not obvious here for you (and Dirk) ?

I think we all agree that the principle of operation of network centric CAN
is based on anycast address per given compute service.

Functionally you need /32 or /128.

But the Internet rightfully is not going to carry anything more specific
then /24 or /48 (maybe /64) respectively.

So now to realize 10 services you must waste 10 min routable blocks.

This also goes against hyperscalers injecting just /16 or /18 into the
global Internet.

So my comment in respect to applicability was not as much about dynamic
load to the control plane introduced as it was just an observation on what
subject solution requires vs current Internet operational rules.

To summarize I do not think that bending or breaking those rules would be
subject to analysis of this WG.

Kind regards,
R.



On Mon, Jan 30, 2023 at 12:45 AM Joel Halpern <jmh@joelhalpern.com> wrote:

> My inclination would be to leave the analysis of the public cloud
> applicability to the working group.  Whether it is or is not applicable is
> not obvious.
>
> Yours,
>
> Joel
> On 1/29/2023 6:40 PM, Linda Dunbar wrote:
>
> Robert,
>
>
>
> You said:
>
> *“Also note that while you could perhaps make option 1 work in your (say
> 5G) network for your service it does not sound like it would be applicable
> to access public clouds compute cluster based on the actual load in the
> same way over  the Internet.” *
>
>
>
> I think that is a very good point. Making CAN applicable to access public
> clouds might not be wise. Maybe we should add this point to the CAN scope?
>
>
>
> My two cents,
>
> Linda
>
>
>
>