Re: [Idr] some comments about the draft-ietf-idr-5g-edge-service-metadata-14.txt

[linchangwang <[e-mail]>]

Hi Linda,

Thank you for your quick reply, please see my reply inline.

Thanks,
Changwang

From: Linda Dunbar [mailto:[e-mail]]
Sent: Wednesday, December 20, 2023 3:13 AM
To: linchangwang (RD); [e-mail]
Cc: idr@ietf. org
Subject: RE: [Idr] some comments about the draft-ietf-idr-5g-edge-service-metadata-14.txt

Chang Wang,

Thank you very much for the comments and the suggestions.
Please see below of detailed resolutions to your comments.

Linda

From: linchangwang <[e-mail]>
Sent: Tuesday, December 19, 2023 8:21 AM
To: Linda Dunbar <[e-mail]>; [e-mail]
Cc: idr@ietf. org <[e-mail]>
Subject: [Idr] some comments about the draft-ietf-idr-5g-edge-service-metadata-14.txt

Hi Linda,

  Here are some comments on the draft-ietf-idr-5g-edge-service-metadata-14.txt for your consideration.


1.        1. BGP RR :

2.         It is recommended to add that in BGP RR networking, the next hop should not be changed, and the add-path feature should be used to advertise multiple routes with different next hops and metrics for the same prefix. The document does not mention the scenario of having BGP Route Reflectors (RRs) in the network. When BGP RRs are present, only the best path is reflected, and non-best paths are not sent. However, for anycast routes in such a service, it is necessary for BGP RRs to send all site routes, for example, by using the add-path feature to send the routes.

3.          BGP RR (Route Reflector) only advertises a single route, and in this document, it is required to advertise routes with the same prefix but different metrics and next hops. It is recommended to provide additional clarification in the document. The BGP RR mentioned here is different from the BGP RR controller mentioned in the document.



[Linda] RR is stated in the last paragraph of the Introduction:

“The extension is targeted for a single domain with RR controlling the propagation of the BGP UPDATE.  The edge service Metadata Path Attribute is only attached to the low latency services (routes) hosted in the 5G edge cloud sites, which are only a small subset of services initiated from UEs, not for UEs accessing many internet sites.”

Add-Path is for adding multiple paths to one NextHop. This draft is about selecting ONE optimal path to one of multiple nextHops.

[Changwang] The add-path feature I mentioned refers to RFC7911, which allows for the advertisement of multiple paths for the same address prefix without implicitly replacing any previous paths. In the given scenario, where three different sites (R1, R2, and R3) send different metadata to the RR device, it becomes necessary to utilize the RFC7911 mechanism. This mechanism ensures that when the RR sends the prefix aa08::4450 to the ingress router, it can include multiple next hops. Therefore, the RR must possess the capability to send multiple paths in order to comply with the requirements specified in RFC7911.
4.
5.         2. Regarding the description of the Capacity Availability Index Metadata in section 4.3, there is a question:
6.            In the case where there are multiple servers within the same site, how are the updated site utilization rates from multiple servers handled?
[Linda] This has changed in v15. Since several people expressed confusion of the naming, the name has been changed to “Site Physical Availability Index Metadata” which indicates the percentage of impact on a group of routes associated with a common physical characteristic, for example, a pod, a row of server racks, a floor, or an entire DC.

[Changwang] Looking forward to reviewing and discussing this further in v15.

7.         3. For Figure 3: Capacity Availability Index Sub-TLV, it is suggested to add a length field to the TLV.
8.             This TLV is associated with each prefix announcement, indicating the site ID associated with each prefix. Subsequently, we would like to notify fast switchover based on the percentage of available site IDs for a route. This logic is equivalent to adjusting the capacity of a site when the Route-Flag I is set to 0.
9.           However, this logic has some issues. We suggest announcing a single route, such as the minimum service IP address, to address this issue.


[Linda] this specific one has fixed Length. Please see the latest revision (-15).

[Changwang] Looking forward to reviewing and discussing this further in v15.
10.
11.     4.There is a question about the Service Delay Prediction Sub-TLV.
12.        Is the delay value the actual delay, or is it calculated through Service Delay Prediction Based on Load Measurement?
13.        The delay value is typically represented more accurately by using minimum, maximum, and average to denote the delay.
[Linda] Please see the attached email proposing the actual delay Sub-TLV.

[Changwang] Thanks, I'll think about it some more and then discuss it further.

14.     5. Concerning Figure 5: Service Delay Prediction Raw Measurements Sub-TLV,
15.         the "total number of bytes to Edge service" is defined as 4 bytes here, but the range of values may not be sufficient.
16.         It should be defined as an 8-byte field.
17.         This type of statistic, which is essentially a packet statistic, is recommended to be converted into a universal cost value before being sent to the head-end.
[Linda] You are correct. Some people suggested to remove this sub-TLV.

18.      6. How is the preference Index used? For ECMP routes, are they first selected based on the Preference Index?
[Linda] Different services might have different preference index values configured for the same site. For
example, Service-A requires high computing power, Service-B requires high bandwidth among
its microservices, and Service-C requires high volume storage capacity. For a DC with relatively
low storage capacity but high bisectional bandwidth, its preference index value for Service-B is
higher and lower for Service-C. Site Preference Index can also be used to achieve stickiness for
some services.


It is out of the scope of this document how the preference index is determined or configured.
19.      7. In section 5.3, Figure 6: Metadata Influenced Decision：
20.       BGP should prefer multiple paths for the prefix, and there should not be a difference in the description of BGP's best path selection and the forwarding plane's best path    selection. BGP needs to prefer all these multiple next hops in order to update them to the forwarding plane. Through metadata data, BGP can update the load-sharing   ratios of these preferred next hops. Therefore, the update of next hop weights should also be through BGP to RIB and then to update the next hop weights in the forwarding plane.
[Linda] The ingress node BGP processing results in one optimal path  with consideration of many factors. Section 5.3 is for the purpose.

[Changwang] The expression is, "Suppose a destination address for aa08::4450 can be reached by three next hops (R1, R2, R3). When BGP is optimizing among these three next hops, it must consider that they have metadata, which requires special handling. All three next hops need to be activated in order to update them to the RIB and then to the forwarding plane. The scenario wherein BGP only optimizes for one next hop, R1, and then optimizes for R2 with metadata, should not occur. In the control plane, R1, R2, and R3 all need to be optimized in order to be updated to the RIB, and then to the forwarding plane, followed by the selection of the next hop based on traffic and metadata. Specifically, only when BGP has optimized all of R1, R2, and R3, can the updates be made to the forwarding table."
             Prefix      Nexthop    Weight
           aa08::4450      R1         10
                           R2         80
                           R3         10


Best Regards
Changwang
-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, which is
intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender
by phone or email immediately and delete it!