Re: [Dyncast] Updates on Dyncast drafts

Dirk Trossen <> Mon, 22 February 2021 08:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8FC093A10B1 for <>; Mon, 22 Feb 2021 00:51:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1f0hsgZLuq9f for <>; Mon, 22 Feb 2021 00:51:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8AF5F3A0FCD for <>; Mon, 22 Feb 2021 00:51:15 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4DkbM5276lz67rXg; Mon, 22 Feb 2021 16:44:01 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2106.2; Mon, 22 Feb 2021 09:51:13 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Mon, 22 Feb 2021 08:51:12 +0000
Received: from ([]) by ([]) with mapi id 15.01.2106.006; Mon, 22 Feb 2021 08:51:12 +0000
From: Dirk Trossen <>
To: fuyuexia <>, 'Aijun Wang' <>, "" <>
Thread-Topic: [Dyncast] Updates on Dyncast drafts
Thread-Index: AdcDvSx2r+cf0yWpRWyYDcGimwJNKQDdNZ+AAGxS6QAABRgCEA==
Date: Mon, 22 Feb 2021 08:51:12 +0000
Message-ID: <>
References: <> <00a001d70732$03a652b0$0af2f810$> <01c701d708e3$5188fed0$f49afc70$@com>
In-Reply-To: <01c701d708e3$5188fed0$f49afc70$@com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_5c450d2854304e06bdce5e99644e4912huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Dyncast] Updates on Dyncast drafts
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Feb 2021 08:51:31 -0000

Dear Yuexia,

Many thanks for this pointer to the ITU work, which I recall from SG13 meetings last year. It is a good reference to point to.

As for the protocol work, there is, of course, much open for design and discussions. At this stage, our drafts aim at the key questions on whether this work is well motivated for being done in the routing area. A list of aspects that will need looking into would, however, indeed be useful to compile ¨C I understand your comment in that direction.



From: fuyuexia []
Sent: 22 February 2021 07:24
To: 'Aijun Wang' <>cn>; Dirk Trossen <>om>;
Subject: ´ð¸´: [Dyncast] Updates on Dyncast drafts

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.


Yuexia Fu
China Mobile

·¢¼þÈË: Dyncast [] ´ú±í Aijun Wang
·¢ËÍʱ¼ä: 2021Äê2ÔÂ20ÈÕ 10:42
ÊÕ¼þÈË: 'Dirk Trossen';<>
Ö÷Ìâ: 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:<> <<>> On Behalf Of Dirk Trossen
Sent: Tuesday, February 16, 2021 1:18 AM
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 and the Dyncast requirements at We have also uploaded a draft outlining a possible Dyncast architecture at

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.


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