Subject: [Dyncast] Updates on Dyncast drafts

From: Dirk Trossen <[email-masked]>
Date: Mon, 15 Feb 2021 17:18:29 +0000

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?
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?

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)

---

From: "Aijun Wang" <[email-masked]>
Date: Sat, 20 Feb 2021 10:42:21 +0800

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: [email-masked] <[email-masked]> On Behalf Of Dirk
Trossen
Sent: Tuesday, February 16, 2021 1:18 AM
To: [email-masked]
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,

---

From: "fuyuexia" <[email-masked]>
Date: Mon, 22 Feb 2021 14:24:00 +0800

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:[email-masked]] 代表 Aijun Wang
发送时间: 2021年2月20日 10:42
收件人: 'Dirk Trossen'; [email-masked]
主题: Re: [Dyncast] Updates on Dyncast drafts

Hi, Dirk:

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”:

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.

Best Regards

Aijun Wang

China Telecom

Dear All,

Best,

---

From: Dirk Trossen <[email-masked]>
Date: Mon, 22 Feb 2021 08:24:16 +0000

Hi Aijun,

Many thanks for the comments. Please see inline as [DOT].

Best,

Dirk

From: Aijun Wang [mailto:[email-masked]]
Sent: 20 February 2021 03:42
To: Dirk Trossen <[email-masked]>; [email-masked]
Subject: 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":

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.

[DOT] The D-SID provides the identification of the service, while the D-BID provides the mapping onto a specific service instance being selected as a destination for a service request towards D-SID. What you describe, i.e., "to select the most optimal path to reach the service" is done by the D-Router by mapping the D-SID onto a specific service instance (using the metrics to perform the selection), this instance being identified through D-BID. What I'm not sure is what you mean with "in several locations for one service"? The service has indeed a single identifier and is being realized in different locations, those network locations being identified by D-BID. I wonder if you are suggesting to use a fully routed model, i.e., route directly on the D-SID instead of mapping the D-SID to the D-BID? The reason for doing the latter is to enable an ingress architecture, i.e., focusing the dyncast capability in the ingress while re-using the locator-based addressing and routing in the network. This minimizes necessary change, i.e., allows for using existing routers beyond the dyncast ingress.

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.
[DOT] The D-Forwarder is motivated in the arch draft by allowing for pushing the D-SID to D-BID mapping closer to the client. It is an optional component, i.e., you can entirely rely on the D-router only.

Best Regards

Aijun Wang
China Telecom

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of Dirk Trossen
Sent: Tuesday, February 16, 2021 1:18 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dyncast] Updates on Dyncast drafts

Dear All,

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.
[DOT] apologies for the unclear wording from my side: this question is not really about solving the problems in the routing area as a matter of possibility but whether we should solve these problems in the routing area rather than relying on higher, e.g., application-level solutions.

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.
[DOT] Could you please point out those protocol-specific WGs to contribute solutions to?

Best,

---

From: Dirk Trossen <[email-masked]>
Date: Mon, 22 Feb 2021 08:51:12 +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 – I understand your comment in that direction.

Best,

Dirk

From: fuyuexia [mailto:[email-masked]]
Sent: 22 February 2021 07:24
To: 'Aijun Wang' <[email-masked]>; Dirk Trossen <[email-masked]>; [email-masked]
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.

Regards,

Yuexia Fu
China Mobile

发件人: Dyncast [mailto:[email-masked]] 代表 Aijun Wang
发送时间: 2021年2月20日 10:42
收件人: 'Dirk Trossen'; [email-masked]<mailto:[email-masked]>
主题: 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”:

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.

Best Regards

Aijun Wang
China Telecom

Dear All,

Best,

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 23 Feb 2021 11:12:29 +0800

Hi, Dirk:

I think the mapping between D-SID and D-BID is more like DNS mapping. If so,
current architecture is not solely one routing solution, but related to the
deployment of upper-layer(for example, DNS-like system). 

