Re: [Dyncast] Updates on Dyncast drafts

[Dirk Trossen <[e-mail]>]

Hi Aijun,

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

Best,

Dirk


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

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.

[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.

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

Best Regards

Aijun Wang
China Telecom



From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>> On Behalf Of Dirk Trossen
Sent: Tuesday, February 16, 2021 1:18 AM
To: [e-mail]<mailto:[e-mail]>
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.
[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?

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)