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

From: Peng Liu<[email-masked]>
Date: 11 Apr 2022 23:38:31 +0800

Hi Joel,

It is about the solution. Yes, one of the takeaways from the BoF is not loading underlay network with application details. We will add this to the issue list. Thanks.

Regards,

Peng

Peng Liu | 刘鹏

China Mobile | 移动研究院

mobile phone：13810146105

email:  [email-masked]

发件人: Dirk Trossen

时间: 2022/04/11(星期一)22:39

收件人: Joel M. Halpern;liupengyjy;dyncast;

主题: RE: [Dyncast] CAN BoF issues and the next stepsJoel,

Indeed, there was a clear message (from what I recall from the chat comments) towards thinking of the realization of such capability in relation to the underlay and particular the routing system. 

From my side, I don't see the need to place this into the underlay as a given, while the question to realize a compute-aware on-path endpoint selection decision may well be of interest. Is that a fair statement?

Best,

Dirk

-----Original Message-----
From: Dyncast [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: 11 April 2022 16:36
To: [email-masked]; dyncast <[email-masked]>
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, [email-masked] 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
> ----------------------------------------------------------------------
> --
> [email-masked]
> 
>     *From:* Joel M. Halpern <mailto:[email-masked]>
>     *Date:* 2022-04-11 20:41
>     *To:* [email-masked]
>     <mailto:[email-masked]>; dyncast <mailto:[email-masked]>
>     *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, [email-masked] 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
>      >
>      >
>     ------------------------------------------------------------------------
>      > [email-masked]
>      >
> 

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