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

Peng Liu <liupengyjy@chinamobile.com> Sat, 28 January 2023 02:48 UTC

Return-Path: <liupengyjy@chinamobile.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 12D97C14CE33; Fri, 27 Jan 2023 18:48:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.575
X-Spam-Level:
X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 zYey4e58udbF; Fri, 27 Jan 2023 18:48:37 -0800 (PST)
Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBB1C14CF0D; Fri, 27 Jan 2023 18:48:33 -0800 (PST)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from cmccmta.chinamobile.com (unknown[172.16.121.91]) by rmmx-syy-dmz-app06-12006 (RichMail) with SMTP id 2ee663d48cfd953-1ca04; Sat, 28 Jan 2023 10:48:31 +0800 (CST)
X-RM-TRANSID: 2ee663d48cfd953-1ca04
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from CMCC-LP (unknown[39.149.170.184]) by rmsmtp-syy-appsvrnew06-12031 (RichMail) with SMTP id 2eff63d48cfcfe1-ceaa9; Sat, 28 Jan 2023 10:48:30 +0800 (CST)
X-RM-TRANSID: 2eff63d48cfcfe1-ceaa9
Date: Sat, 28 Jan 2023 10:48:41 +0800
From: Peng Liu <liupengyjy@chinamobile.com>
To: Robert Raszuk <robert@raszuk.net>, "linda.dunbar" <linda.dunbar@futurewei.com>
Cc: jgs <jgs@juniper.net>, can <can@ietf.org>, "idr@ietf.org" <idr@ietf.org>, Dino Farinacci <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>
X-Priority: 3
X-GUID: 25EFD764-122E-446F-81FF-05CAC5459C5F
X-Has-Attach: no
X-Mailer: Foxmail 7.2.21.453[cn]
Mime-Version: 1.0
Message-ID: <2023012810484112984917@chinamobile.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart011155458258_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/r9FqMizThT67o5HNjW-X-C0KVR0>
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 02:48:43 -0000

Hi Robert,

There might be OTT based solutions that don't involve ingress/egress routers . But some environments, like in our 5G edge network, OTT method is more expensive than a mechanism for egress routers to distribute the information to ingress routers so that path selection engines can consider both. CAN aims at the case where the operator wants to offer the selection service from its edge devices.

In the 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.'

So CAN won't impact every routers but just egress and ingress, before the architecture, it is a little early to determine which protocol could be used. But for the directions, I think IETF is for building various tools. like one person can use  knife to peel an apple doesn’t mean peeler shouldn’t be invented.  

Regards,
Peng


liupengyjy@chinamobile.com
 
From: Robert Raszuk
Date: 2023-01-28 05:35
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,

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