Re: [Dyncast] New Version Notification fordraft-liu-dyncast-ps-usecases-00.txt

刘鹏 <liupengyjy@chinamobile.com> Tue, 02 February 2021 11:47 UTC

Return-Path: <liupengyjy@chinamobile.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 E03363A19E4 for <dyncast@ietfa.amsl.com>; Tue, 2 Feb 2021 03:47:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.684
X-Spam-Level:
X-Spam-Status: No, score=-0.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BIGNUM_EMAILS=1.214, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 pAYFTvh9Q5Bd for <dyncast@ietfa.amsl.com>; Tue, 2 Feb 2021 03:47:44 -0800 (PST)
Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFED3A19D0 for <dyncast@ietf.org>; Tue, 2 Feb 2021 03:47:40 -0800 (PST)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.7]) by rmmx-syy-dmz-app03-12003 (RichMail) with SMTP id 2ee360193bcf6f8-97824; Tue, 02 Feb 2021 19:47:28 +0800 (CST)
X-RM-TRANSID: 2ee360193bcf6f8-97824
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from PENG (unknown[10.2.53.68]) by rmsmtp-syy-appsvr04-12004 (RichMail) with SMTP id 2ee460193bcd65f-487e6; Tue, 02 Feb 2021 19:47:28 +0800 (CST)
X-RM-TRANSID: 2ee460193bcd65f-487e6
MIME-Version: 1.0
x-PcFlag: cc85c55f-be7e-48ea-81b0-0edab6e3cf24_5_45962
X-Mailer: PC_RICHMAIL 2.8.5
Date: 02 Feb 2021 19:47:26 +0800
From: =?utf-8?B?5YiY6bmP?=<liupengyjy@chinamobile.com>
To: jmh<jmh@joelhalpern.com>
Cc: dyncast<dyncast@ietf.org>
Message-ID: <20210202194726988476397@chinamobile.com>
Content-Type: multipart/Alternative; boundary="----=_001_NextPart988476397_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dyncast/HYUB1XG62Qt1rSiTG7GNt3IXs0k>
Subject: Re: [Dyncast] New Version Notification fordraft-liu-dyncast-ps-usecases-00.txt
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: Tue, 02 Feb 2021 11:47:47 -0000


Thank you, Joel. 

We will consider your suggestion in the next revision and new draft. Anycast related text in current draft is intended to illustrate the communication model, not any specific protocol. It is certainly the problem can be solved in various ways. It could be the source of confusion. 






Best,

Peng











Peng Liu | 刘鹏

China Mobile | 移动研究院

mobile phone:13810146105

email:  liupengyjy@chinamobile.com

 



发件人: liupengyjy

时间: 2021/02/02(星期二)10:14

收件人: jmh;dyncast;

主题: Re:  [Dyncast] New Version Notification fordraft-liu-dyncast-ps-usecases-00.txt    Hi Joel,




The draft analyzes the gap of existing methods, and does not rule out other methods can be implemented, but the efficiency needs to be verified. 

Moreover, in the edge computing scenario, many native services are deployed by operators, so we think that the method of using anycast is feasible.

Best,

Peng Liu








  发件人: "JoelM.Halpern" <jmh@joelhalpern.com>
 发送日期: Mon Feb 01 22:24:08 GMT+08:00 2021
 收件人: dyncast <dyncast@ietf.org>
 主题: Re: [Dyncast] Fw: New Version Notification fordraft-liu-dyncast-ps-usecases-00.txt
  
 

This problem statement draft seems to assume a particular approach to 
the solution.

It is not at all obvious, absent the assumptions, that one wants to put 
the information into routing at all.  There are multiple approaches that 
address the problem that do not require the use of anycast addressing or 
injecting the application placement dynamics into the underlying routing 
system.

Yours,
Joel

On 2/1/2021 5:22 AM, 刘鹏 wrote:
 Dear all,

Welcome all to the mailing list for the problem of and work on dynamic 
anycast, enabling the consideration of compute and network metrics in 
the decision to route a flow of packets among more than one service 
instance. We have now uploaded the use case and problem statement draft, 
outlining a few pertinent use cases for this work, as well as 
shortcomings of existing solutions and requirements for a desirable 
solution. It is the intention to use this draft to frame the discussion 
towards a possible solution proposal. To this end, we also plan on 
releasing a first version of an architecture draft soon.

In the meantime, any comments and discussion on the use case and problem 
statement draft is highly welcome!

Best,

Peng Liu

Peng Liu | 刘鹏
China Mobile | 移动研究院
mobile phone:13810146105
email: _ liupengyjy@chinamobile.com_

    发件人: internet-drafts <mailto:internet-drafts@ietf.org>
    时间: 2021/02/01(星期一)18:15
    收件人: Dirk Trossen <mailto:dirk.trossen@huawei.com>;Peng Liu
    <mailto:liupengyjy@chinamobile.com>;Peter Willis
    <mailto:peter.j.willis@bt.com>;
    主题: New Version Notification for draft-liu-dyncast-ps-usecases-00.txt

A new version of I-D, draft-liu-dyncast-ps-usecases-00.txt
has been successfully submitted by Dirk Trossen and posted to the
IETF repository.

Name: draft-liu-dyncast-ps-usecases
Revision: 00
Title: Dynamic-Anycast (Dyncast) Use Cases and Problem Statement
Document date: 2021-02-01
Group: Individual Submission
Pages: 14
URL: https://www.ietf.org/archive/id/draft-liu-dyncast-ps-usecases-00.txt
Status: https://datatracker.ietf.org/doc/draft-liu-dyncast-ps-usecases/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-liu-dyncast-ps-usecases
Htmlized: https://tools.ietf.org/html/draft-liu-dyncast-ps-usecases-00

Abstract:
Service providers are exploring the edge computing to achieve better
response time, control over data and carbon energy saving by moving
the computing services towards the edge of the network in 5G MEC
(Multi-access Edge Computing) scenarios, virtualized central office,
and others. Providing services by sharing computing resources from
multiple edges is an emerging concept that is becoming more useful
for computationally intensive tasks. Ideally, services should be
computationally balanced using service-specific metrics instead of
simply dispatching the service in a static way, e.g., to the
geographically closest edge since this may cause unbalanced usage of
computing resources at edges which further degrades user experience
and system utilization. This draft provides an overview of scenarios
and problems associated with realizing such scenarios.

The document identifies several key areas which require more
investigations in terms of architecture and protocol to achieve
balanced computing and networking resource utilization among edges
providing the services.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat