Network Working Group L. Dunbar Internet-Draft Futurewei Intended status: Standards Track C. Li Expires: 9 June 2026 Huawei Technologies 6 December 2025 BGP Edge Metadata Path Applicability draft-dunbar-cats-5g-metadata-applicability-00 Abstract This document analyzes the applicability of the Edge Metadata Path Attribute specified in (ietf-idr-5g-edge-service-metadata) to the computing and service related metrics defined by the IETF CATS Working Group. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 9 June 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Dunbar & Li Expires 9 June 2026 [Page 1] Internet-Draft Metadata Applicability December 2025 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Summary of 5G Edge Service Metadata Mechanism . . . . . . . . 4 3.1. Attribute Structure . . . . . . . . . . . . . . . . . . . 4 3.2. High-Level Distribution Behavior . . . . . . . . . . . . 4 3.3. Mapping Sub-TLVs to CATS Metric Categories (Overview) . . 4 4. Applicability of 5G Edge Metadata to CATS Metrics . . . . . . 5 4.1. Compute/Resource Capability (CATS L1/L2) . . . . . . . . 5 4.2. Compute/Resource Availability (CATS L1) . . . . . . . . . 5 4.3. Service Processing Delay (CATS L0 or L1) . . . . . . . . 5 4.4. Traffic Load / Utilization (CATS L0-L1/L2 . . . . . . . . 6 4.5. Site Preference (CATS L2 policy metric) . . . . . . . . . 6 4.6. Site Physical Availability (CATS Shared Resource) . . . . 6 4.7. Expressiveness, Granularity, Update Semantics . . . . . . 7 5. Distribution Model and Leakage Prevention . . . . . . . . . . 7 6. Metric Lifetimes . . . . . . . . . . . . . . . . . . . . . . 7 7. Granularity Semantics Issues . . . . . . . . . . . . . . . . 7 8. Scalability and Churn Considerations . . . . . . . . . . . . 8 9. Gaps and Extensions Needed for CATS Compliance . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 14.1. Normative References . . . . . . . . . . . . . . . . . . 9 14.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Service Delay Prediction Based on Load Measurement . . . . . . . . . . . . . . . . . . . . . . . 12 Appendix B. Service Metadata Influenced Decision Process . . . . 13 B.1. Egress Router Behavior . . . . . . . . . . . . . . . . . 13 B.2. Integrating Network Delay with the Service Metrics . . . 14 B.3. Integrating with BGP Route Selection . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Dunbar & Li Expires 9 June 2026 [Page 2] Internet-Draft Metadata Applicability December 2025 1. Introduction The Edge Metadata Path Attribute defined in [I-D.ietf-idr-5g-edge-service-metadata] allows egress routers at edge data centers to advertise edge service related metadata (e.g., availability, preference, delay prediction, and resource status) to ingress routers. CATS (Computing-Aware Traffic Steering) optimizes traffic steering to service instances by considering both network and compute resource state. The CATS WG defines raw and normalized compute/communication/ delay metrics in [I-D.ietf-cats-metric-definition] and describes BGP distribution for service and shared-resource metrics in [I-D.ll-idr-cats-bgp-extension]. This document evaluates how far the existing Edge Metadata mechanisms can carry, approximate, or be extended to support CATS metrics and their operational requirements. 2. Conventions used in this document The following conventions are used in this document. Edge DC: Edge Data Center, which provides the hosting environment for the edge services. An Edge DC might host 5G core functions in addition to the frequently used edge services. gNB: next generation Node B [TS.23.501-3GPP] RTT: Round-trip Time PSA: PDU Session Anchor (UPF) [TS.23.501-3GPP] UE: User Equipment UPF: User Plane Function [TS.23.501-3GPP] This document uses the terms "Service Contact Instance (SCI)", "Service", "Compute Resource", "Shared Resource", and "CATS Metric Levels (L0/L1/L2)" as defined in [I-D.ietf-cats-framework] and [I-D.ietf-cats-metric-definition]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC8174] when, and only when, they appear in all capitals, as shown here. Dunbar & Li Expires 9 June 2026 [Page 3] Internet-Draft Metadata Applicability December 2025 3. Summary of 5G Edge Service Metadata Mechanism 3.1. Attribute Structure The Edge Metadata Path Attribute is an optional, non-transitive BGP Path Attribute consisting of a set of Sub-TLVs. Each Sub-TLV carries one metric or an abstracted value about the running environment or capability of an edge service or its hosting site. The base document defines Sub-TLVs including (but not limited to): Site Preference Index, Site Physical Availability Index, Service Delay Prediction, Raw Measurement, Service-Oriented Capability, and Service-Oriented Available Resource. The attribute is carried with selected service routes, typically anycast service prefixes, and can also be used in standalone UPDATEs for site-wide values. 3.2. High-Level Distribution Behavior Edge Metadata is intended for limited-domain distribution. The attribute is non-transitive and is expected to be filtered at administrative boundaries. Route Reflectors (RRs) can further constrain propagation using NO-ADVERTISE or an in-attribute AS-Scope Sub-TLV. The metadata is propagated in BGP UPDATEs, subject to a minimum advertisement interval (default 30 seconds) to control churn. 3.3. Mapping Sub-TLVs to CATS Metric Categories (Overview) CATS defines metrics at three abstraction levels: L0 (raw resource and network measures), L1 (normalized per-resource-type metrics), and L2 (composite or policy-derived metrics). The 5G Edge Metadata Path Attribute primarily supports L1 and L2-style abstractions, which aligns with the CATS guidance to avoid flooding highly dynamic raw (L0) metrics in BGP. The Sub-TLVs defined in [I-D.ietf-idr-5g-edge-service-metadata] naturally map to CATS metric classes as follows: Service-Oriented Capability -> CATS L1/L2 compute capability: Represents a normalized measure of compute availability for a service or set of instances. Service-Oriented Available Resource -> CATS L1 compute availability: Similar to CPU/memory/storage availability, but abstracted into a comparable index. Dunbar & Li Expires 9 June 2026 [Page 4] Internet-Draft Metadata Applicability December 2025 Service Delay Prediction -> CATS L1 normalized delay or L0 raw delay: Provides a predictive or measured service-instance delay, supporting both raw and normalized forms depending on encoding. Raw Measurement -> CATS L0 telemetry: Byte/packet counters can be used to construct utilization and load factors that feed into higher-level metrics. Site Preference Index -> CATS L2 policy composite: Not a standard CATS metric, but fits naturally into the L2 category used for operator-defined policy overrides. Site Physical Availability Index (SPAI) -> CATS Shared Resource metric: Directly expresses physical-site-level constraints that affect all SCIs hosted at that site. 4. Applicability of 5G Edge Metadata to CATS Metrics The 5G Edge Metadata Path Attribute provides a ready-made container to carry most CATS-defined compute and service metrics, especially those that must be synchronized across ingress nodes for service- instance selection. The mechanisms align with CATS in several dimensions: 4.1. Compute/Resource Capability (CATS L1/L2) The Service-Oriented Capability Sub-TLV is directly usable as a normalized compute capability indicator. It already conforms to the CATS requirement that compute metrics be abstracted and comparable across heterogeneous hardware. 4.2. Compute/Resource Availability (CATS L1) The Available Resource Sub-TLV corresponds to CATS L1 availability metrics such as CPU headroom, memory availability, or accelerator capacity. Where CATS defines a family of resource-type-specific primitives, the 5G mechanism provides a unified normalized format suitable for routing-level decisions. 4.3. Service Processing Delay (CATS L0 or L1) The Service Delay Prediction SubTLV supports both, raw time values (L0), when expressed in milliseconds; and normalized delay scores (L1/L2), when expressed as a 0-100 index. Dunbar & Li Expires 9 June 2026 [Page 5] Internet-Draft Metadata Applicability December 2025 This flexibility matches CATS' need for both precise measurements and abstracted comparative metrics. 4.4. Traffic Load / Utilization (CATS L0-L1/L2 The Raw Measurement Sub-TLV offers input signals for evaluating congestion, load, and resource pressure. These serve as L0 primitives from which CATS-compliant L1 or L2 metrics can be derived. 4.5. Site Preference (CATS L2 policy metric) Although not defined by CATS, the Site Preference Index aligns with the CATS concept of operator-defined L2 composite metrics (e.g., policy-driven affinity, regulatory guidance, cost-based biasing). 4.6. Site Physical Availability (CATS Shared Resource) Site Physical Availability Index (SPAI) Sub-TLV provides a site/pod/row/floor/DC availability percentage that applies to a group of routes sharing the same physical characteristic. This directly aligns with the "Shared Resource" concept in [I.D.ll-idr-cats-bgp- extension], where a single metric update should influence multiple SCIs without per-service replication. The SPAI is naturally suited for use as a CATS Shared Resource metric because it reflects conditions that affect all service instances within the same facility. SPAI represents substrate-level constraints such as power redundancy, cooling capacity, rack/row availability, and environmental health - factors that are not tied to any individual service instance. When the physical state of a site changes, all hosted services are simultaneously impacted, meaning a single SPAI update conveys a facility wide condition without requiring per-service updates. This behavior matches the CATS Shared Resource semantics defined in [I-D.ll-idr-cats-bgp-extension], which aims to avoid churn by enabling one update to apply to many SCIs. SPAI's value is also normalized and abstracted (0-100), satisfying CATS's preference for L1/L2 metrics that can be compared uniformly across egress nodes. Additionally, SPAI is disseminated using the same limited domain, non-transitive BGP propagation model recommended for CATS, without requiring new identifiers or mapping constructs because the site itself serves as the implicit shared resource boundary. Dunbar & Li Expires 9 June 2026 [Page 6] Internet-Draft Metadata Applicability December 2025 Therefore, SPAI can be used directly as a Shared Resource metric in CATS deployments, helping reduce protocol overhead, avoiding per service metric replication, and improving responsiveness to physical site level events. 4.7. Expressiveness, Granularity, Update Semantics CATS recommends distributing normalized L1/L2 metrics due to their stability and comparability. The 5G Edge Metadata model already restricts itself to abstracted values, with raw L0 metrics not directly exposed except through Raw Measurement. Thus, the overall expressiveness aligns well with CATS' guidance and operational constraints. 5. Distribution Model and Leakage Prevention 6. Metric Lifetimes The Edge Metadata model uses BGP UPDATE propagation, with default minimum advertisement interval of 30 seconds in iBGP domains. This is consistent with typical CATS control plane expectations for "moderately dynamic" metrics (seconds-to-minutes scale), but may be insufficient for highly bursty L0 measurements unless operators apply dampening and aggregation. For L2-style normalized values (capability/availability/delay prediction), BGP timeliness is generally adequate in a limited domain where topology diameter is small. For raw L0-style signals (if added later), asynchronous collection and local aggregation before BGP export is RECOMMENDED. 7. Granularity Semantics Issues CATS separates metrics by scope: per-SCI (service instance), per- service (aggregate over instances), per-site, and shared-resource. The Edge Metadata mechanisms currently mix these scopes: * Service-Oriented Capability and Available Resource are per-service at a site (implicitly per-service aggregate over instances). * Service Delay Prediction is per-service at a site, but can represent either a normalized score or raw time; consistent semantic interpretation across ingress nodes is required. Dunbar & Li Expires 9 June 2026 [Page 7] Internet-Draft Metadata Applicability December 2025 * Site Physical Availability Index is per-site or shared-resource and supports standalone updates. This matches CATS shared resource needs. * Raw Measurement is per-service route signal, not a standardized CATS L0 set. If CATS requires explicit per-SCI differentiation (e.g., for multiple instances behind one anycast service prefix), the 5G Edge Metadata encoding needs augmentation to carry an instance identifier or to bind distinct metrics to distinct NLRIs. 8. Scalability and Churn Considerations The 5G Edge Metadata draft deliberately limits scope to a small subset of services in a limited domain, and applies a minimum advertisement interval to avoid route churn. This is aligned with CATS concerns about frequent metric updates causing cascading BGP UPDATEs. Operators SHOULD: * Prefer L1/L2 normalized metrics for distribution. * Aggregate L0 signals locally and export only on meaningful change. * Use shared-resource/site-wide updates (e.g., Site Physical Availability Index) whenever possible. In large deployments with many services per site, the per-service Sub-TLV updates could still create noticeable churn. Mapping to the generic CATS BGP metric container may reduce the need for new Sub-TLV types and simplify extensibility. 9. Gaps and Extensions Needed for CATS Compliance The following additions would allow the 5G Edge Metadata mechanisms to serve as a fully compliant CATS metric container: Per-SCI Differentiation: Add an Instance-ID field or tie individual metric Sub-TLVs to distinct NLRIs so ingress routers can distinguish metrics for different service instances behind an anycast prefix. Explicit Resource-Type Identification (for L0->L1 transitions): CATS defines specific raw metrics (CPU load, GPU usage, memory pressure). Adding optional resource-type enumerations would allow Raw Measurement or Capability TLVs to expose more structured CATS L0 primitives when needed. Dunbar & Li Expires 9 June 2026 [Page 8] Internet-Draft Metadata Applicability December 2025 Metric Lifetime / Validity Interval: CATS defines explicit metric- freshness semantics. The 5G Edge Metadata mechanism can be extended with: TTL or "valid until" timestamps, change-threshold indicators, or explicit "stale" flags. Scope Identifier for Shared Resource Metrics: Allow SPAI-like metrics to reference a named resource pool (e.g., "DC-Room-A", "GPU-Cluster-2") when a site contains multiple independent shared resources. Support for More Dynamic Metric Classes: For highly dynamic CATS L0 metrics, support for sub-second updates is generally not appropriate in BGP. Guidance should mandate local smoothing/ aggregation before exporting updates into the control plane. 10. Security Considerations This document does not introduce new security mechanisms beyond those in [I-D.ietf-idr-5g-edge-service-metadata] and [I-D.ll-idr-cats-bgp-extension]. Operators MUST ensure metadata remains within the trusted limited domain, and SHOULD apply policy- based filtering and AS-scope controls. 11. IANA Considerations This document makes no IANA requests. 12. Contributors 13. Acknowledgements 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, . Dunbar & Li Expires 9 June 2026 [Page 9] Internet-Draft Metadata Applicability December 2025 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, . [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, . [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, August 2008, . [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, . [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, . [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Dunbar & Li Expires 9 June 2026 [Page 10] Internet-Draft Metadata Applicability December 2025 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, . [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, April 2021, . 14.2. Informative References [I-D.ietf-cats-framework] C. Li, et al, "A Framework for Computing-Aware Traffic Steering (CATS)", November 2025, . [I-D.ietf-cats-metric-definition] C. Li, et al, "CATS Metrics Definition", October 2025, . [I-D.ietf-idr-5g-edge-service-metadata] L. Dunbar, et al, "BGP Extension for 5G Edge Service Metadata", September 2025, . [I-D.ll-idr-cats-bgp-extension] C. Li and P. Liu, "CATS BGP Extension", October 2025, . [IANA-BGP-PARAMS] IANA, "BGP Path Attributes", BGP Path Attributes https://www.iana.org/assignments/bgp-parameters/. [RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing Domains: A model for routing in the Internet", RFC 1136, DOI 10.17487/RFC1136, December 1989, . [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, . Dunbar & Li Expires 9 June 2026 [Page 11] Internet-Draft Metadata Applicability December 2025 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . [TS.23.501-3GPP] 3rd Generation Partnership Project (3GPP), "System Architecture for 5G System; Stage 2, 3GPP TS 23.501 v2.0.1", December 2017. Appendix A. Service Delay Prediction Based on Load Measurement When data centers detailed running status are not exposed to the network operator, historic traffic patterns through the egress routers can be utilized to predict the load to a specific service. For example, when traffic volume to one service at one data center suddenly increases a huge percentage compared with the past 24 hours average, it is likely caused by a larger than normal demand for the service. When this happens, another data center with lower-than- average traffic volume for the same service might have a shorter processing time for the same service. Here are some measurements that can be utilized to derive the Service Delay Predication for a service ID: - Total number of packets to the attached service instance (ToPackets); - Total number of packets from the attached service instance (FromPackets); - Total number of bytes to the attached service instance (ToBytes); - Total number of bytes from the attached service instance (FromBytes); - The actual load measurement to the service instance attached to an egress router can be based on one of the metrics above or including all four metrics with different weights applied to each, such as: LoadIndex = w1*ToPackets+w2*FromPackes+w3*ToBytes+w4*FromBytes Where w1/w2/w3/w4 are between 0-1. w1+ w2+ w3+ w4 = 1; Dunbar & Li Expires 9 June 2026 [Page 12] Internet-Draft Metadata Applicability December 2025 The weights of each metric contributing to the index of the service instance attached to an egress router can be configured or learned by self-adjusting based on user feedbacks. The Service Delay Prediction Index can be derived from LoadIndex/24Hour-Average. A higher value means a longer delay prediction. The egress router can use the ServiceDelayPred sub-TLV to indicate to the ingress routers of the delay prediction derived from the traffic pattern. Note: The proposed IP layer load measurement is only an estimate based on the amount of traffic through the egress router, which might not truly reflect the load of the servers attached to the egress routers. They are listed here only for some special deployments where those metrics are helpful to the ingress routers in selecting the optimal paths. Appendix B. Service Metadata Influenced Decision Process B.1. Egress Router Behavior Multiple instances of the same service could be attached to one egress router. When all instances of the same service are grouped behind one application layer load balancer, they appear as one single route to the egress router, i.e., the application loader balancer's prefix. Under this scenario, the compute metrics for all those instances behind one application layer balancer are aggregated under the application load balancer's prefix. In this case, the compute metrics aggregated by the Load Balancer are visible to the egress router as associated with the Load Balancer's prefix. However, how the application layer Load Balancers distribute the traffic among different instances is out of the scope of this document. When multiple instances of the same service have different paths or links reachable from the egress router, multiple groups of metrics from respective paths could be exposed to the egress router. The egress router can have preconfigured policies on aggregating various metrics from different paths and the corresponding policies in selecting a path for forwarding the packets received from ingress routers. The aggregated metrics can be carried in the BGP UPDATE messages instead of detailed measurements to reduce the entries advertised by the control plane and dampen the routes update in the forwarding plane. Upon receiving packets from ingress routers, the egress router can use its policies to choose an optimal path to one service instance. It is out of the scope of this document how the measurements are aggregated on egress routers and how ingress routers are configured with the algorithms to integrate the aggregated metrics with network layer metrics. Dunbar & Li Expires 9 June 2026 [Page 13] Internet-Draft Metadata Applicability December 2025 Many measurements could impact and correspondingly reflect service performance. In order to simplify an optimal selection process, egress routers can have preconfigured policies or algorithms to aggregate multiple metrics into one simple one to ingress routers. Though out of the scope of this document, an egress router can also have an algorithm to convert multiple metrics to network metrics, an IGP cost for each instance, to pass to ingress nodes. This decision- making process integrates network metrics computed by traditional IGP/BGP and the service delay metrics from egress routers to achieve a well-informed and adaptive routing approach. This intelligent orchestration at the edge enhances the service's overall performance and optimizes resource utilization across the distributed infrastructure. When the egress has merged the compute metrics from the local sites behind it, it can include one or more aggregated compute metrics in the Metadata Path Attribute in the BGP UPDATE to the Ingress. Also, an identifier or flag can be carried to indicate that the metrics are merged ones. After receiving the routes for the Service ID with the identifier, the ingress would do the route selection based on pre-configured algorithms (see Section 3 of this document). B.2. Integrating Network Delay with the Service Metrics As the service metrics and network delays are in different units, here is an exemplary algorithm for an ingress router to compare the cost to reach the service instances at Site-i or Site-j. ServD-i * CP-j Pref-j * NetD-i Cost-i=min(w *(----------------) + (1-w) *(------------------)) ServD-j * CP-i Pref-i * NetD-j CP-i: Capacity Availability Index at Site-i. A higher value means higher capacity available. NetD-i: Network latency measurement (RTT) to the Egress Router at the site-i. Pref-i: Preference Index for Site-i, a higher value means higher preference. ServD-i: Service Delay Predication Index at Site-i for the service, i.e., the ANYCAST address [RFC4786] for the service. w: Weight is a value between 0 and 1. If smaller than 0.5, Network latency and the site Preference have more influence; otherwise, Service Delay and capacity availability have more influence. Dunbar & Li Expires 9 June 2026 [Page 14] Internet-Draft Metadata Applicability December 2025 When a set of service Metadata is converted to a simple metric, a decision process is determined by the metric semantics and deployment situations. The goal is to integrate the conventional network decision process with the service Metadata into a unified decision- making process for path selection. B.3. Integrating with BGP Route Selection Not all metadata attributes specified in this document are intended for use in every deployment. Each deployment may choose to consider only a subset of the available metadata attributes based on its specific service requirements. - Deployment-Specific Attribute Selection: A deployment may prioritize only certain metadata attributes relevant to its operational needs. For example, one deployment might only use the Service Delay Prediction Index for latency-sensitive applications, while another might focus solely on the Capacity Availability Index to manage resource availability. - Influence on BGP Decision Process: The edge service Metadata influences next-hop selection differently from traditional BGP metrics (e.g., Local Preference, MED). Unlike a general next-hop metric that can affect many routes, edge service Metadata selectively impacts optimal next-hop selection for specific routes configured to consider these service-specific attributes. This targeted influence allows for optimized path selection without disrupting broader route decisions. - Handling Degraded Metrics (Policy-Based): If a service-specific metric degrades beyond a configured threshold (e.g., the Service Delay Prediction Index exceeds an acceptable delay threshold or the Capacity Availability Index drops below a required level), the ingress router will treat that route as ineligible for traffic steering. This is similar to a BGP route withdrawal, where the degraded route is deprioritized or ignored, even if traditional BGP attributes would otherwise favor it. This ensures that traffic is directed only to service instances that meet the defined performance criteria. - Fallback to Non-Metadata Routes: Dunbar & Li Expires 9 June 2026 [Page 15] Internet-Draft Metadata Applicability December 2025 If no suitable routes with the required metadata are available, the BGP decision process defaults to traditional attribute evaluation [RFC4271], ensuring consistent routing even when metadata-specific paths are absent. This approach provides flexibility and adaptability in routing decisions, allowing each deployment to apply relevant metadata attributes and enforce performance thresholds for improved service quality. Authors' Addresses Linda Dunbar Futurewei Dallas, TX, United States of America Email: ldunbar@futurewei.com Cheng Li Huawei Technologies Beijing China Email: c.l@huawei.com Dunbar & Li Expires 9 June 2026 [Page 16]