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

"duzongpeng@foxmail.com" <duzongpeng@foxmail.com> Mon, 30 January 2023 09:04 UTC

Return-Path: <duzongpeng@foxmail.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 ABBE4C14CF0C; Mon, 30 Jan 2023 01:04:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.848
X-Spam-Level:
X-Spam-Status: No, score=0.848 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, HELO_DYNAMIC_IPADDR=1.951, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=foxmail.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 AlwFjnl_Ijr0; Mon, 30 Jan 2023 01:04:27 -0800 (PST)
Received: from out162-62-57-64.mail.qq.com (out162-62-57-64.mail.qq.com [162.62.57.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763D1C14F72F; Mon, 30 Jan 2023 01:04:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1675069462; bh=GNeRt9XgWCw5gc5JAgIOrE/fmyQh5k+YpOFwLxJm6XY=; h=Date:From:To:Cc:Subject:References; b=q1f0nRY8HCNKYztsoaEauBprwVmyMG0wU8mjgmvNiTU9sqNVWGX/IXWv0LuMFUVaV LioVI5ktFQHnq3Gjcq2yfei4O+mR16unrcRjt9YlsveUl586KySd3usz46DEYrPYBn sxZSzWeDdkDVlefG3Fjwre7DX1f8dGGF766bN/3E=
Received: from cmcc-PC ([103.35.105.45]) by newxmesmtplogicsvrszb9-0.qq.com (NewEsmtp) with SMTP id 11392E52; Mon, 30 Jan 2023 17:04:19 +0800
X-QQ-mid: xmsmtpt1675069459tr4hn52ni
Message-ID: <tencent_B4CAE9A1E47D8ED9B5F8D6DB88D5A4A33009@qq.com>
X-QQ-XMAILINFO: OKkKo7I1HxIeez3nUJxzE3QBhvICbhTtSPTlrEaYLPiM3lYBkBNbe5MsLu/jaQ lSWeCWJe6beRU1kKPmTN7kMTVY2OhcfRGQLPMoL83LLSUa/NCisTxK70X0ewvLKf9wx7A8pCBaYP hIZDJlSQxwPUow5XAGf85MOQJI6awFN6ih6cN4z+MXN3FYhUQCjXmzDdRmrOSXMtLvCs4VmmPQrP +FpR7Om3o7JMc5kJd9Otn0Su7OF6qcPi1d3Uivy7xzSnYKdDAHCbczz/DQWZEM5+cq3KuKhxyL9G pwXTcd6zw0j4CB1j1SL+6k1hliX9yeOScy/JdjADVqJdSUy1lAWXWtfV51pz/QVG2/bPEePa2VsS +raMzE4NH4tE8qHa/HS5IbWeMi9Ex4fVKtUvAu9svUARIy6kPjfqZmWO6gTRCjw0Wr2cbM+tO6ua I1KuEKjH11auKpWm+5BQHXAdZcvffpMHgdmPBwxJPq90iK4wZbLP+tZWEnTQlVWO+mLvg8BCvxCA f4HT/irGa6PPsMUxf2fyO4N6eqNLtXP5a8fswtsIMnX+foZCh8P2J8D+OmnMbeweKKscD615/Vjr LMILKvR5wiz/izypYDGzkqtLEmO3v4ZxJGW1A2Eh9kbgtolI8BE2SAqAU8yb12nHdd+VH0njISXO e/Ad876mLrvaGdJTiRTl/kUdAtjECIekEms/XSXzdrsMX9+dKmX7ehI0Dw1FUODlr7FL/RZp/mdz FSa8fPD39oYdvqlsLnn4eG/8zUxV8YriINYRVC4p9ND92Jx45hMhB+0tKBmsEOddjJ4eGTovlmAf BRa4ulvf1JUaBV3SGQ/F7uj3tLfi1U94lZm8WXYCEo6ZUfrnctjmoZZCPpROxrvoCUqonWkIhEZw i+8cSTMxJ19OTuqhCrndsZky/JK5HupvNpKHPf/PF32TuUJzzmzdG54ftVBKO7g5D4KH/qrjNVvq u+xSgxE7X9bwjUlmaUoCXYA5ltruesKNAcdMZqSYW+v34HIvx85yJy5ZX0GXHW059tkWxYoogFC3 78Ehe4UhsXNKjDN+/CYiEQ1nJ5aKMjlJHie+sBZg==
Date: Mon, 30 Jan 2023 17:04:20 +0800
From: "duzongpeng@foxmail.com" <duzongpeng@foxmail.com>
To: Robert Raszuk <robert@raszuk.net>, "'Joel M. Halpern'" <jmh@joelhalpern.com>
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>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.25.178[cn]
Mime-Version: 1.0
X-OQ-MSGID: <2023013017042007053614@foxmail.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart780241385672_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/DyOU06LMDiK1xpsX-mCf5KQwA5I>
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 09:04:31 -0000

Hi Robert,

    I agree with the problem about : "So now to realize 10 services you must waste 10 min routable blocks. "

    However, I do not think it is unacceptable. Perhaps we will not have too many kinds of services for CAN in the initial phase. I mean that not every service needs CAN.

     In addition, the routing information needs not be spread into the whole global Internet because it is unnecessary. I do not think a service point far away will not be potentially optimal. Perhaps we can control the spread scope of the information by some means.

Best Regards
Zongpeng Du



duzongpeng@foxmail.com & duzongpeng@chinamobile.com
 
From: Robert Raszuk
Date: 2023-01-30 16:40
To: Joel Halpern
CC: Linda Dunbar; can; idr@ietf.org
Subject: Re: [Idr] [Can] Proposed CAN WG charter for discussion
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