| Internet-Draft | Using BGP EPE Control Plane for computin | July 2023 |
| Liu | Expires 11 January 2024 | [Page] |
This document describes an approach for using the BGP EPE Control Plane [RFC8670] for CATS cross as domain steering traffic based on a normalized metric that reflect the underlying network conditions and other service-specific metrics collected from available service locations.¶
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 11 January 2024.¶
Copyright (c) 2023 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 (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.¶
BGP (Border Gateway Protocol) is a dynamic routing protocol between autonomous system AS (Autonomous System). The BGP EPE function is an extension of BGP to Segment Routing to implement source routing between AS.¶
Enabling BGP EPE?egress peer engineering [RFC8670], BGP Peer SID can be assigned to inter-domain paths and Peer SID can be passed to the network controller via BGP-LS extension. Through the rational arrangement of IGP SID and BGP Peer SID, the controller can realize the optimal path forwarding across the domain.¶
In addition to the Peer Node and Peer Adjacency, there is also the Peer Set. Peer Set That is, a group of neighbors as a Set, and then assign SID based on the group. This SID can also correspond to multiple outgoing interfaces.¶
CATS is about finding an optimal service path for arrange a service request, and thus about selecting one of the available service instances that better optimize a set of metrics . The document focuses on multiple AS domains traffic engineering .¶
This document makes use of the following terms:¶
The goal of the proposed BGP extension is to distribute the metrics collected by C-SMAs (CATS Service Metric Agents) to the CATS SDN controller(centrial framwork) or ingress routers(distribued framwork) to be used by the corresponding CATS Path Selectors . In this document, We mainly propose a multi-domain centralized computing force routing implementation scheme, combined with BGP EPE technology to realize cats multi-domain traffic scheduling.¶
The detailed metrics collected by a C-SMA will be decided by the CATS WG . And the encoding of the CATS metrics that will be selected by the WG will be discussed in IDR WG . When a CATS ingress router receives metrics updates for a Service ID from multiple CATS egress routers, all those egress routers are considered as the next hops for that Service ID . The Service ID is represented as an IPv4/IPv6 unicast address, which is assigned to a group of interfaces to which the service instances are attached .¶
The CATS ingress router's BGP engine will send this metric to SDN controller by BGP-LS protocol. According to the collected computing power resource information and network information, the SDN controller generates an end-to-end segmentID list through the computing path algorithm, which is sent to cats ingress through BGP SR policy.¶
As shown in Figure 1, computing service node 1 and node 2 are cloud resource pools, which can provide computing power resource services. The main functions of the computing power agent(C-SMA) module are as follows:¶
Use restful protocol to collect the computing information of computing service nodes. The computing information includes CPU utilization, memory utilization, GPU utilization, storage capacity, DPU utilization, energy efficiency of computing power nodes, etc.¶
The computing power agent module normalized the collected computing information(metric) by PageRank algorithm to generate the comprehensive computing power index metric. The larger the metric, the more preferred.¶
Computing power information notification, as shown in Figure R11, R12, as the exit router of computing power agent module, needs to have BGP routing protocol capability. R9, R11, R 11 and R12 should establish BGP neighbors respectively. The BGP update message passes the above normalized metric value to R9 and R10.¶
+---------+
| R12 |
+---------------+ +-----------------+ +------------+ | |
| SDN | | R8 | | | | C-SMA|
| | | | | | +---------+
| R2 | | | | R10 |
| | | R4 R6 | | |
| | | AS3 | | |
| R1 | +-----------------+ | |
| | | |
| | +----------------+ | |
| R3 | | | | |
| | | | | |
| | | R5 R7 | | R9 |
| | | | | | +----------+
| AS1 | | AS2 | | AS4 | | R11 |
+---------------+ +----------------+ +------------+ | |
| C-SMA|
+----------+
|
As shown in FIG. 1, the router R9 and R10 of AS4 receive the computing information(metric) distributed by the R9 to its? all peers.(the process flow of R9 is same R10, we use R9 for example in following).The R9 as the export router of AS4 domain would to be assigned a BGP prefix SID [RFC8669], while enabling BGP LU address family(BGP label unicast address family). routers establishing IBGP peers within inter-domain, and intra-domain establishing EBGP peers . By extending the BGP update message that add a new BGP attribute indicates the metric of the computing resource pool hanging under the egress router. R1 can receive the BGP prefix-SID of R9 through the message interaction between bgp peers. Finally, the metric will be sent to SDN controller.¶
Enabling BGP EPE[RFC7855] function on egress routers of each As domain. After the device starts the EPE function, BGP peer SID will be automatically assigned, and the SDN controller in the domain will collect Peer SID, all BGP routes,the network information, the topology information, the information from the EPE function in the domain, and the metric which distributed by C-SMA of CATS.¶
According to the business needs, the controller determines the last jump of the egress equipment of the computing resource pool that meets the computing requirements to generate SID-LIST. The controller sends the SID-LIST to the forwarding entry device(ingress device, R1 in Fig.1) through the border gateway protocol or the PCEP protocol. Finally, in the cross-domain scenario, the appropriate service center can be determined according to the computing information(metirc), and at the same time, the traditional BGP based on the shortest path selection, realizing the cross-domain computing network traffic engineering.¶
As the metrics change can triger bgp provider send update message to peer, the bgp route table may changed, and impact the path selection. The route update interval was fifteen seconds for the IBGP peer, and thirty seconds for the EBGP peer. The Minimum Interval for Metrics Change Advertisement is configured to control the bgp message update frequency to avoid bgp route oscillations . The minmun interval is set equal or greater than bgp route fresh interval in best .¶
The Edge Service Metadata described in this document are only intended for propagating between Ingress and egress routers of one single BGP domain . Only the selective services by clients are considered as CATS Services, which are managed by one operator, even though the routers can be by different vendors.¶
BGP EPE CATS needs to follow the spring architecture[RFC7855], and be consistent with the spring architecture?s security considerations.¶
In the current IANA definition, the number 41 to 127 are unused. The type value (Type Code) of the computing-aware routing attribute is defined as optional transitive, and the normalized metric attribute type value is temporarily set to 127.¶
TBD.¶