Re: [Dyncast] CAN BoF issues and the next steps

Hi, Joel:
I think we all agree that the user want to better E2E application performance. 
The underlay network has invented various tools to achieve such aims within its boundary, for example, various TE solutions, Segment Routing, Flexalgo etc, and more metrics(link bandwidth, link delay, link color etc.) are considered and added into the SPF calculations.

But, with the placement of the ANYCAST application servers closing to the users in different sites, the bottleneck to influence the E2E application performance is not only the network metric, the metric for the application servers play a major role now.
It is time to consider both the network metric and application server metric together to achieve such goals.

There are already existing similar approaches, for example, LB based solution. But as analyzed during the BoF meeting, to solve the above problem, LB based solution will also dive into one similar signaling protocol and SPF calculation process.
Then, I think we should analyze what's the main concerns to let router do such more clever selection and find the solution to mitigate the influences.

Best Regards

Aijun Wang
China Telecom   

-----Original Message-----
From: dyncast-bounces@ietf.org <dyncast-bounces@ietf.org> On Behalf Of Joel M. Halpern
Sent: Monday, April 11, 2022 10:36 PM
To: liupengyjy@chinamobile.com; dyncast <dyncast@ietf.org>
Subject: Re: [Dyncast] CAN BoF issues and the next steps

I believe I was very clear during the BoF.  I have not seen a persuasive case for why we need to use the underlay routing system to address the problem of enabling communication between end user applications and edge located compute services.

There are multiple ways to improve the application situation without burdening the underlay routing with something it does not care about.

Yours,
Joel

On 4/11/2022 10:30 AM, liupengyjy@chinamobile.com wrote:
> Dear Joel,
> 
> Sorry, more accurately, we didn't hear any objections on the use case.
> 
> We are eager to hear any issues with the use cases presented. We would 
> appreciate it very much if you can elaborate issues you have with the 
> use case.
> 
> Regards,
> Peng
> ----------------------------------------------------------------------
> --
> liupengyjy@chinamobile.com
> 
>     *From:* Joel M. Halpern <mailto:jmh@joelhalpern.com>
>     *Date:* 2022-04-11 20:41
>     *To:* liupengyjy@chinamobile.com
>     <mailto:liupengyjy@chinamobile.com>; dyncast <mailto:dyncast@ietf.org>
>     *Subject:* Re: [Dyncast] CAN BoF issues and the next steps
>     Please do not overstate the situation.
>     I do not think that "almost everyone agreed" to anything in that BoF.
>     And in particular, I do not think that "almost everyone agreed" to the
>     value for additional metrics.
>     Yours,
>     Joel
>     On 4/11/2022 2:36 AM, liupengyjy@chinamobile.com wrote:
>      > Dear all,
>      >
>      > Thanks for supporting and joining the CAN work.  We can
>     see that the BoF
>      > was successful and had a good discussion, and almost everyone
>     agree on
>      > the use case that considering more metrics for steering traffic is
>      > valuable and a right direction.
>      > https://notes.ietf.org/notes-ietf-113-can
>      > <https://notes.ietf.org/notes-ietf-113-can>.
>      >
>      > Here we list the issues according to BoF talking and give the
>      > preliminary answers to them, which could be found at
>      > https://github.com/CAN-IETF/CAN-BoF-ietf113/issues
>      > <https://github.com/CAN-IETF/CAN-BoF-ietf113/issues>. If missing any
>      > issue, please let us know and we could add it. The issues will
>     continue
>      > to be iterated and then closed.
>      >
>      > Moreover, we will update the key drafts according to the BoF
>     talking and
>      > further thinking. If you have the interests, please feel free to
>     contact
>      > us.
>      >
>      > Regards,
>      > Peng
>      >
>      >
>     ------------------------------------------------------------------------
>      > liupengyjy@chinamobile.com
>      >
> 

--
Dyncast mailing list
Dyncast@ietf.org
https://www.ietf.org/mailman/listinfo/dyncast