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

If the ingress edge does the calculation, makes the determination, and 
tunnels the traffic to the right place then the underlay routing system 
does not need to know anything about these metrics or the decision 
processes made by the edge.

Yours,
Joel

On 4/12/2022 10:52 PM, Aijun Wang wrote:
> Hi, Luigi:
> Why only the ingress need such decision? I think all the routers in-path
> need such information(routing metric +compute metric), to achieve the
> optimal "instance selection".
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -----Original Message-----
> From: dyncast-bounces@ietf.org <dyncast-bounces@ietf.org> On Behalf Of Luigi
> IANNONE
> Sent: Tuesday, April 12, 2022 3:04 PM
> To: Aijun Wang <wangaijun@tsinghua.org.cn>; 'Joel M. Halpern'
> <jmh@joelhalpern.com>; liupengyjy@chinamobile.com; 'dyncast'
> <dyncast@ietf.org>
> Subject: Re: [Dyncast] CAN BoF issues and the next steps
> 
> Hi,
> 
>> 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.
> 
> I think that Joel is not against the above (routing metric +compute metric =
> instance selection).
> I think that he is more inline with Dirk's position, meaning that it is not
> necessarily the routing layer that has to be "enhanced" with compute
> metrics.
> Rather, an in-path decision based on both metrics should be made by some
> (CAN ) element.
> My personal take is that the ingress is well suited for that (since for sure
> it is in-path).
> Then you have the choice of various ways on how to steer the traffic.
> 
> Ciao
> 
> L.
> 
> 
> 
> 
> --
> Dyncast mailing list
> Dyncast@ietf.org
> https://www.ietf.org/mailman/listinfo/dyncast
> 