<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->
<?rfc compact="yes"?>
<?rfc text-list-symbols="o*+-"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="no"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-liu-cats-bgp-epe-applicability-00" ipr="trust200902" submissionType="IETF" obsoletes="" updates="" xml:lang="en" sortRefs="false" symRefs="true" tocInclude="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.17.4 -->
  <front>
    <title abbrev="Using BGP EPE Control Plane for CATS">Using BGP EPE
    Control Plane for CATS</title>
    <seriesInfo name="Internet-Draft" value="draft-liu-cats-bgp-epe-applicability-00"/>
    <author fullname="Xingsheng Liu" initials="X." surname="Liu">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <street>No.32 XuanWuMen West Street</street>
          <city>Beijing</city>
          <code>100053</code>
          <country>China</country>
        </postal>
        <email>liuxing0315@sohu.com</email>
      </address>
    </author>
    <date day="10" month="July" year="2023"/>
    <workgroup>IDR</workgroup>
    <abstract>
      <t>This document describes an approach for using the BGP EPE Control 
	  Plane <xref target="RFC8670" format="default"/> 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.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>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.</t>
      <t>Enabling  BGP EPE?egress peer engineering <xref target="RFC8670" format="default"/>, 
      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.</t>
      <t>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.</t>
      <t>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 . </t>
    </section>
    <section anchor="definition-of-terms" numbered="true" toc="default">
      <name>Definition of Terms</name>
      <t>This document makes use of the following terms:</t>
      <dl newline="false" spacing="normal" indent="2">
        <dt>Computing-Aware Traffic Steering (CATS): </dt>
        <dd>Aiming at
          computing and network resource optimization by steering traffic to
          appropriate computing resources considering not only routing metric
          but also computing resource metric.</dd>
        <dt>Service:</dt>
        <dd>A monolithic functionality that is provided
          by an endpoint according to the specification for said service. A
          composite service can be built by orchestrating monolithic
          services.</dd>
        <dt>Service instance:</dt>
        <dd>Running environment (e.g., a node)
          that makes the functionality of a service available. One service can
          have several instances running at different network locations.</dd>
        <dt>Service identifier:</dt>
        <dd>Used to uniquely identify a
          service, at the same time identifying the whole set of service
          instances that each represents the same service behavior, no matter
          where those service instances are running.</dd>
        <dt>Service transaction:</dt>
        <dd>Has one or more service request
          that has several flows which require the affinity because of the
          transaction related state.</dd>
        <dt>Computing Capacity:</dt>
        <dd>The ability of nodes with
          computing resource achieve specific result output through data
          processing, including but not limited to computing, communication,
          memory and storage capacity.</dd>
      </dl>
    </section>
    <section numbered="true" toc="default">
      <name>CATS information to be Distributed by BGP</name>
      <t>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.</t>
      <t>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 .</t>
      <t>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.</t>
    </section>
    <section anchor="BGP_EPE_for_CATS" numbered="true" toc="default">
      <name>BGP EPE for CATS</name>
      <section numbered="true" toc="default">
        <name>Metric collected and distributed</name>
        <t>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:</t>
        <t>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.</t>
        <t> 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.</t>
        <t> 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.</t>
        <figure anchor="fig-BGP-EPE-CATS-modeling">
          <name>Modeling of BGP EPE For CSTS</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[                                 
	                                                       +---------+
	                                                       | R12     |
	+---------------+  +-----------------+  +------------+ |         |
	| SDN           |  |        R8       |  |            | |    C-SMA|
	|               |  |                 |  |            | +---------+
	|          R2   |  |                 |  |     R10    |
	|               |  |   R4      R6    |  |            |
	|               |  |       AS3       |  |            |
	| R1            |  +-----------------+  |            |
	|               |                       |            |
	|               |   +----------------+  |            |
	|         R3    |   |                |  |            |
	|               |   |                |  |            |
	|               |   |  R5      R7    |  |     R9     |
	|               |   |                |  |            | +----------+
	|      AS1      |   |     AS2        |  |    AS4     | | R11      |
	+---------------+   +----------------+  +------------+ |          |
	                                                       |     C-SMA|
	                                                       +----------+

                                 |]]></artwork>
        </figure>
      </section>
      <section numbered="true" toc="default">
        <name>BGP Extension for CATS</name>
        <t>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 
        <xref target="RFC8669" format="default"/>, 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. </t>
      </section>
      <section numbered="true" toc="default">
        <name>Implemention for BGP EPE CATS</name>
        <t>Enabling  BGP EPE<xref target="RFC7855" format="default"/> 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.</t>
        <t>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.</t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Minimum Interval for Metrics Change Advertisement</name>
      <t>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 .</t>
    </section>
    <section anchor="manageability-considerations" numbered="true" toc="default">
      <name>Manageability Considerations</name>
      <t>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.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>BGP EPE CATS needs to follow the spring architecture<xref target="RFC7855" format="default"/>, and be consistent 
      with the spring architecture?s security considerations.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>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.</t>
    </section>
    <section anchor="acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>TBD.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8670" target="https://www.rfc-editor.org/info/rfc8670" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8670.xml">
          <front>
            <title>BGP Prefix Segment in Large-Scale Data Centers</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="G. Dawra" initials="G." surname="Dawra"/>
            <author fullname="E. Aries" initials="E." surname="Aries"/>
            <author fullname="P. Lapukhov" initials="P." surname="Lapukhov"/>
            <date month="December" year="2019"/>
            <abstract>
              <t>This document describes the motivation for, and benefits of, applying Segment Routing (SR) in BGP-based large-scale data centers.  It describes the design to deploy SR in those data centers for both the MPLS and IPv6 data planes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8670"/>
          <seriesInfo name="DOI" value="10.17487/RFC8670"/>
        </reference>
        <reference anchor="RFC8669" target="https://www.rfc-editor.org/info/rfc8669" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8669.xml">
          <front>
            <title>Segment Routing Prefix Segment Identifier Extensions for BGP</title>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="A. Lindem" initials="A." role="editor" surname="Lindem"/>
            <author fullname="A. Sreekantiah" initials="A." surname="Sreekantiah"/>
            <author fullname="H. Gredler" initials="H." surname="Gredler"/>
            <date month="December" year="2019"/>
            <abstract>
              <t>Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through an ordered list of instructions called "segments". A segment can represent any instruction, topological or service based. The ingress node prepends an SR header to a packet containing a set of segment identifiers (SIDs). Each SID represents a topological or service-based instruction. Per-flow state is maintained only on the ingress node of the SR domain. An "SR domain" is defined as a single administrative domain for global SID assignment.</t>
              <t>This document defines an optional, transitive BGP attribute for announcing information about BGP Prefix Segment Identifiers (BGP Prefix-SIDs) and the specification for SR-MPLS SIDs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8669"/>
          <seriesInfo name="DOI" value="10.17487/RFC8669"/>
        </reference>
        <reference anchor="RFC9085" target="https://www.rfc-editor.org/info/rfc9085" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9085.xml">
          <front>
            <title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing</title>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="H. Gredler" initials="H." surname="Gredler"/>
            <author fullname="M. Chen" initials="M." surname="Chen"/>
            <date month="August" year="2021"/>
            <abstract>
              <t>Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological subpaths, called "segments". These segments are advertised by routing protocols, e.g., by the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3) within IGP topologies.</t>
              <t>This document defines extensions to the Border Gateway Protocol - Link State (BGP-LS) address family in order to carry SR information via BGP.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9085"/>
          <seriesInfo name="DOI" value="10.17487/RFC9085"/>
        </reference>
        <reference anchor="RFC9086" target="https://www.rfc-editor.org/info/rfc9086" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9086.xml">
          <front>
            <title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering</title>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="K. Patel" initials="K." surname="Patel"/>
            <author fullname="S. Ray" initials="S." surname="Ray"/>
            <author fullname="J. Dong" initials="J." surname="Dong"/>
            <date month="August" year="2021"/>
            <abstract>
              <t>A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with a list of segment identifiers (SIDs). A segment can represent any instruction, topological or service based. SR segments allow steering a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain.</t>
              <t>This document describes an extension to Border Gateway Protocol - Link State (BGP-LS) for advertisement of BGP Peering Segments along with their BGP peering node information so that efficient BGP Egress Peer Engineering (EPE) policies and strategies can be computed based on Segment Routing.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9086"/>
          <seriesInfo name="DOI" value="10.17487/RFC9086"/>
        </reference>
        <reference anchor="RFC9087" target="https://www.rfc-editor.org/info/rfc9087" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9087.xml">
          <front>
            <title>Segment Routing Centralized BGP Egress Peer Engineering</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="G. Dawra" initials="G." role="editor" surname="Dawra"/>
            <author fullname="E. Aries" initials="E." surname="Aries"/>
            <author fullname="D. Afanasiev" initials="D." surname="Afanasiev"/>
            <date month="August" year="2021"/>
            <abstract>
              <t>Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows for the enforcement of a flow through any topological path while maintaining per-flow state only at the ingress node of the SR domain.</t>
              <t>The Segment Routing architecture can be directly applied to the MPLS data plane with no change on the forwarding plane. It requires a minor extension to the existing link-state routing protocols.</t>
              <t>This document illustrates the application of Segment Routing to solve the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based BGP-EPE solution allows a centralized (Software-Defined Networking, or SDN) controller to program any egress peer policy at ingress border routers or at hosts within the domain.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9087"/>
          <seriesInfo name="DOI" value="10.17487/RFC9087"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC7855" target="https://www.rfc-editor.org/info/rfc7855" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7855.xml">
          <front>
            <title>Source Packet Routing in Networking (SPRING) Problem Statement and Requirements</title>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
            <author fullname="M. Horneffer" initials="M." surname="Horneffer"/>
            <author fullname="R. Shakir" initials="R." surname="Shakir"/>
            <date month="May" year="2016"/>
            <abstract>
              <t>The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions. Source-based routing mechanisms have previously been specified for network protocols but have not seen widespread adoption. In this context, the term "source" means "the point at which the explicit route is imposed"; therefore, it is not limited to the originator of the packet (i.e., the node imposing the explicit route may be the ingress node of an operator's network).</t>
              <t>This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic. Multicast use cases and requirements are out of scope for this document.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7855"/>
          <seriesInfo name="DOI" value="10.17487/RFC7855"/>
        </reference>
        <reference anchor="I-D.yao-cats-ps-usecases" target="https://datatracker.ietf.org/doc/html/draft-yao-cats-ps-usecases-02" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.yao-cats-ps-usecases.xml">
          <front>
            <title>Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases and Requirements</title>
            <author fullname="Kehan Yao" initials="K." surname="Yao">
              <organization>China Mobile</organization>
            </author>
            <author fullname="Dirk Trossen" initials="D." surname="Trossen">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
              <organization>Orange</organization>
            </author>
            <author fullname="Luis M. Contreras" initials="L. M." surname="Contreras">
              <organization>Telefonica</organization>
            </author>
            <author fullname="Hang Shi" initials="H." surname="Shi">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Yizhou Li" initials="Y." surname="Li">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Shuai Zhang" initials="S." surname="Zhang">
              <organization>China Unicom</organization>
            </author>
            <date day="22" month="June" year="2023"/>
            <abstract>
              <t>Many service providers have been exploring distributed computing techniques to achieve better service response time and optimized energy consumption. Such techniques rely upon the distribution of computing services and capabilities over many locations in the network, such as its edge, the metro region, virtualized central office, and other locations. In such a distributed computing environment, providing services by utilizing computing resources hosted in various computing facilities (e.g., edges) is being considered, e.g., for computationally intensive and delay sensitive services. Ideally, compute services are balanced across servers and network resources using metrics that are oriented towards compute capabilities and resources instead of simply dispatching the service requests in a static way or optimizing solely on connectivity metrics. For example, systematically directing end user-originated service requests to the geographically closest edge or some small computing units may lead to an unbalanced usage of computing resources, which may then degrade both the user experience and the overall service performance. We have named this kind of network with dynamic sharing of edge compute resources "Computing-Aware Traffic Steering" (CATS). This document provides the problem statement and the typical scenarios of CATS, which is to show the necessity of considering more factors when steering the traffic to the appropriate service instance based on the basic edge computing deployment to provide the service equivalency.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-yao-cats-ps-usecases-02"/>
        </reference>
      </references>
    </references>
  </back>
</rfc>
