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

Joel Halpern <jmh@joelhalpern.com> Mon, 30 January 2023 16:45 UTC

Return-Path: <jmh@joelhalpern.com>
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 BE66FC16953D; Mon, 30 Jan 2023 08:45:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, 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 (1024-bit key) header.d=joelhalpern.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 RH_Wmq5_Y0Ee; Mon, 30 Jan 2023 08:45:17 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D866FC1782C9; Mon, 30 Jan 2023 08:45:17 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4P5DZ556t8z6G9w6; Mon, 30 Jan 2023 08:45:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1675097117; bh=2AW7f+8X9HcW5DM2SMHyc+pU1al98fskuUUWZmlsd84=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Jaqt1jc1LHAhuQ/Cu6h57rVBcH4vEEtnig6usddNvP6bri7TN3MbLvEJgtExkeBhB aBdhqvjHQhO0RIkheuKtF9joP31j7sQG19HuZ0LxVWu/EE9jjx2VyaoYjTnfFDbmsj Sp6vbfClR80am5nQq7MuQTYBO48zWLCtY0OYr0X0=
X-Quarantine-ID: <3Mky3aXDmYDz>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.21.74] (unknown [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4P5DZ42YrPz6G9K4; Mon, 30 Jan 2023 08:45:16 -0800 (PST)
Content-Type: multipart/alternative; boundary="------------SbXpPZj1GElTsn5MNvyFp0wm"
Message-ID: <2691365d-b5b4-4348-b2b7-a1feae8177be@joelhalpern.com>
Date: Mon, 30 Jan 2023 11:45:15 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1
Content-Language: en-US
To: Robert Raszuk <robert@raszuk.net>
Cc: Linda Dunbar <linda.dunbar@futurewei.com>, can <can@ietf.org>, "idr@ietf.org" <idr@ietf.org>
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> <CAOj+MMGTW=7k0Q=hos6J_=bPFmuwSEUtvYt-e2H2FwteK1NjpQ@mail.gmail.com>
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <CAOj+MMGTW=7k0Q=hos6J_=bPFmuwSEUtvYt-e2H2FwteK1NjpQ@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Q4BU1bUAhcrmzFhxmPs_Ckeq9ug>
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 16:45:21 -0000

It is not obvious that you need to inject the anycast address for the 
network service steering into the underlay routing.  You may. And for 
some deployments that would be IGP, and others it may be scope bounded 
BGP.  But I can also envision solutions (which is not what we are 
discussing) which do not require such injection. So it is not obvious 
that we need the restriction.

Yours,

Joel

On 1/30/2023 3:40 AM, Robert Raszuk wrote:
> 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
>>
>
>
>