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

Robert Raszuk <robert@raszuk.net> Mon, 30 January 2023 16:53 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 A4B60C16951C for <idr@ietfa.amsl.com>; Mon, 30 Jan 2023 08:53:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 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_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=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 X9YWVvGWr1qj for <idr@ietfa.amsl.com>; Mon, 30 Jan 2023 08:53:07 -0800 (PST)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 9BC5EC151534 for <idr@ietf.org>; Mon, 30 Jan 2023 08:53:07 -0800 (PST)
Received: by mail-wr1-x42e.google.com with SMTP id m14so11250637wrg.13 for <idr@ietf.org>; Mon, 30 Jan 2023 08:53:07 -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=swOaM4CRj+FkkRvE9Q0cTxQeZ+WS4bBIQOOYx9Zq/wg=; b=CX+dYQs0lE12rT1TxqosNxgZlPnVmwXAW6dUPcePD0N9K+Az45lNsN12ZRPb6JYGEj RKiFpZM79lTEcMqg1qKQ83u4Ch3XeDzphR/+HEHaxdP2DmTeXMBOcF5RFYH9SLxnukft yurB4Yavos4NzZLg8uQo/tptKj3J4VLFY6tE7X+6BHb4UDO3UyAqCj6olSK8fsoRemDu 5AqUU+6iGwOCS/A0dtA+UL5w0koZYfxQ8fmL92w0wpfodxJhkrCfNlbN/lqAfm03aYea qMhgvpQOU75jyzFignrZ02ElZ7I2Bk0k5q5dz49DVCeIh6UJFFCEZBPW3CXytPjZXMxT zQfA==
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=swOaM4CRj+FkkRvE9Q0cTxQeZ+WS4bBIQOOYx9Zq/wg=; b=pSuy9tXnOi153xvU8FK7GIuOllJqPbywdat1uGZgVdXuCCKWkTaFOjs0s8eHsZ2eyt 8zJPeDDIEcG8V2Q9BPG9l/Mv/sy5hLUT4KTuBnww1bVw6dpdL65oGU4w1qsW0amrW2wj WFF8DKb67lRbnPaIf9AIcVX4kZ73+XS86n7wsvFFBm3IE1W0IqR7AfIcMC/hrZyhqZLp O3d5Vq36lZxXTm/eUPlfq+S04+ILF7lQQ1P0elbEtuAGEbHvP3XCmImiY7EYbnfgd1ra 8ho/yj9RHkzJ8USGiDv9UJcn1oV6ycTpvhtEDapeiH/dhpoX8gnyvXhyFeF3X3PgXQIu H3Xg==
X-Gm-Message-State: AFqh2krbEFUbHU+TNySG0TSdIeHnygmE5faq+h6lzTaGvaXeQ7tOx9DY KnByZ1shj4xuQAIDsjZhj0fxwfgPNJOuPxIOD7kadnLxnWdaFUVxtHs=
X-Google-Smtp-Source: AMrXdXvTOnFX7JmtrWzQEi1Te4WBSnw8+sOUQ78JICCFqef8BfVLvru2iNczSU2/O3TAGcpX05PsoVahCSZ1SZywDrM=
X-Received: by 2002:adf:aac8:0:b0:2be:691a:24ca with SMTP id i8-20020adfaac8000000b002be691a24camr1842878wrc.438.1675097585462; Mon, 30 Jan 2023 08:53:05 -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> <CAOj+MMGTW=7k0Q=hos6J_=bPFmuwSEUtvYt-e2H2FwteK1NjpQ@mail.gmail.com> <2691365d-b5b4-4348-b2b7-a1feae8177be@joelhalpern.com>
In-Reply-To: <2691365d-b5b4-4348-b2b7-a1feae8177be@joelhalpern.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 30 Jan 2023 17:52:54 +0100
Message-ID: <CAOj+MMFCiAsAsMzoJ8LCZ84qYOg-JQQ5xxhUsk4K5yc1AZJoWw@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="0000000000008bc02305f37e0c67"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/jCpyfeOa32X1Z4M-LjE3iOw_mcw>
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:53:11 -0000

Hi Joel,

> it may be scope bounded BGP

Mind refreshing my failing memory, what is "scope bounded BGP" ?

I am aware of at least three attempts to propose it - well two failed.
Third is still waiting for any wider deployment. Perhaps I missed something
new :)

And sure I am not saying injection of host routes is needed into underlay
.. I was just describing the case where any tenant would be willing to
enter CAN augmented public cloud resources from any ISP attachment port.

Thx,
R.

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

> 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
>>
>>
>>
>>
>
>
>