For routing area, I think they mainly consideration how to accomplish the
optimal path to D-BID, and don't care the mapping between D-SID and D-BID.

For protocol-specific  contribution, I think you can pay attention to LSR
for IGP extension related draft, and IDR for BGP extension related draft.

Actually, there are two related drafts has already been posted that related
to Dyncast, I think you can refer them:

https://datatracker.ietf.org/doc/html/draft-dunbar-idr-5g-edge-compute-app-m
eta-data-01( BGP Extension)

https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-ospf-
ext-02 (OSPF Extension)

Can the above two drafts address the requirements of Dyncast?

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Dirk
Trossen
Sent: Monday, February 22, 2021 4:24 PM
To: Aijun Wang <[email-masked]>; [email-masked]
Subject: Re: [Dyncast] Updates on Dyncast drafts

Hi Aijun,

Best,

Dirk

From: Aijun Wang [mailto:[email-masked]] 
Sent: 20 February 2021 03:42
To: Dirk Trossen <[email-masked] <mailto:[email-masked]>
>; [email-masked] <mailto:[email-masked]> 

Hi, Dirk:

[DOT] The D-SID provides the identification of the service, while the D-BID
provides the mapping onto a specific service instance being selected as a
destination for a service request towards D-SID. What you describe, i.e.,
"to select the most optimal path to reach the service" is done by the
D-Router by mapping the D-SID onto a specific service instance (using the
metrics to perform the selection), this instance being identified through
D-BID. What I'm not sure is what you mean with "in several locations for one
service"? The service has indeed a single identifier and is being realized
in different locations, those network locations being identified by D-BID. I
wonder if you are suggesting to use a fully routed model, i.e., route
directly on the D-SID instead of mapping the D-SID to the D-BID? The reason
for doing the latter is to enable an ingress architecture, i.e., focusing
the dyncast capability in the ingress while re-using the locator-based
addressing and routing in the network. This minimizes necessary change,
i.e., allows for using existing routers beyond the dyncast ingress. 

[DOT] The D-Forwarder is motivated in the arch draft by allowing for pushing
the D-SID to D-BID mapping closer to the client. It is an optional
component, i.e., you can entirely rely on the D-router only. 

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <mailto:[email-masked]>
<[email-masked] <mailto:[email-masked]> > On Behalf Of
Dirk Trossen
Sent: Tuesday, February 16, 2021 1:18 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [Dyncast] Updates on Dyncast drafts

Dear All,

[DOT] apologies for the unclear wording from my side: this question is not
really about solving the problems in the routing area as a matter of
possibility but whether we should solve these problems in the routing area
rather than relying on higher, e.g., application-level solutions.

[DOT] Could you please point out those protocol-specific WGs to contribute
solutions to?

Best,

---

From: Dirk Trossen <[email-masked]>
Date: Tue, 23 Feb 2021 07:59:47 +0000

Hi Aijun,

Thanks for the comments; please see inline.

Best,

Dirk

From: Aijun Wang [mailto:[email-masked]]
Sent: 23 February 2021 04:12
To: Dirk Trossen <[email-masked]>; [email-masked]
Cc: 'Linda Dunbar' <[email-masked]>
Subject: RE: [Dyncast] Updates on Dyncast drafts

Hi, Dirk:

I think the mapping between D-SID and D-BID is more like DNS mapping. If so, current architecture is not solely one routing solution, but related to the deployment of upper-layer(for example, DNS-like system).
[DOT] Please see Section 4 of the use cases draft where we also discuss the use of DNS + IP routing for the use cases. Dyncast proposes to address the mapping at the routing level but there needs to be a linkage to upper layers, e.g., for the creation of a suitable D-SID.
For routing area, I think they mainly consideration how to accomplish the optimal path to D-BID, and don't care the mapping between D-SID and D-BID.
[DOT] The 'mapping' in dyncast is about choosing the right destination and also, to an extent, the right path. The input comes here from the metrics used for that decision and the affinity to a previously chosen service instance.

