Re: [Idr] [Dyncast] Adoption call for draft-dunbar-idr-5g-edge-compute-app-meta-data-09.txt (7/29/2022 to 8/12/2022)

+1

Cheers,
Jeff

> On Aug 8, 2022, at 06:19, Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org> wrote:
> 
> I agree with Jeffrey. Given that the selection of endpoints at the application layer is already at an advanced level, the draft is predicated on a subset of this selection process being done with anycast addresses at the routing layer. 
> 
> Thanks,
> Acee
> 
> On 8/4/22, 1:51 PM, "Dyncast on behalf of Jeffrey (Zhaohui) Zhang" <dyncast-bounces@ietf.org on behalf of zzhang=40juniper.net@dmarc.ietf.org> wrote:
> 
>    Hi,
> 
>    There was a CAN BOF in IETF113:
> 
>    https://datatracker.ietf.org/doc/bofreq-liu-computing-aware-networking-can/
>    https://www.youtube.com/watch?v=_0uanSBJz5c&ab_channel=IETF-InternetEngineeringTaskForce
> 
>    There have been extensive and on-going discussions on whether we should solve the problem in routing. There were two presentations on the follow-up in IETF114 as well. My understandings are:
> 
>    - It is not decided yet if/where there will be a CAN WG and whether we should standardize a routing-based solution
>    - This draft is a routing-based solution for the use case
> 
>    Based on above, I do not think we should rush to adopt it - it should be deferred to until CAN is decided.
> 
>    I am copying the CAN mailing list (dyncast@ietf.org).
> 
>    Thanks.
>    Jeffrey
> 
> 
>    Juniper Business Use Only
> 
>    -----Original Message-----
>    From: Idr <idr-bounces@ietf.org> On Behalf Of Susan Hares
>    Sent: Friday, July 29, 2022 6:23 AM
>    To: idr@ietf.org
>    Subject: [Idr] Adoption call for draft-dunbar-idr-5g-edge-compute-app-meta-data-09.txt (7/29/2022 to 8/12/2022)
> 
>    [External Email. Be cautious of content]
> 
> 
>    This begins a 3 week WG Adoption call for draft-dunbar-idr-5g-edge-compute-app-meta-data-09.txt
>    https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-dunbar-idr-5g-edge-compute-app-meta-data/__;!!NEt6yMaO-gk!FUoaLlWqdv8TPFCwzEtE2-8x6PRa-AsjklFfcIuNSadWVhqdf7uktC31Ynli5-IYysRSNv_WVVS6-sg$
> 
>    This draft proposes a new SubTLV (AppMetaData) for the BGP Tunnel Encapsulation Attribute [RFC9012] that indicates the running status and environment of directly attached 5G Edge Computing (EC) instances.
> 
>    The AppMetaData can be used by routers in the 5G Local Data Network to make path selection not only based on the routing distance but also the running environment of the destinations. The goal is to improve latency and performance for 5G EC services.
> 
>    In your discussion of this adoption call, please consider these questions:
> 
>    1) The addition of this type of information to tunnels is useful for inter-domain routing within 5G networks?
> 
>    2) What type of additional load this data to Basic Tunnel encapsulation [RFC9012]?
> 
>    For example is the load placed by this draft equal or Less than the SR routing additions from such as draft-ietf-idr-segment-routing-te-policy?
> 
>    3) Will the addition of this information aid Routing in 5G networks?
> 
>    Cheers, Sue Hares
> 
>    _______________________________________________
>    Idr mailing list
>    Idr@ietf.org
>    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!FUoaLlWqdv8TPFCwzEtE2-8x6PRa-AsjklFfcIuNSadWVhqdf7uktC31Ynli5-IYysRSNv_W1s6-HKo$
> 
>    -- 
>    Dyncast mailing list
>    Dyncast@ietf.org
>    https://www.ietf.org/mailman/listinfo/dyncast
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr