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

Hi Sue,

Thank you for your clarification, it is clear now.

Yes, my personal comment will be another path attribute, but we can discuss about which position is better.

Thanks,
Cheng

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Monday, August 22, 2022 5:40 AM
To: Chengli (Cheng Li) <c.l@huawei.com>; idr@ietf.org
Subject: RE: Adoption call for draft-dunbar-idr-5g-edge-compute-app-meta-data-09.txt (7/29/2022 to 8/12/2022)

Cheng:

My question below is unclear.

2) What type of additional load this data to Basic Tunnel encapsulation [RFC9012]?

[Cheng]Sorry, I do not really get this question.  But it is different with SR policy for sure.

I am asking whether adding these TLVS to the Tunnel Encapsulation path attribute
will create too much processing load on a computer.

The other alternatives are:
1) in a wide community,
2) include this in a separate path attribute.

I believe you correctly indicated your preference for a separate path attribute.

Cheers, Sue

From: Chengli (Cheng Li) <c.l@huawei.com<mailto:c.l@huawei.com>>
Sent: Tuesday, August 16, 2022 5:35 AM
To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: Adoption call for draft-dunbar-idr-5g-edge-compute-app-meta-data-09.txt (7/29/2022 to 8/12/2022)

Hi Sue and IDRers,

I read the draft and support the adoption with comments.

1. It may be good to use a new Path Attribute instead of putting TLV into Tunnel Encap Path attributes IMHO. This can be discussed after the adoption. The main idea of distributing APP metadata is useful.

2. Regarding the weighted Load Index[1]  in section 4.1. I am not really understand the meeting of only setting four weight for four types of metrics. It may need to comparing with the Capacity? Hope to see more clarification of this in the next revision.

Generally, I think this is a good starting point of a WG document, and would like to contribute to the draft if possible.

More reply, please see below.

Thanks and respect,

Cheng

[1]. https://datatracker.ietf.org/doc/html/draft-dunbar-idr-5g-edge-compute-app-meta-data-10#section-4.1

-----Original Message-----

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares

Sent: Friday, July 29, 2022 6:23 PM

To: idr@ietf.org<mailto: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)

This begins a 3 week WG Adoption call for draft-dunbar-idr-5g-edge-compute-app-meta-data-09.txt

https://datatracker.ietf.org/doc/draft-dunbar-idr-5g-edge-compute-app-meta-data/

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?

[Cheng]Yes, it is useful. But I have concern of where to put the information.

2) What type of additional load this data to Basic Tunnel encapsulation [RFC9012]?

[Cheng]Sorry, I do not really get this question.  But it is different with SR policy for sure.

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?

[Cheng] it can help in 5G networks.

Cheers, Sue Hares

_______________________________________________

Idr mailing list

Idr@ietf.org<mailto:Idr@ietf.org>

https://www.ietf.org/mailman/listinfo/idr