IDR C. Lin Internet Draft New H3C Technologies Intended status: Standards Track H. Yao Expires: September 3, 2024 China Mobile March 4, 2024 Distribute Service Metric By BGP draft-lin-idr-distribute-service-metric-00 Abstract When calculating the path selection for service traffic, it is important to consider not only network metrics, but also the impact of service Metric. Therefore, it is necessary to transmit service Metric information from the server site to the user access site, in order to facilitate path selection for service traffic at the access router. This document describes an approach for using the BGP Control Plane to steer traffic based on a set of metrics that reflect the underlying network conditions and other service-specific state collected from available service locations. 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 September 3, 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 XXX, et al. Expires September 3, 2024 [Page 1] Internet-Draft Distribute Service Metric By BGP March 2024 respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................3 1.1. Conventions and Terminology...............................3 1.2. Gap.......................................................4 1.3. Overview..................................................4 1.4. Registration and Subscription for Service Metric..........7 2. BGP Service Metric Routes .....................................8 2.1. The Service Metric Register NLRI..........................9 2.2. The Service Metric Subscribe NLRI........................10 2.3. The Service Metric Subscribe Option Extended Community...10 2.4. The Service Metric Update NLRI...........................11 2.5. The Service Metric Location Extended Community...........11 2.6. The Service Metric Metric Extended Community.............12 2.7. The Service Metric Raw Metric Extended Community.........13 2.8. The Service Metric Priority Extended Community...........14 3. Example.......................................................14 4. Security Considerations.......................................16 5. IANA Considerations...........................................16 5.1. Service Metric AFI.......................................16 5.2. Service Metric TLV.......................................16 6. References....................................................17 6.1. Normative References.....................................17 Authors' Addresses...............................................18 Lin, et al. Expires September, 2024 [Page 2] Internet-Draft Distribute Service Metric By BGP March 2024 1. Introduction In scenarios such as edge services and CATS services, service instances are deployed across multiple geographically distributed sites to achieve better response times. When selecting a path for service traffic, it is important to consider not only network metrics but also the operational status of the servers, which includes CPU utilization, service queue length, memory usage, and other factors. These operational statuses of the servers are abstracted as service metrics, allowing service requests to be directed to the optimal service instance based on both network metrics and service metrics. Due to the rapid changes in server operational status, it is necessary for the server side to frequently send update messages regarding its operational status to the user side. Typically, the update frequency ranges from 1 to 5 minutes. In scenarios with a large number of services, frequent updates of service metrics for each service instance can consume a significant amount of network bandwidth. This document describes a service metric distribution framework based on the BGP protocol, which is designed to support the registration, subscription, and updating of service metrics. 1.1. Conventions and Terminology 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Service Metric Routing: Service Metric Routing Ingress Forwarder: Ingress GateWay Egress Forwarder: Egress GateWay Publisher Service Metric Route Publisher Subscriber Service Metric Route Subscriber S-ID: Service ID, can be an integer, IPv4, or IPv6 address. SI-ID: Service Instance ID Lin, et al. Expires September, 2024 [Page 3] Internet-Draft Distribute Service Metric By BGP March 2024 1.2. Gap The process of Service Metric routing involves Egress Forwarder collecting service metric information and notifying it to Ingress Forwarder. When Ingress Forwarder needs to forward service traffic, it selects the optimal path for forwarding based on the network metric and service metric information. Due to the frequent changes in service metrics, the Egress Forwarder needs to periodically notify the Ingress Forwarder of updates to the service metrics. In the current implementation, BGP utilizes existing IPv4 and IPv6 address families to distribute service metric routes. Consequently, if there are nodes that do not wish to pay attention to Service Metric Routing, additional filtering methods are required to prevent the potential impact on the efficiency of other routes processing. Alternatively, there is a current proposal to use the Service Metric address family to propagate Service Metric routing(Service Metric Routing). The advantage of using a separate Service Metric address family is that routers not involved in service traffic processing are unaffected by Service Metric routing, as they do not pay attention to Service Metric address family routes. Furthermore, when the Ingress Forwarder router has not yet received service traffic, periodic updates of Service Metric routing are unnecessary. This document presents a registration/subscription mechanism for Service Metric routing, ensuring that subscription to the corresponding Service Metric routing is only required when handling the respective service traffic. In this scenario, for environments supporting multiple services simultaneously, the Ingress router only needs to focus on the Service Metric routing related to the services it handles. This approach significantly reduces the burden on the Ingress server. 1.3. Overview For Service Metric routers, each service needs to be mapped to a service ID to differentiate between different services, called S-ID. The S-ID can be an IPv4 address, an IPv6 address, or more abstractly, an integer. To differentiate between different servers for the same service, each server is assigned a service instance ID, called SI-ID. When S-ID is used as an IPv4 or IPv6 address, it corresponds to the Anycast mode. The advantage of using Anycast mode is that it can Lin, et al. Expires September, 2024 [Page 4] Internet-Draft Distribute Service Metric By BGP March 2024 leverage the existing routing and forwarding infrastructure. However, the drawback is that it can impact non-Service Metric routing, as all routers have to process Anycast routes. Therefore, we consider adopting a more general approach, which is to use a universal S-ID instead of IPv4/IPv6 addresses. The mapping from service characteristics to S-ID is announced by the egress router. The Ingress Forwarder stores the mapping relationship and maps the received service traffic to the corresponding service S-ID according to the mapping relationship. Service characteristics can include protocol type, service port number, TOS type, and so on. The function of announcing the mapping of service characteristics to S-ID by the egress router can be abstracted into a module: Publisher. To facilitate the filtering of Service Metric routes by nodes that do not concern Service Metric routing, considering the characteristic of frequent updates in Service Metric routing, this document defines a new BGP address family called Service Metric address family, which leverages the characteristic of frequent updates in Service Metric routing. The Ingress Forwarder receives the service mapping announcement sent by the Publisher and saves the corresponding service mapping. In order to further reduce the bandwidth consumed by Service Metric routes, a subscription mechanism is introduced. If it needs to pay attention to the service metric information, it sends a subscription for service metrics to the Publisher. Here, we abstract a new module called Subscriber. The Publisher first sends a service registration route to notify the Ingress Forwarder about the existence of Service Metric routes. If the Ingress server needs to subscribe to the service metric information, it acts as a Subscriber and sends a subscription for service metrics to the Publisher. On the contrary, if the Ingress server hasn't received any traffic related to the service yet, it doesn't need to pay attention to the service metrics at the moment. Subsequently, The Publisher receives the service metric subscription sent by the Subscriber, records the subscription status, and sends service metric updates to the Subscriber. In general, the Subscriber only needs to send subscription routes to request service metric information when it receives service requests related to the specific service. However, for simplification purposes, the Subscriber can also choose not to use the subscription Lin, et al. Expires September, 2024 [Page 5] Internet-Draft Distribute Service Metric By BGP March 2024 mechanism and directly send subscription routes to request service metric information upon receiving registered routes. Sending a subscription message without any service traffic can improve the response speed when the service traffic is first received. However, the downside is that it increases the load on the Ingress server. The specific usage scenario needs to be assessed based on whether priority is given to the response speed to service requests or to reducing the load on the Ingress server. This can also be determined based on the characteristics of each service. For example, for services with higher real-time requirements, immediate subscription can be adopted, while other services can use on-demand subscription. The specific processing steps are as follows: +------------+ +-----------+ |Subscriber | | Publisher | +----+-------+ +-------+---+ |<---1)Type 1: Register Route--------| 2)Service Request--->| | |----3)Type 2: Subscribe Route------>| |<---4)Type 3: Update Route----------| |<---5)Type 3: period Update Route---| Figure 1: BGP Service Metric Route Process 1) The Publisher gathers service information and sends a Register Route to the Subscriber to identify the service characteristics and map the corresponding service to an S-ID (Service ID). The specific format of registration routes is shown in Section 2.1. If the Subscriber chooses not to use the On-Demand subscription mechanism, it skips the 2) step and proceeds directly to the 3) step upon receiving registered routes. 2) When the Subscriber receives a service request, it checks if it matches the service characteristics specified in the previously received registered routes. If there is a match, it associates the request with the corresponding service type, as 3). 3) Subscriber sends a Subscribe Route to subscribe the service metric information. The format of the subscription message is shown in Section 2.2. 4) Upon receiving the subscription route, the Publisher sends an Update Route to notify the service metric information. The Update Route format is as shown in Section 2.4. In the case of multiple registrants, the Subscriber needs to send subscription messages to Lin, et al. Expires September, 2024 [Page 6] Internet-Draft Distribute Service Metric By BGP March 2024 all registrants, and after receiving the Update Route from each Publisher site, it selects the optimal route to guide the Service Metric route forwarding. 5) Thereafter, the Publisher periodically sends Update Routes to update the service metric information when it changes. 1.4. Registration and Subscription for Service Metric ServiceCapTable +--------+ |S-ID | |Protocol|... |Port | +----+---+ | Register-Table(Type 1 Route) | +--------+ +--------+ +--------+RD1 +----+RD2 |... | +--------+ +--------+ | | Subscrib-Table(Type 2 Route) | +--------+ +--------+ +--------+RD3 +----+RD4 |... | +--------+ +--------+ | | ServiceMetricTable(Type 3 Route) | +-----------+ +-----------+ | |RD1 | |RD2 | | |SI-ID1 | |SI-ID2 | +--------+ServerAddr1+----+ServerAddr2|... | |Metric | |Metric | | +-----------+ +-----------+ Figure 2: Registration and Subscription For each service type, maintain a Service Capability Table that records the S-ID, protocol type, and service port number for each service. When Publisher establishing a new BGP neighbor, the Type 1 register routes is advertised to the neighbor to notify them of the service metric and the associated S-ID of the service. When Subscriber receives registered routes, it maintains a service information table based on the S-ID. If local on-demand subscription is required, the Subscriber only sends subscribed routes to the Publisher to request service metric information when it receives a local service request. Otherwise, it Lin, et al. Expires September, 2024 [Page 7] Internet-Draft Distribute Service Metric By BGP March 2024 directly sends subscribed routes to request service metric information. Upon receiving Type 2 subscribed routes from Scriber, Publisher sends Type 3 updated routes to the subscriber to update the service metric information, and the subscriber of this service is recorded for future use in sending updated routes based on this information. When the service metric information changes afterwards, Publisher sends Type 3 updated routes to the Subscriber based on the Subscrib- Table. The service metric information is stored as Service Metric Tables and published via Type 3 routes. During publication, it is only sent to subscribers. Subscriber information is stored in the Subscription Table. To avoid frequent updates of service metric information, the updated routes are sent based on the minimum refresh time. 2. BGP Service Metric Routes This document defines a new BGP Network Layer Reachability Information (NLRI) called the Service Metric NLRI. The format of the Service Metric NLRI is as follows: +-----------------------------------+ | Route Type (1 octet) | +-----------------------------------+ | Length (1 octet) | +-----------------------------------+ | Route Type specific (variable) | +-----------------------------------+ The Route Type field defines the encoding of the rest of the Service Metric NLRI (Route Type specific Service Metric NLRI). The Length field indicates the length in octets of the Route Type specific field of the Service Metric NLRI. This document defines the following Route Types: + 1 - Service Metric Register route Lin, et al. Expires September, 2024 [Page 8] Internet-Draft Distribute Service Metric By BGP March 2024 + 2 - Service Metric Subscribe route + 3 - Service Metric Update route The detailed encoding and procedures for these route types are described in subsequent sections. The Service Metric NLRI is carried in BGP [RFC4271] using BGP Multiprotocol Extensions [RFC4760] with an AFI of TBD and an SAFI of Service Metric (To be assigned by IANA). The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the Service Metric NLRI (encoded as specified above). 2.1. The Service Metric Register NLRI A Service Metric Register route type specific Service Metric NLRI consists of the following: +---------------------------------------+ | RD (8 octets) | +---------------------------------------+ | S-ID (Variable) | +---------------------------------------+ | Protocol (2 octets) | +---------------------------------------+ | Service-Port (2 octets) | +---------------------------------------+ The Publisher utilizes Service Metric Register messages to register service characteristics and their associated S-ID. Subscriber that are interested in this service can subscribe to the service metric information of this service. S-ID: includes a 1-byte type field and a variable-length field. Type: 1 Byte, indicates the type of S-ID. 1 the S-ID type is a 4-byte unsigned integer. 2: the S-ID type is a IPv4 address 3: the S-ID type is a IPv6 address Lin, et al. Expires September, 2024 [Page 9] Internet-Draft Distribute Service Metric By BGP March 2024 2.2. The Service Metric Subscribe NLRI A Service Metric Subscribe route type specific Service Metric NLRI consists of the following: +---------------------------------------+ | RD (8 octets) | +---------------------------------------+ | S-ID (Variable) | +---------------------------------------+ There are two instances in which an Subscriber sends a Subscribe message. The first is when on-demand subscription is supported and local service metric information for a requested service is not available. In this scenario, the Subscriber sends a Subscribe message to Publisher based on the registration message in order to request the corresponding service metric information from the Publisher. The second instance is when on-demand subscription is not supported. In this scenario, upon receiving a registration message from the Publisher, the Subscriber immediately sends a Subscribe message to request the corresponding service metric information. Subscribe routing can include Subscribe Option extended community. 2.3. The Service Metric Subscribe Option Extended Community This Extended Community is a new transitive Extended Community having a Type field value of Service Metric (TBD) and the Sub-Type 0x01. It may be advertised along with Service Metric Subscribe routes. Service Metric Subscribe Option extended community is encoded as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(TBD) | Sub-Type=0x01 | Subscribe-Option(2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD, 1 octet. Sub-Type: 0x01, 1octet. Subscribe-Option: 2 octets. Lin, et al. Expires September, 2024 [Page 10] Internet-Draft Distribute Service Metric By BGP March 2024 * 0x01: AggBit, Support for site routing aggregation. * 0x02: RawBit, Requesting raw metric information. 2.4. The Service Metric Update NLRI A Service Metric Update route type specific Service Metric NLRI consists of the following: +---------------------------------------+ | RD (8 octets) | +---------------------------------------+ | S-ID (Variable) | +---------------------------------------+ | SI-ID (4 octets) | +---------------------------------------+ When the Publisher receives a Service Metric subscribe message for the first time, it sends an Update message to the Subscriber to notify the update of service metric information. Subsequently, if there are any changes in the service metric information, an Update message is sent to the subscribers to notify the update of service metric information. To avoid frequent updates of service metric, it is necessary to have a last update period to control the minimum interval for updating the service metric of a specified service. Service Metric Update routing can include Location extended community, metric extended community, Raw metric extended community, and Priority extended community. 2.5. The Service Metric Location Extended Community This Extended Community is a new transitive Extended Community having a Type field value of Service Metric (TBD) and the Sub-Type 0x01. It may be advertised along with Service Metric Update routes. Service Metric Location extended community is encoded as follows: Lin, et al. Expires September, 2024 [Page 11] Internet-Draft Distribute Service Metric By BGP March 2024 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(TBD) | Sub-Type=0x02 | LocationType | ServerAddrType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Location... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ServerAddr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD, 1 octet. Sub-Type: 0x02, 1octet. LocationType: 1 octet, * 0x01: Locationtion is IPv4 address(4 octets); * 0x02: Location is IPv6 address(16 octets); * 0x03: mpls label(4 octets); * 0x04: SRv6 SID(16 octets); ServerAddrType: 0x01: ServerAddr is IPv4 address(4 octets); 0x02: ServerAddr is IPv6 address(16 octets); Location: The specific content depends on the LocationType. ServerAddr: The specific content depends on the ServerAddrType. 2.6. The Service Metric Metric Extended Community This Extended Community is a new transitive Extended Community having a Type field value of Service Metric (TBD) and the Sub-Type 0x03. It may be advertised along with Service Metric Update routes. Service Metric Metric extended community is encoded as follows: Lin, et al. Expires September, 2024 [Page 12] Internet-Draft Distribute Service Metric By BGP March 2024 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(TBD) | Sub-Type=0x03 | Reserved=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MaxMetric(4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MinMetric(4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AverageMetric(4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD, 1 octet. Sub-Type: 0x03, 1octet. MaxMetric: 4 octet, Max Metric MinMetric: 4 octet, Min Metric AverageMetric: 4 octet, Average Metric 2.7. The Service Metric Raw Metric Extended Community This Extended Community is a new transitive Extended Community having a Type field value of Service Metric (TBD) and the Sub-Type 0x04. It may be advertised along with Service Metric Update routes. Service Metric Raw Metric extended community is encoded as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(TBD) | Sub-Type=0x04 | Reserved=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | total number of Received packets(4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | total number of Send packets(4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | total number of Received bytes(4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | total number of send bytes(4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD, 1 octet. Lin, et al. Expires September, 2024 [Page 13] Internet-Draft Distribute Service Metric By BGP March 2024 Sub-Type: 0x03, 1octet. total number of Received packets: 4 octet total number of Send packets: 4 octet total number of Received bytes: 4 octets total number of send bytes: 4 octets 2.8. The Service Metric Priority Extended Community This Extended Community is a new transitive Extended Community having a Type field value of Service Metric (TBD) and the Sub-Type 0x05. It may be advertised along with Service Metric Update routes. Service Metric Priority extended community is encoded as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(TBD) | Sub-Type=0x05 | Priority | Affinity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD, 1 octet. Sub-Type: 0x05, 1octet. Priority: 1 octet, Priority of the server Affinity: 1 octet, Affinity of the server 3. Example Host------Scriber-----------+--Publisher1 -------Server1 | | (SI-ID 1, Metric) | +------ Server2 | (SI-ID 2, Metric) +--Publisher2 -------Server3 | (SI-ID 3, Metric) +------ Server4 (SI-ID 4, Metric) Figure 3: Service Metric Network Topology Lin, et al. Expires September, 2024 [Page 14] Internet-Draft Distribute Service Metric By BGP March 2024 The host is connected to the Scriber, Server1 and Server2 are connected to Publisher1, while Server3 and Server4 are connected to Publisher2. The following is the process of Scriber and Publisher interacting with BGP for Service Metric routing: 1) Publisher1 sends a Type 1 Registration Route to register the service attributes associated with S-ID 1. The Scriber receives the registration route and maintains the registration information for this service, recording the association between S-ID and service attributes. If the Publisher Forwarder itself does not support on-demand subscription, it directly proceeds to the 3) step and immediately sends Type 2 subscription routes. 2) When the Subscriber Forwarder receives a service request from the Host for the first time, it associates the request with the S-ID based on the service attributes and the maintained registration information. It then proceeds to the 3): sending Type 2 subscription routes to all the registered subscribers of this service. 3) The Subscriber Forwarder sends a Type 2 subscription route to all registered subscribers of this service based on the S-ID, in order to request the measurement information for this service. 4) When the Publisher1 receives the Type 2 subscription routes, it sends the measurement information for this service to subscribers by using Type 3 Update routes. 5) Publisher2 establishes a BGP neighborship with Subscriber and sends Type 1 registration routes to register service characteristics, associating them with S-ID 1. 6) When Subscriber receives new registration routes and if there are already other registrars and service metric tables, it sends subscription routes to the new registrar, requesting new service metric. 7) When there is a change in the service metric, the Publisher1 or Publisher2 sends Type 3 update routes to all subscribers based on the Type 2 subscription routes. Update routes are sent only to the subscribers, which helps in reducing network load. Lin, et al. Expires September, 2024 [Page 15] Internet-Draft Distribute Service Metric By BGP March 2024 8) When Subscriber receives new registration routes and if there are already other registrars and service metric tables, it sends subscription routes to the new registrar, requesting new service metric. 9) When there is no service traffic for a long period of time, the service metric table is aged out, and Subscriber sends withdrawal of Type 2 subscription routes to all registrars. 4. Security Considerations TBD. 5. IANA Considerations 5.1. Service Metric AFI This document requests a code point for Service Metric AFI from the registry of Address Family Numbers. This document requests creation of a new registry for Service Metric Register, Service Metric Subscribe, and Service Metric Update. This document requests a code point from the BGP Path Attributes registry. 5.2. Service Metric TLV IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters" with a subregistry of "BGP Path Attributes". IANA is requested to assigned a new Path attribute called "Service Metric attribute". Value Description Reference ----- --------------- ------------- TBD Service Metric TLV This document Figure 3: Service Metric TLV This document request IANA to created a new subregistry called the "Service Metric Attribute TLVs" registry Lin, et al. Expires September, 2024 [Page 16] Internet-Draft Distribute Service Metric By BGP March 2024 +======+===== ===================+===============| | Type | Name | This document | +======+=========================+===============| | 1 | Subscribe Option TLV | This document | +------+-------------------------+---------------| | 2 | Location TLV | This document | +------+-------------------------+---------------| | 3 | Metric TLV | This document | +------+-------------------------+---------------| | 4 | Raw Metric TLV | This document | +------+-------------------------+---------------+ | 5 | Priority TLV | This document | +------+-------------------------+---------------+ 6. References 6.1. Normative References TBD Lin, et al. Expires September, 2024 [Page 17] Internet-Draft Distribute Service Metric By BGP March 2024 Authors' Addresses Changwang Lin New H3C Technologies China Email: linchangwang.04414@h3c.com Huijuan Yao China Mobile No.32 XuanWuMen West Street Beijing 100053 China Email: yaohuijuan@chinamobile.com Lin, et al. Expires September, 2024 [Page 18]