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

We are defining how the system will operate.  There is no "more popular" 
that we are trying to support.

Also, even if anycast is used by the end stations, the ingress and 
egress can still tunnel using proper unicast address to keep the routing 
system from becoming complicated with things it does not care about.

Yours,
Joel

PS: Personally, I like an approach even one step more drastic.  Have the 
host talk to a service to determine what application instance it should 
talk to, and use unicast between them.  But I am not insisting on that.

On 4/12/2022 10:59 PM, Aijun Wang wrote:
> Hi, Joel:
> If you use binding address behind the ANYCAST address, it is possible. But if you use the ANYCAST address directly, you can't.
> For my understanding, the latter scenario is more popular.
> 
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -----Original Message-----
> From: Joel M. Halpern <jmh@joelhalpern.com>
> Sent: Wednesday, April 13, 2022 10:55 AM
> To: Aijun Wang <wangaijun@tsinghua.org.cn>; 'Luigi IANNONE' <luigi.iannone=40huawei.com@dmarc.ietf.org>; liupengyjy@chinamobile.com; 'dyncast' <dyncast@ietf.org>
> Subject: 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
>>
> 