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

"duzongpeng@foxmail.com" <duzongpeng@foxmail.com> Sat, 28 January 2023 09:02 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 51CCCC169510; Sat, 28 Jan 2023 01:02:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.949
X-Spam-Level:
X-Spam-Status: No, score=0.949 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, HTTPS_HTTP_MISMATCH=0.1, 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_BLOCKED=0.001, 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 99hfvsWsiOR1; Sat, 28 Jan 2023 01:02:33 -0800 (PST)
Received: from out162-62-57-210.mail.qq.com (out162-62-57-210.mail.qq.com [162.62.57.210]) (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 66327C169508; Sat, 28 Jan 2023 01:02:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1674896548; bh=mpbSvedvyEagv01yO/YevxgQ+DdPBhDrjX7UTJODDTk=; h=Date:From:To:Cc:Subject:References; b=bkE+O8q/iX1+giwSUZauuFe6DaQmebXNR4IiAOHL94s1SRVrS3ncDEAO6cuWUOMZt 7Dg6mUIn8CvjmZ+Zg8IZQQyJvyUWGhGQmtsAbGb1wTDPhwCFM1BQGFXlfEzPEaxBQ1 XlSfDu+KeAo97vO7VpH9co6MpWEWVAMuHmBso/+g=
Received: from cmcc-PC ([103.35.105.45]) by newxmesmtplogicsvrsza12-0.qq.com (NewEsmtp) with SMTP id 9A2DECD; Sat, 28 Jan 2023 17:02:26 +0800
X-QQ-mid: xmsmtpt1674896546tcrv2k9h9
Message-ID: <tencent_EC215F419B875A7C545EB90A14BF4F3ABB06@qq.com>
X-QQ-XMAILINFO: Nt+cTZuZCMyiD8A/OHQNgWVVc5Mw/ZeMWNrH9yu1hXqqXBgOBMFv7Tz9bvviCX 0nGZh8M3BDiYievgiEnoYynmIwKGi+Kx3wXKyTLJYHr6c+NVa1umJxA4gKRhgF0VoAQl1S9FGAd2 aQboS/H++h+Hhv/lAx+wrjoSHi7DTAmaDnljV3CWC00vet4SRUBIUDQvCUHYWQkUvrEwmhMNpRz+ 7inLhRBHgmQ9oZR4oopp+W2i94Ef5+XD3bujZBwn1fv/xlc9zWnbFr2jlZ/RnLecepOGerArDY0T XS0rNpZW6xozvzJLk66CeIfBpo9P54u8TESYoP6wmXd82EK1P4+DFTeRjM9gdGLk37J0E+KelBoh Q7e2jO1PdLRrHj8SnWf/ZAr43aLS7YLGY2tCeRnx2ZqHGC2sfbBGkrEZdiWGCQE44cGhsE8R7eIN CpN1to7Xql5j5+7UeK4Msbnrimj59VVllIqZTnYkcTTAh1SfXL85j85p2bd3C7IKVBT5zCXUgkSw zOYovnbqE3zEG/NLCP8TUaO/t8QEdmi/rWIEd5nklhkG82DqDaAl2IRbWFr2iRCujgm8cr15tl75 4LMvz3Ly6Mi+nowY4BVSgBP0731SWlDNisc9zy0gN+NOyoKvnqze60P6B4Q4JL+JSXyVC38QQF6q RzukGiq6vLFQDiVJSFU4zJUHJLoMo8KVcXSm7qygA7fzMvuUwDzcu/I75MtafUxLW9uD0cWufCNd URbvNwhmUtNmdo0rtFRDKSORdKtyCbUTYMheHylCv4SB55xX253C5kOnVHhCvTUYwNWnxuIPWxWo uopucb/8ZBlRpcs+L6H2gcIulUm696u2q5ZmeeIsiI8MlzNkduDSk2e/t4KbHa4sES4/71DW+euW 7Hzq0ClV1QfbMaPhRMEw4X5J1LW8lZvqS6biuLAvHvx4U8roj6VCPOYlpiCCOs88xuBrSdYWLefn xIBnA2MX3P2QLLCcAycSNqZM/uBMQXx7RuldJSCMSG/Ol2823OqA==
Date: Sat, 28 Jan 2023 17:02:26 +0800
From: "duzongpeng@foxmail.com" <duzongpeng@foxmail.com>
To: Robert Raszuk <robert@raszuk.net>, Linda Dunbar <linda.dunbar@futurewei.com>
Cc: John Scudder <jgs@juniper.net>, can <can@ietf.org>, "idr@ietf. org" <idr@ietf.org>, "farinacci@gmail.com" <farinacci@gmail.com>
References: <53B67919-AD61-489D-8115-EBCB5CCE1976@juniper.net>, <CO1PR13MB49207D831961BE1891CEEEF985CE9@CO1PR13MB4920.namprd13.prod.outlook.com>, <70C0E859-8EDE-441E-A1F2-7FFA68B9B6D8@juniper.net>, <CO1PR13MB4920B520CB00D82B0576F8E385CC9@CO1PR13MB4920.namprd13.prod.outlook.com>, <CAOj+MMGdWbvm9t0GOpdWqmS5h4OMdmnX5_2kbU4ukkU6BXTnZQ@mail.gmail.com>, <CO1PR13MB49205F1D5CE4D2EF99BAEFE985CC9@CO1PR13MB4920.namprd13.prod.outlook.com>, <CAOj+MMFNeq=rs8rmoBLCYVQgpMv4W5m7CCneCH5QFa+X=41egQ@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: <202301281613116529661@foxmail.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart182604103564_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/kBR1KveBl33pGuSqreI6tBIiyg4>
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: Sat, 28 Jan 2023 09:02:37 -0000

Hi Robert

    IMO, multiple solutions exist here, perhaps for different scenarios. Maybe we can make the charter more general to cover all the potential cases, and then explore further about the detailed approaches.

Best Regards
Zongpeng Du



duzongpeng@foxmail.com & duzongpeng@chinamobile.com
 
From: Robert Raszuk
Date: 2023-01-28 06:41
To: Linda Dunbar
CC: John Scudder; can@ietf.org; idr@ietf.org; farinacci@gmail.com
Subject: Re: [Can] [Idr] Proposed CAN WG charter for discussion
Hi Linda,

I believe that you can get much wider and faster traction with the idea if you keep routers outside of it. 

I know LISP roots started at the assumption that xTRs should be placed in routers vs ILNP idea (or family of ideas) to make it in the host - however today I think that even for LISP xTR can be natively implemented in the compute nodes itself. 

I am not pointing at any specific solution here - just trying to better understand where in IETF such WG (if/when formed) should reside. Routing Area does not sound to me like a best/good fit for it. Hence the note. 

Cheers,
R.



On Fri, Jan 27, 2023 at 11:29 PM Linda Dunbar <linda.dunbar@futurewei.com> wrote:
Robert, 
 
I believe the CAN proponents only want to distribute the information on Overlay, not involving the network elements in the underlay, as stated in the current CAN charter:
 
The assumed model for the CAN WG is an overlay network, where an ingress routing node makes a forwarding decision based on the metrics of interest, and then steers the traffic to an egress node that serves the selected service instance, for example using a tunnel. Architectures that require the underlay network to be service-aware are out of scope.
 
As for OTT, does it imply egress routers distribute the information to the external system which in turn distribute the information to the relevant ingress routers?
 
Dino did suggest LISP as one way to distribute the information between egress routers and Ingress routers. Maybe the draft you mentioned can be considered as the starting point for applicability study of using LISP?
 
 
Linda
 
From: Robert Raszuk <robert@raszuk.net> 
Sent: Friday, January 27, 2023 3:35 PM
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: John Scudder <jgs@juniper.net>; can@ietf.org; idr@ietf.org; farinacci@gmail.com
Subject: Re: [Idr] Proposed CAN WG charter for discussion
 
Hi Linda,
 
But why do we need to do that within the underlay network vs Over The Top (OTT) way ? 
 
Why network needs to be at all involved in distribution of the load information if we could solve it at the application level and keep network lean and as much stateless as possible ? Simple mapping plane will work just fine for this resulting in OTT Compute Aware Load Balancer (for the lack of the better name). 
 
Why bring this "awareness" to BGP or IGP or even routers in general ? 
 
Isn't the draft https://www.ietf.org/id/draft-kjsun-lisp-dyncast-03.html a possible solution ? 
 
Many thx,
R.
 
 
On Fri, Jan 27, 2023 at 9:43 PM Linda Dunbar <linda.dunbar@futurewei.com> wrote:
John, 

Oh, I guess I have over-thought of the "Architecture & framework". 
The proponents' wanting a mechanism for egress routers to distribute computing resources to ingress routers can be considered as one rough architecture. 

Thank you. 

Linda

-----Original Message-----
From: John Scudder <jgs@juniper.net> 
Sent: Friday, January 27, 2023 12:06 PM
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: can@ietf.org; idr@ietf.org; farinacci@gmail.com
Subject: Re: Proposed CAN WG charter for discussion

Hi Linda,

I didn't mean to say that the architecture would have to be completed to the point of RFC publication before that step could be started! But of course, anyone studying the applicability of a mechanism, has to be thinking, "applicable for what purpose"? So I think that studying applicability presupposes that the person doing the study has an architecture in mind. 

Your summary seems about right, and I think it demonstrates that those in the side discussion *do* have at least a rough architecture in mind. My point is,

a. It's important to write that rough architecture down, to make the assumptions transparent to all WG participants, and b. It's important that when listing work items, we do not lose sight of the fact that this is one work item.

I don't see the bullet list as comprising a strictly ordered list of tasks that have to be completed in the order listed, I'm sure some will be worked on in parallel or even out of order. 

I hope that helps?

-John