[Dyncast] 答复: Updates on Dyncast drafts

fuyuexia <fuyuexia@chinamobile.com> Mon, 22 February 2021 06:24 UTC

Return-Path: <fuyuexia@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 1386B3A0BB8 for <dyncast@ietfa.amsl.com>; Sun, 21 Feb 2021 22:24:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 vp-xGleKj8Iu for <dyncast@ietfa.amsl.com>; Sun, 21 Feb 2021 22:24:24 -0800 (PST)
Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6102A3A0BB3 for <dyncast@ietf.org>; Sun, 21 Feb 2021 22:24:19 -0800 (PST)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.15]) by rmmx-syy-dmz-app07-12007 (RichMail) with SMTP id 2ee760334e06d82-e2c38; Mon, 22 Feb 2021 14:24:07 +0800 (CST)
X-RM-TRANSID: 2ee760334e06d82-e2c38
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from YuexiaFu (unknown[10.1.6.6]) by rmsmtp-syy-appsvr08-12008 (RichMail) with SMTP id 2ee860334e0185d-4ffd2; Mon, 22 Feb 2021 14:24:05 +0800 (CST)
X-RM-TRANSID: 2ee860334e0185d-4ffd2
From: fuyuexia <fuyuexia@chinamobile.com>
To: 'Aijun Wang' <wangaijun@tsinghua.org.cn>, dirk.trossen@huawei.com, dyncast@ietf.org
References: <33e65ba11ecb471b83248bf0a5aafc73@huawei.com> <00a001d70732$03a652b0$0af2f810$@tsinghua.org.cn>
In-Reply-To: <00a001d70732$03a652b0$0af2f810$@tsinghua.org.cn>
Date: Mon, 22 Feb 2021 14:24:00 +0800
Message-ID: <01c701d708e3$5188fed0$f49afc70$@com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_01C8_01D70926.5FAC3ED0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQJARhSlo6UN8wd+7gkUi2Z5IHQxNamNziCQgANprJA=
Content-Language: zh-cn
Archived-At: <https://mailarchive.ietf.org/arch/msg/dyncast/FuWw-uEi5Xg3gDFjGKm_mWZDrXE>
Subject: [Dyncast] 答复: Updates on Dyncast drafts
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: Mon, 22 Feb 2021 06:24:32 -0000

Dear all,

 

We have initiated a work item Y.CAN-reqts: “Functional requirements of
computing-aware networking“in ITU-T in Oct,2019, and several technical
requirements are presented including distributed computing information
awareness, broadcasting and computing-aware routing. The attached file is
the draft recommendation for reference.

 

We think that this work item is closely related to Dyncast. It would be good
to see some protocol specific work moved forward in IETF to support those
deployment requirements. So to Dirk’s question, I think routing area work
is a good way to go.

 

At the same time, currently the architecture has not deeply dug the protocol
designs. It might be still early at this stage, but I think more specific
proposals (maybe in next few months) would help us to understand what work
to be expected. 

 

 

Regards,

 

Yuexia Fu

China Mobile

 

发件人: Dyncast [mailto:dyncast-bounces@ietf.org] 代表 Aijun Wang
发送时间: 2021年2月20日 10:42
收件人: 'Dirk Trossen'; dyncast@ietf.org
主题: Re: [Dyncast] Updates on Dyncast drafts

 

Hi, Dirk:

 

I have a quick review of the usecase and architecture draft that you
provides and think this is one interesting topic to discuss within IETF.

Regarding to the usecase draft, as I known, there are also other SDO(ITU
etc.) studying on this topic, can anyone share what their progress now and
can we refer to their work to prove the necessary of such service needed in
the network?

Regarding to the architecture draft, I am litter confusion about two mapping
components as described in section 5. ” Dyncast Control-plane vs Data-plane
operations”:

1.     Why we need the mapping of (D-SID, D-BID)?  

We are mentioning “Dynamic Anycast” architecture, why don’t’ use just
one unique D-SID in several locations for one service?  The router have the
capabilities to select what’s the most optimal path to reach the service
that identified by D-SID.

 

2.     Why we need the mapping between D-Router and D-Forwarder?

It seems not easy to introduces the D-Forwarder entity into the network,
also the mapping between them. I think we should first focus on utilizing
the existing network devices to accomplish the aim.

 

The answers to your questions are inline below [WAJ].

 

Best Regards

 

Aijun Wang

China Telecom

 

 

 

From: dyncast-bounces@ietf.org <dyncast-bounces@ietf.org> On Behalf Of Dirk
Trossen
Sent: Tuesday, February 16, 2021 1:18 AM
To: dyncast@ietf.org
Subject: [Dyncast] Updates on Dyncast drafts

 

Dear All,

 

For the preparation to the planned side meeting at the upcoming IETF110
(more details on this will follow in a separate email), it is our intention
to formulate use cases, problems and architectural requirements for
addressing those problems in order to focus this side meeting on the
following two main questions:

1.       Are the use cases compelling and the problems worth to be discussed
and possibly solved in the routing area?

[WAJ] Yes, I think it is possibly solved in the routing area.

 

2.       What would be the best approach in doing so within the IETF, e.g.,
through a new WG focusing on dyncast or through contributions to existing,
protocol-specific WGs, with problem and requirements kept as contributions
to the RTG WG?

        [WAJ] Based on current information about the use case and the aim, I
think contributions to existing, protocol-specific WGs is feasible.

 

Depending on what the community thinks, we will go for a more formal meeting
at IETF111. 

 

As input material for our discussion, we have uploaded the following three
Dyncast drafts to the datatracker, namely the Dyncast use case and problem
statement at
https://www.ietf.org/archive/id/draft-liu-dyncast-ps-usecases-01.txt and the
Dyncast requirements at
https://www.ietf.org/archive/id/draft-liu-dyncast-reqs-00.txt. We have also
uploaded a draft outlining a possible Dyncast architecture at
https://www.ietf.org/archive/id/draft-li-dyncast-architecture-00.txt

 

Any comments or views on either of those two questions above are warmly
welcome in preparation to the planned side meeting. We hope to see many of
you there.

 

Best,

 

 

Dirk (on hehalf of the authors of the Dyncast drafts)