For protocol-specific  contribution, I think you can pay attention to LSR for IGP extension related draft, and IDR for BGP extension related draft.
Actually, there are two related drafts has already been posted that related to Dyncast, I think you can refer them:

https://datatracker.ietf.org/doc/html/draft-dunbar-idr-5g-edge-compute-app-meta-data-01( BGP Extension)
https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-ospf-ext-02 (OSPF Extension)

Can the above two drafts address the requirements of Dyncast?
[DOT] Thanks for those pointers; we will look at them in more detail.

Best Regards

Aijun Wang
China Telecom

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of Dirk Trossen
Sent: Monday, February 22, 2021 4:24 PM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dyncast] Updates on Dyncast drafts

Hi Aijun,

Best,

Dirk

From: Aijun Wang [mailto:[email-masked]]
Sent: 20 February 2021 03:42
To: Dirk Trossen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dyncast] Updates on Dyncast drafts

Hi, Dirk:

Best Regards

Aijun Wang
China Telecom

Dear All,

Best,

---

From: Tianji Jiang <[email-masked]>
Date: Thu, 25 Feb 2021 18:08:38 -0800

Hi,

Thank you for sharing the 2 documents.

[quoted]

[Tianji] my understanding is that these proposals are trying to address a similar issue *only* from the routing domain. While they might keep minimal changes in current implementation, they are not able to reflect what ‘Dyncast’ strives for. For example, using traffic-load to/from a DC is too coarse to differentiate among numerous application backends that would be running on different hosts (bare-metal, VM), with different specs (i.e., computing-metrics, service-metrics). 

Yes, Dyncast will have to address the routing-related issues later, but regardless, the potential scheme would require more granular collection & utilization of metrics.

BR,

-Tianji

 

From: Dyncast <[email-masked]> on behalf of Dirk Trossen <[email-masked]>
Date: Monday, February 22, 2021 at 11:59 PM
To: Aijun Wang <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: 'Linda Dunbar' <[email-masked]>
Subject: Re: [Dyncast] Updates on Dyncast drafts

Hi Aijun,

Best,

Dirk

Hi, Dirk:

For routing area, I think they mainly consideration how to accomplish the optimal path to D-BID, and don’t care the mapping between D-SID and D-BID.

[DOT] The ‘mapping’ in dyncast is about choosing the right destination and also, to an extent, the right path. The input comes here from the metrics used for that decision and the affinity to a previously chosen service instance.

 

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Dirk Trossen
Sent: Monday, February 22, 2021 4:24 PM
To: Aijun Wang <[email-masked]>; [email-masked]
Subject: Re: [Dyncast] Updates on Dyncast drafts

Hi Aijun,

Best,

Dirk

Hi, Dirk:

[DOT] The D-SID provides the identification of the service, while the D-BID provides the mapping onto a specific service instance being selected as a destination for a service request towards D-SID. What you describe, i.e., “to select the most optimal path to reach the service” is done by the D-Router by mapping the D-SID onto a specific service instance (using the metrics to perform the selection), this instance being identified through D-BID. What I’m not sure is what you mean with “in several locations for one service”? The service has indeed a single identifier and is being realized in different locations, those network locations being identified by D-BID. I wonder if you are suggesting to use a fully routed model, i.e., route directly on the D-SID instead of mapping the D-SID to the D-BID? The reason for doing the latter is to enable an ingress architecture, i.e., focusing the dyncast capability in the ingress while re-using the locator-based addressing and routing in the network. This minimizes necessary change, i.e., allows for using existing routers beyond the dyncast ingress. 

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Dirk Trossen
Sent: Tuesday, February 16, 2021 1:18 AM
To: [email-masked]
Subject: [Dyncast] Updates on Dyncast drafts

Dear All,

Best,

-- Dyncast mailing list [email-masked] https://www.ietf.org/mailman/listinfo/dyncast