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

["[e-mail]" <[e-mail]>]

Hi, Linda, and the authors:

    Some comments about draft-ietf-idr-5g-edge-service-metadata-02.txt for your considerations.

    About the metric distribution, I think the BGP method is one of the important ways. And perhaps in CATS, we need to start from the simple cases. However, future extensions should be supported.
 IMHO, the way in this document should be supported in future versions of the CATS metric draft, for the scenario that the service instance does not support the direct notification of the computing information.

    For example, we can extend the format with more information to show it is extensible.
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Service-Metadata Type       |        Length (2 Octets)      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
|     Flags     |   FormatID    |   AlgoID      |   Reserved    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |         Value (multiple Metadata sub-TLVs)                    |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 1: Edge Service Metadata Path Attribute
o  FormatID (1 octets): indicate a specific format, i.e., which set of TLVs would be included.
     o  AlgoID (1 octets): the suggested algorithm to compare the cost to reach the service in different servers.

    Thus, we can define different FormatIDs for different scenarios. 

 Another suggestion about the draft is about the migration of the computing information. You can consider whether it is valuable and acceptable.
 In the current CATS framework draft, as shown below, the granularity of the computing information can be per-service instance Or aggregated per-site.
 
   Note that, depending on the design considerations and service   requirements, per-service instance computing-related metrics or   aggregated per-site computing related metrics (and a combination   thereof) can be used by a C-PS.  Using aggregated per-site computing   related metrics appears as a privileged option scalability-wise, but   relies on Egress CATS-Routers that connect to various service   instances to select the proper service instance.
 
 However, IMHO, we can also merge the computing information in the per Egress Router granularity. The advantage is that we can merge again the computing information if more than one site connect to the Egress. However, more TLVs are needed here.
 
Example of Aggregation Descriptions

     It is said that a cluster of servers serving the same Application behind a Layer 7 Load balancer can be considered as one merged Application server.
     In this case, the compute metrics from each server within the site will be merged at the site level.
    Optionally, if the Egress can do another round of load balancing among the local sites that connects directly to it, the Egress can merge again the compute metrics from the local sites. The advantage is that we can reduce the metric information that needs to be transferred in the network. But new TLVs need to be designed.

Best Regards
Zongpeng Du



[e-mail] & [e-mail] 


[Idr] I-D Action: draft-ietf-idr-5g-edge-service-metadata-02.txt
[e-mail] Thu, 04 May 2023 23:17 UTCShow header
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Inter-Domain Routing
(IDR) WG of the IETF.
   Title           : BGP Extension for 5G Edge Service Metadata
   Authors         : Linda Dunbar
                     Kausik Majumdar
                     Haibo Wang
                     Gyan Mishra
   Filename        : draft-ietf-idr-5g-edge-service-metadata-02.txt
   Pages           : 19
   Date            : 2023-05-04
Abstract:
   This draft describes a new Metadata Path Attribute and some
   sub-TLVs for egress routers to advertise the Edge Service
   Metadata of the directly attached edge services (ES). The Edge
   Service Metadata can be used by the ingress routers in the 5G
   Local Data Network to make path selections not only based on
   the routing cost but also the running environment of the edge
   services. The goal is to improve latency and performance for
   5G edge services.
   The extension enables an edge service at one specific location
   to be more preferred than the others with the same IP address
   (ANYCAST) to receive data flow from a specific source, like
   specific User Equipment (UE).
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-5g-edge-service-metadata/
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-5g-edge-service-metadata-02
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-idr-5g-edge-service-metadata-02