Distribution of Service Metadata in BGP FlowSpec

Introduction Many modern services deploy their service instances in multiple sites to get better response time and resource utilization. These sites are often geographically distributed to serve the user demand. For some services such as VR/AR and intelligent transportation, the QoE will depend on both the network metrics and the compute metrics. For example, if the nearest site is overloaded due to the demand fluctuation, then steer the user traffic to another light-loaded sites may improve the QoE. To steer the traffic to the best site, the computing metadata of the site needs to be collected. describes the BGP extension of distributing service route with network and computing-related metrics. The router connected to the site will received the service routes and service metadata sent from devices inside the edge site, and then generates the corresponding routes and distributes them to ingress routers. However, the route with service metadata on the router connected to the site can be also collected by a central controller using BGP LS. Then the central controller may process the metadata and distributes the result to the ingress router using BGP FlowSpec. This document defines an extension of BGP FlowSpec to carry the service metadata along with the service route which is received from the controller. Using the service metadata and the service route, the ingress router can calculate the best site for the traffic, giving each user the best QoE.

Terminology

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 BCP 14 when, and only when, they appear in all capitals, as shown here.

BGP FlowSpec Extension for Service Metadata The goal of the BGP FlowSpec extension is to distribute the information of the service route and metadata. A service is identified by an prefix and this information is carried using the existing Destination Prefix Component specified in and . defines that the Color Extended Community and BGP Prefix-SID attribute is carried in the context of the FlowSpec NLRI. In addition to that, this document proposes to carry the service metadata attribute(See ). The ingress router can compare the compute metric of different sites and steer the traffic into the best one using the SR policy. The metadata can be original values defined in or an aggregated one calculated using original values.

Example of using BGP FlowSpec to distribute the service route and metadata ) |Egress|----------| Site | +-------+ (SR List) +------+ +---------+ '--( )--' ( ) '-----' ]]>

Metadata Path Attribute TLV The Metadata Path Attribute TLV is the same as defined in , including the following three sub-TLVs:

Site Preference Index sub-TLV indicates the preference to choose the site.
Capacity Index sub-TLV indicates the capability of a site. One Edge Site can be in full capacity, reduced capacity, or completely out of service.
Load Measurement sub-TLV indicates the load level of the site.

Aggregated Metric Path Attribute TLV The Aggregated Metric Path Attribute is a newly defined TLV(See ). It contains a single aggregated value which is calculated by the controller using the original metrics such as site preference, capacity and load measurement.

Aggregated Metric Path Attribute TLV format

Type: identify the Aggregated Metadata Attribute, to be assigned by IANA.
Length: the total number of the octets of the value field.
Value: value of Aggregated Computing metric.

Security Considerations TBD

IANA Considerations This document requires IANA to assign the following code points from the registry called "BGP Path Attributes":

Value	Description	Reference
TBD1	Aggregated Metadata Type