IETF Logo Mail Archive

Re: [Dyncast] edge capability feedback

Liyizhou <liyizhou@huawei.com> Thu, 11 March 2021 09:48 UTC

Return-Path: <liyizhou@huawei.com>
X-Original-To: dyncast@ietfa.amsl.com
Delivered-To: dyncast@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648A63A1752 for <dyncast@ietfa.amsl.com>; Thu, 11 Mar 2021 01:48:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqCfkkp05Cy0 for <dyncast@ietfa.amsl.com>; Thu, 11 Mar 2021 01:48:53 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145DA3A174D for <dyncast@ietf.org>; Thu, 11 Mar 2021 01:48:53 -0800 (PST)
Received: from fraeml734-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Dx3pf3VDlz67xkr for <dyncast@ietf.org>; Thu, 11 Mar 2021 17:40:42 +0800 (CST)
Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by fraeml734-chm.china.huawei.com (10.206.15.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 11 Mar 2021 10:48:47 +0100
Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 11 Mar 2021 17:48:45 +0800
Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.2106.013; Thu, 11 Mar 2021 17:48:45 +0800
From: Liyizhou <liyizhou@huawei.com>
To: Barry Greene <bgreene@senki.org>, =?utf-8?B?5YiY6bmP?= <liupengyjy@chinamobile.com>
CC: dyncast <dyncast@ietf.org>, Michael McBride <michael.mcbride@futurewei.com>
Thread-Topic: [Dyncast] edge capability feedback
Thread-Index: AQHXFh3FtC6jxKpVTkaD5R6AIXbTHKp9nFqAgADmHAA=
Date: Thu, 11 Mar 2021 09:48:45 +0000
Message-ID: <2c804ff785b948f9b42d9c0e18a29f9d@huawei.com>
References: <20210311102435132657878@chinamobile.com> <9A6BA68B-3916-413E-BD29-62D4096DF1D3@senki.org>
In-Reply-To: <9A6BA68B-3916-413E-BD29-62D4096DF1D3@senki.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.98.176]
Content-Type: multipart/alternative; boundary="_000_2c804ff785b948f9b42d9c0e18a29f9dhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/dyncast/oQWVZJII1C0Ge_dgsvCi_MhI1zM>
Subject: Re: [Dyncast] edge capability feedback
X-BeenThere: dyncast@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dyncast.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dyncast>, <mailto:dyncast-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dyncast/>
List-Post: <mailto:dyncast@ietf.org>
List-Help: <mailto:dyncast-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dyncast>, <mailto:dyncast-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Mar 2021 09:48:55 -0000

Hi Barry,

Is RFC8782 the one you mentioned as DOTS signaling channel?

AFAIK DOTS signal channel is most likely to report some risky traffic from DOTS client and server.
DOTS signaling channel is more for light weight info exchange regarding what the potential attack is between DOTS client and DOTS server. It is not relevant to where and what are the reachable serving address and also it is hardly the case a single client talking to a number of servers.
Client and server are pre-determined pair in most cases.

For metrics sync or distribution, a metric agent needs to distribute the metrics to a number of D-Routers so that each can make the own choices when a service demand reaches.

So DOTS signal channel was not designed for such purpose and it is a bit hard for me to imagine what kind of changes would be required to let it carry those metrics info and make such info flooded out.

Cheers,
Yizhou

From: Dyncast [mailto:dyncast-bounces@ietf.org] On Behalf Of Barry Greene
Sent: Thursday, March 11, 2021 11:34 AM
To: 刘鹏 <liupengyjy@chinamobile.com>
Cc: dyncast <dyncast@ietf.org>rg>; Michael McBride <michael.mcbride@futurewei.com>
Subject: Re: [Dyncast] edge capability feedback




On Mar 10, 2021, at 8:24 PM, 刘鹏 <liupengyjy@chinamobile.com<mailto:liupengyjy@chinamobile.com>> wrote:

The edge node could inform it's status to the D-routers based on the metric, such as CPU load or other metrics for the specific instance if defined in the furture, then the D-router could choose a suitable edge considering both network and computing or other specific status. We have some experimental verification and functional implementation.

Have you done the due diligence in past work in this area?

What you described above sounds like the signaling in the DOTS work (shifting load based on DDoS).

It is also should similar to Cisco Distributed Direct Routing Protocol (1997ish), TIDP/TMP (early 2000s), and some other network oriented shifting of edge loads.

What would be helpful is a review of all the past efforts (go back to the ‘90s) and review what worked and what did not work.

v2.8.7 | Report a Bug | By Email