<?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-rfc version 1.7.29 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-yxl-cats-protocols-applicability-00" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.0 -->
  <front>
    <title abbrev="Protocols Applicability for CATS ">Protocols Applicability for Computing-Aware Traffic Steering (CATS)</title>
    <seriesInfo name="Internet-Draft" value="draft-yxl-cats-protocols-applicability-00"/>
    <author initials="H." surname="Yao" fullname="Huijuan Yao">
      <organization>China Mobile</organization>
      <address>
        <email>yaohuijuan@chinamobile.com</email>
      </address>
    </author>
    <author initials="Q." surname="Xiong" fullname="Quan Xiong">
      <organization>ZTE Corporation</organization>
      <address>
        <email>xiong.quan@zte.com.cn</email>
      </address>
    </author>
    <author initials="C." surname="Lin" fullname="Changwang Lin">
      <organization>New H3C Technologies</organization>
      <address>
        <email>linchangwang.04414@h3c.com</email>
      </address>
    </author>
    <date year="2026" month="January" day="09"/>
    <workgroup>cats</workgroup>
    <abstract>
      <?line 51?>

<t>This document analyzes the applicability of protocols related to a CATS system，and describes how to build a CATS system by extending existing IETF protocols.</t>
    </abstract>
  </front>
  <middle>
    <?line 54?>

<section anchor="introduction">
      <name>Introduction</name>
      <t><xref target="I-D.ietf-cats-framework"/> introduces a framework for Computing-Aware Traffic Steering (CATS). 
This document analyzes the corresponding protocols in control plane, management plane 
and data plane, and evaluates how far the existing protocols or be extended 
to support CATS such as metrics distribution and their operational requirements.</t>
    </section>
    <section anchor="conventions">
      <name>Conventions Used in This Document</name>
      <section anchor="terminology">
        <name>Terminology</name>
        <t>The terms defined in <xref target="I-D.ietf-cats-framework"/> can be used in this document.</t>
      </section>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all
   capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="cats-applicability">
      <name>CATS Applicability Overview</name>
      <t>As defined in <xref target="I-D.ietf-cats-framework"/>, the CATS framework structure consists of the C-SMA (responsible for maintaining service metrics), the C-NMA (responsible for maintaining network metrics), the C-PS (responsible for maintaining forwarding table entries), and the C-TC (responsible for traffic classification).</t>
      <section anchor="control-plane-applicability-analysis">
        <name>Control Plane Applicability Analysis</name>
        <t>The control plane protocols are used to distribute the CATS metrics of service,then to chose forwarding paths to the CATS service's destinatios.
Based on  <xref target="I-D.ietf-cats-framework"/>, various relevant computing metrics are defined in [I-D.ietf-cats-metric-definition], which can be used in CATS. However, the protocols and technologies for distributing metrics from the egress gateway to the ingress gateway are still under research.Extensible protocols include YANG, BGP existing attribute, new BGP address family, FlowSpec, or BGP-LS. In addition, The FlowSpec protocol can be extended to accommodate the selection of CATS service paths.
In addition, the control protocols are capable of controlling traffic classification include FlowSpec and YANG model. The FlowSpec is a distributed control method, while the YANG model is a centralized control method. These two protocol models can be extended to classify CATS data traffics.</t>
      </section>
      <section anchor="management-plane-applicability-analysis">
        <name>Management Plane Applicability Analysis</name>
        <t>Management plane protocols are used to manage and configure CATS systems. Existing PING and TRACE protocols may be utilized in CATS networks. These protocols could be extended to operate on specific CATS Service Identifiers (CS‑IDs). Alternatively, YANG models could be extended to report statistical information about CATS flows for monitoring purposes.</t>
      </section>
      <section anchor="data-plane-applicability-analysis">
        <name>Data Plane Applicability Analysis</name>
        <t>The data plane protocols are used to forward the CATS traffiic to the corresponding destination  by existing rotocols IPv4/IPv6 or IPv4/IPv6 over SRv6.</t>
      </section>
    </section>
    <section anchor="cats-protocols-applicability">
      <name>Protocols Applicability to CATS</name>
      <section anchor="igpbgp-ls-applicability-for-metrics-collection">
        <name>IGP/BGP-LS Applicability for Metrics Collection</name>
        <t>As defined in <xref target="I-D.ietf-cats-framework"/> section 3.4.3, the CATS Network Metric Agent (C-NMA) is used to 
gather information about the state of the underlay network. The C-NMA could collect the network metrics
leveraging the existing IGP (Interior Gateway Protocol) (e.g., OSPF-TE<xref target="RFC7471"/> and IS-IS TE <xref target="RFC8570"/>) and 
advertise them to the CATS Path Selector (C-PSes) through BGP-LS (Border Gateway Protocol Link State) <xref target="RFC8571"/>.</t>
        <t>As defined in <xref target="I-D.ietf-cats-framework"/> section 3.4.2, the CATS Service Metric Agent (C-SMA) is used to 
gather information about service sites and server resources, as well as the status of the different service instances. 
The C-SMA may collect the service information through private interfaces associated with multiple service contact instances
and report them to the C-PSes through BGP-LS extensions for service metrics.</t>
      </section>
      <section anchor="bgp-applicability-for-metrics-distribution">
        <name>BGP Applicability for Metrics Distribution</name>
        <t>As defined in <xref target="I-D.ietf-cats-framework"/> section 4.2, the C-SMA needs to collect the computing-related
capabilities and metrics, associate them with a CS-ID and distribute the computing metrics to the C-PSes.
The C-NMA needs to collect the network-related capabilities and metrics, and distribute the network metrics 
to the C-PSes. The C-PSes could use the combination of computing and network metrics to determine the best 
Egress CATS-Forwarder to provide access to a service contact instance and invoke the compute function required 
by a service request.</t>
        <t>BGP (Border Gateway Protocol) is an inter-Autonomous System (AS) routing protocol that enables the distribution of 
routing information across the networks. It operates between different AS, which are networks under a single 
administration to exchange network reachability information and determine the best paths for data transmission. 
The exsiting BGP technology (e.g., <xref target="RFC4271"/> and <xref target="I-D.ietf-idr-bgp4-rfc4271bis"/>) can be used to distribute the 
network metrics from the C-NMA to the C-PSes. The C-SMA may distribute the computing metrics to the C-PSes through 
BGP extensions for CATS.</t>
      </section>
      <section anchor="pcep-applicability-for-service-aware-computing">
        <name>PCEP Applicability for Service-aware Computing</name>
        <t>As defined in <xref target="I-D.ietf-cats-framework"/> section 3.4.4, C-PSes determines the best paths to forward traffic after collecting
the computing and network metrics. And a standalone C-PS can be a functional component of a PCE (Path Computation Element). 
The Path Computation Element Protocol (PCEP) as per <xref target="RFC5440"/> is used to enable computation of the path between a PCE and 
a Path Computation Client (PCC) (or other PCE).</t>
        <t>The C-PSes which is viewed as a PCE can compute the best path from ingress CATS-Forwarder (which is viewed as a PCC)to 
egress CATS-Forwarder based on the network topology information from C-NMA. But in CATS, the C-PSes may firstly select the 
egress CATS-Forwarder and the related service instances and compute the path associated with the computing metric information 
from C-SMA. The C-PSes could also distribute the best path including the corresponding CS-ID and possibly CSCI-IDs through 
PCEP extensions.</t>
      </section>
      <section anchor="bgp-fs-applicability-for-service-mapping">
        <name>BGP-FS Applicability for Service Mapping</name>
        <t>A BGP Flow Specification (BGP-FS) is an n-tuple consisting of several matching criteria that can be applied to IP traffic 
such as BGP flow specification version 1 (FSv1) as per <xref target="RFC8955"/> and version 2 of the BGP flow specification (FSv2)
as per <xref target="I-D.ietf-idr-flowspec-v2"/>. A service is identified by an prefix as defined in <xref target="RFC8955"/> and <xref target="RFC8956"/> 
can be used to steer the traffic in IP networks by L3 traffic filtering rules. The MPLS label filtering rules can be used 
to match the traffic in <xref target="I-D.ietf-idr-flowspec-mpls-match"/> and the MPLS label for a service mapping to a MPLS network 
can use the Label-action defined in <xref target="I-D.ietf-idr-bgp-flowspec-label"/>. It also could use the BGP FlowSpec to steer packets
into an SR Policy as per <xref target="I-D.ietf-idr-ts-flowspec-srv6-policy"/>.</t>
        <t>As defined in <xref target="I-D.ietf-cats-framework"/> section 3.4.4, a standalone C-PS can be a functional component of a centralized 
controller. The BGP-FS may help the C-PSes to distribute the routes associated with computing metrics and steer the traffic
for CATS services. The CATS services may be mapped to the corresponding CS-ID or SR Policy through BGP-FS extensions.</t>
      </section>
      <section anchor="bgp-sr-policy-applicability-for-service-aware-candidate-paths">
        <name>BGP SR Policy Applicability for Service-aware Candidate Paths</name>
        <t>The ingress node can steer the packets into a specific path according to the Segment Routing Policy (SR Policy) as 
defined in <xref target="RFC9256"/> and the BGP SR Policy can be used to distribute SR policies to the headend as per <xref target="RFC9830"/>.</t>
        <t>As per <xref target="I-D.ietf-cats-framework"/> section 3.4.4, a standalone C-PS can be a functional component of a centralized 
controller. The C-PS may distribute SR policies to the CATS Ingress CATS-Router associated with computing metrics in 
SR-MPLS and SRv6 networks. The SR policy may be distributed to carry the identifiers of CATS services in candidate paths
by the BGP SR Policy extensions.</t>
      </section>
      <section anchor="yang-model-applicability-for-service-configuration-and-management">
        <name>Yang Model Applicability for Service Configuration and Management</name>
        <t>As per <xref target="I-D.ietf-cats-framework"/> section 3.3, the CATS management plane is responsible for monitoring, configuring,
and maintaining CATS network devices. The CATS data may be required to be maintained in the management plane and configured 
to the control plane, data plane and C-SMA. A YANG data model may be required for the configuration and management.</t>
        <t>The routing data model and ietf-routing YANG model is defined for configuring and managing a routing subsystem
as per <xref target="RFC8349"/>. The model contains all the basic network-related configuration parameters to operate the CATS networks. 
The data model may be required to augment for the CATS computing information.</t>
      </section>
      <section anchor="data-plane-protocols-applicability-for-forwarding-cats-packets">
        <name>Data plane Protocols Applicability for Forwarding CATS Packets</name>
        <t>As per <xref target="I-D.ietf-cats-framework"/> section 3.3, the CATS data plane is responsible for computing-aware steering the
packets along the paths to the service contact instances. It needs to classify and forward the packets in routing 
networks such as IPv6, SR-MPLS and SRv6 networks. The ingress CATS-Router needs to encapsulate the corresponding
headers from itself to the egress CATS-Router. It is required to indicate the interface associated to a specific service
contact instance which connected to the egress CATS-Router.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The security considerations described in <xref target="I-D.ietf-cats-framework"/> and related routing protocols 
are applicable to this document. This document analyzed the applicability for some protocols 
which do not introduce any new extensions and new security considerations.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>Currently this document does not make an IANA requests.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="I-D.ietf-cats-framework">
          <front>
            <title>A Framework for Computing-Aware Traffic Steering (CATS)</title>
            <author fullname="Cheng Li" initials="C." surname="Li">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Zongpeng Du" initials="Z." surname="Du">
              <organization>China Mobile</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="John Drake" initials="J." surname="Drake">
              <organization>Independent</organization>
            </author>
            <date day="20" month="November" year="2025"/>
            <abstract>
              <t>   This document describes a framework for Computing-Aware Traffic
   Steering (CATS).  Specifically, the document identifies a set of CATS
   functional components, describes their interactions, and provides
   illustrative workflows of the control and data planes.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-cats-framework-19"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC768">
          <front>
            <title>User Datagram Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel"/>
            <date month="August" year="1980"/>
          </front>
          <seriesInfo name="STD" value="6"/>
          <seriesInfo name="RFC" value="768"/>
          <seriesInfo name="DOI" value="10.17487/RFC0768"/>
        </reference>
        <reference anchor="RFC2119">
          <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="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC7471">
          <front>
            <title>OSPF Traffic Engineering (TE) Metric Extensions</title>
            <author fullname="S. Giacalone" initials="S." surname="Giacalone"/>
            <author fullname="D. Ward" initials="D." surname="Ward"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="A. Atlas" initials="A." surname="Atlas"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <date month="March" year="2015"/>
            <abstract>
              <t>In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection.</t>
              <t>This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance.</t>
              <t>Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7471"/>
          <seriesInfo name="DOI" value="10.17487/RFC7471"/>
        </reference>
        <reference anchor="RFC8570">
          <front>
            <title>IS-IS Traffic Engineering (TE) Metric Extensions</title>
            <author fullname="L. Ginsberg" initials="L." role="editor" surname="Ginsberg"/>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
            <author fullname="S. Giacalone" initials="S." surname="Giacalone"/>
            <author fullname="D. Ward" initials="D." surname="Ward"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <date month="March" year="2019"/>
            <abstract>
              <t>In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.</t>
              <t>This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.</t>
              <t>Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.</t>
              <t>This document obsoletes RFC 7810.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8570"/>
          <seriesInfo name="DOI" value="10.17487/RFC8570"/>
        </reference>
        <reference anchor="RFC8571">
          <front>
            <title>BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions</title>
            <author fullname="L. Ginsberg" initials="L." role="editor" surname="Ginsberg"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <date month="March" year="2019"/>
            <abstract>
              <t>This document defines new BGP - Link State (BGP-LS) TLVs in order to carry the IGP Traffic Engineering Metric Extensions defined in the IS-IS and OSPF protocols.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8571"/>
          <seriesInfo name="DOI" value="10.17487/RFC8571"/>
        </reference>
        <reference anchor="RFC4271">
          <front>
            <title>A Border Gateway Protocol 4 (BGP-4)</title>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <author fullname="T. Li" initials="T." role="editor" surname="Li"/>
            <author fullname="S. Hares" initials="S." role="editor" surname="Hares"/>
            <date month="January" year="2006"/>
            <abstract>
              <t>This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t>
              <t>The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</t>
              <t>BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</t>
              <t>This document obsoletes RFC 1771. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4271"/>
          <seriesInfo name="DOI" value="10.17487/RFC4271"/>
        </reference>
        <reference anchor="I-D.ietf-idr-bgp4-rfc4271bis">
          <front>
            <title>A Border Gateway Protocol 4 (BGP-4)</title>
            <author fullname="Yakov Rekhter" initials="Y." surname="Rekhter">
              <organization>Retired</organization>
            </author>
            <author fullname="Tony Li" initials="T." surname="Li">
              <organization>HPE</organization>
            </author>
            <author fullname="Susan Hares" initials="S." surname="Hares">
              <organization>Hickory Hill Consulting</organization>
            </author>
            <author fullname="John Scudder" initials="J." surname="Scudder">
              <organization>HPE</organization>
            </author>
            <date day="14" month="October" year="2025"/>
            <abstract>
              <t>   This document discusses the Border Gateway Protocol (BGP), which is
   an inter-Autonomous System routing protocol.

   The primary function of a BGP-speaking system is to exchange network
   reachability information with other BGP systems.  This network
   reachability information includes information on the list of
   Autonomous Systems (ASes) that reachability information traverses.
   This information is sufficient for constructing a graph of AS
   connectivity for this reachability from which routing loops may be
   pruned, and, at the AS level, some policy decisions may be enforced.

   BGP-4 provides a set of mechanisms for supporting Classless Inter-
   Domain Routing (CIDR).  These mechanisms include support for
   advertising a set of destinations as an IP prefix, and eliminating
   the concept of network "class" within BGP.  BGP-4 also introduces
   mechanisms that allow aggregation of routes, including aggregation of
   AS paths.

   This document obsoletes RFC 4271.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp4-rfc4271bis-00"/>
        </reference>
        <reference anchor="RFC5440">
          <front>
            <title>Path Computation Element (PCE) Communication Protocol (PCEP)</title>
            <author fullname="JP. Vasseur" initials="JP." role="editor" surname="Vasseur"/>
            <author fullname="JL. Le Roux" initials="JL." role="editor" surname="Le Roux"/>
            <date month="March" year="2009"/>
            <abstract>
              <t>This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5440"/>
          <seriesInfo name="DOI" value="10.17487/RFC5440"/>
        </reference>
        <reference anchor="RFC8955">
          <front>
            <title>Dissemination of Flow Specification Rules</title>
            <author fullname="C. Loibl" initials="C." surname="Loibl"/>
            <author fullname="S. Hares" initials="S." surname="Hares"/>
            <author fullname="R. Raszuk" initials="R." surname="Raszuk"/>
            <author fullname="D. McPherson" initials="D." surname="McPherson"/>
            <author fullname="M. Bacher" initials="M." surname="Bacher"/>
            <date month="December" year="2020"/>
            <abstract>
              <t>This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.</t>
              <t>It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification.</t>
              <t>This document obsoletes both RFC 5575 and RFC 7674.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8955"/>
          <seriesInfo name="DOI" value="10.17487/RFC8955"/>
        </reference>
        <reference anchor="RFC8956">
          <front>
            <title>Dissemination of Flow Specification Rules for IPv6</title>
            <author fullname="C. Loibl" initials="C." role="editor" surname="Loibl"/>
            <author fullname="R. Raszuk" initials="R." role="editor" surname="Raszuk"/>
            <author fullname="S. Hares" initials="S." role="editor" surname="Hares"/>
            <date month="December" year="2020"/>
            <abstract>
              <t>"Dissemination of Flow Specification Rules" (RFC 8955) provides a Border Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets.</t>
              <t>This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8956"/>
          <seriesInfo name="DOI" value="10.17487/RFC8956"/>
        </reference>
        <reference anchor="RFC8402">
          <front>
            <title>Segment Routing Architecture</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
            <author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
            <author fullname="R. Shakir" initials="R." surname="Shakir"/>
            <date month="July" year="2018"/>
            <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. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.</t>
              <t>SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.</t>
              <t>SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8402"/>
          <seriesInfo name="DOI" value="10.17487/RFC8402"/>
        </reference>
        <reference anchor="RFC9256">
          <front>
            <title>Segment Routing Policy Architecture</title>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <author fullname="A. Bogdanov" initials="A." surname="Bogdanov"/>
            <author fullname="P. Mattes" initials="P." surname="Mattes"/>
            <date month="July" year="2022"/>
            <abstract>
              <t>Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.</t>
              <t>This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9256"/>
          <seriesInfo name="DOI" value="10.17487/RFC9256"/>
        </reference>
        <reference anchor="RFC9830">
          <front>
            <title>Advertising Segment Routing Policies in BGP</title>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="P. Mattes" initials="P." surname="Mattes"/>
            <author fullname="D. Jain" initials="D." surname="Jain"/>
            <date month="September" year="2025"/>
            <abstract>
              <t>A Segment Routing (SR) Policy is an ordered list of segments (also referred to as "instructions") that define a source-routed policy. An SR Policy consists of one or more Candidate Paths (CPs), each comprising one or more segment lists. A headend can be provisioned with these CPs using various mechanisms such as Command-Line Interface (CLI), Network Configuration Protocol (NETCONF), Path Computation Element Communication Protocol (PCEP), or BGP.</t>
              <t>This document specifies how BGP can be used to distribute SR Policy CPs. It introduces a BGP SAFI for advertising a CP of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute to signal information related to these CPs.</t>
              <t>Furthermore, this document updates RFC 9012 by extending the Color Extended Community to support additional steering modes over SR Policy.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9830"/>
          <seriesInfo name="DOI" value="10.17487/RFC9830"/>
        </reference>
        <reference anchor="RFC8349">
          <front>
            <title>A YANG Data Model for Routing Management (NMDA Version)</title>
            <author fullname="L. Lhotka" initials="L." surname="Lhotka"/>
            <author fullname="A. Lindem" initials="A." surname="Lindem"/>
            <author fullname="Y. Qu" initials="Y." surname="Qu"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.</t>
              <t>The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8349"/>
          <seriesInfo name="DOI" value="10.17487/RFC8349"/>
        </reference>
        <reference anchor="I-D.ietf-idr-flowspec-v2">
          <front>
            <title>BGP Flow Specification Version 2</title>
            <author fullname="Susan Hares" initials="S." surname="Hares">
              <organization>Hickory Hill Consulting</organization>
            </author>
            <author fullname="Donald E. Eastlake 3rd" initials="D. E." surname="Eastlake">
              <organization>Futurewei Technologies</organization>
            </author>
            <author fullname="Chaitanya Yadlapalli" initials="C." surname="Yadlapalli">
              <organization>ATT</organization>
            </author>
            <author fullname="Sven Maduschke" initials="S." surname="Maduschke">
              <organization>Verizon</organization>
            </author>
            <date day="28" month="April" year="2024"/>
            <abstract>
              <t>   BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC
   8956, and RFC 9117 describes the distribution of traffic filter
   policy (traffic filters and actions) distributed via BGP.  Multiple
   applications have used BGP FSv1 to distribute traffic filter policy.
   These applications include the following: mitigation of denial of
   service (DoS), enabling traffic filtering in BGP/MPLS VPNs,
   centralized traffic control of router firewall functions, and SFC
   traffic insertion.

   During the deployment of BGP FSv1 a number of issues were detected
   due to lack of consistent TLV encoding for rules for flow
   specifications, lack of user ordering of filter rules and/or actions,
   and lack of clear definition of interaction with BGP peers not
   supporting FSv1.  Version 2 of the BGP flow specification (FSv2)
   protocol addresses these features.  In order to provide a clear
   demarcation between FSv1 and FSv2, a different NLRI encapsulates
   FSv2.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-flowspec-v2-04"/>
        </reference>
        <reference anchor="I-D.ietf-idr-flowspec-mpls-match">
          <front>
            <title>BGP Flow Specification Filter for MPLS Label</title>
            <author fullname="Lucy Yong" initials="L." surname="Yong">
              <organization>Huawei</organization>
            </author>
            <author fullname="Susan Hares" initials="S." surname="Hares">
              <organization>Huawei</organization>
            </author>
            <author fullname="liangqiandeng" initials="" surname="liangqiandeng">
              <organization>Huawei</organization>
            </author>
            <author fullname="Jianjie You" initials="J." surname="You">
              <organization>Huawei</organization>
            </author>
            <date day="20" month="October" year="2022"/>
            <abstract>
              <t>   This draft proposes BGP flow specification rules that are used to
   filter MPLS labeled packets.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-flowspec-mpls-match-02"/>
        </reference>
        <reference anchor="I-D.ietf-idr-bgp-flowspec-label">
          <front>
            <title>Carrying Label Information for BGP FlowSpec</title>
            <author fullname="liangqiandeng" initials="" surname="liangqiandeng">
              <organization>Huawei</organization>
            </author>
            <author fullname="Susan Hares" initials="S." surname="Hares">
              <organization>Huawei</organization>
            </author>
            <author fullname="Jianjie You" initials="J." surname="You">
              <organization>Huawei</organization>
            </author>
            <author fullname="Robert Raszuk" initials="R." surname="Raszuk">
              <organization>Nozomi</organization>
            </author>
            <author fullname="Dan Ma" initials="D." surname="Ma">
              <organization>Cisco Systems</organization>
            </author>
            <date day="20" month="October" year="2022"/>
            <abstract>
              <t>   This document specifies a method in which the label mapping
   information for a particular FlowSpec rule is piggybacked in the same
   Border Gateway Protocol (BGP) Update message that is used to
   distribute the FlowSpec rule.  Based on the proposed method, the
   Label Switching Routers (LSRs) (except the ingress LSR) on the Label
   Switched Path (LSP) can use label to indentify the traffic matching a
   particular FlowSpec rule; this facilitates monitoring and traffic
   statistics for FlowSpec rules.


              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-flowspec-label-02"/>
        </reference>
        <reference anchor="I-D.ietf-idr-ts-flowspec-srv6-policy">
          <front>
            <title>Traffic Steering using BGP FlowSpec with SR Policy</title>
            <author fullname="Jiang Wenying" initials="J." surname="Wenying">
              <organization>China Mobile</organization>
            </author>
            <author fullname="Yisong Liu" initials="Y." surname="Liu">
              <organization>China Mobile</organization>
            </author>
            <author fullname="Shunwan Zhuang" initials="S." surname="Zhuang">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Gyan Mishra" initials="G. S." surname="Mishra">
              <organization>Verizon Communications Inc.</organization>
            </author>
            <author fullname="Shuanglong Chen" initials="S." surname="Chen">
              <organization>Huawei Technologies</organization>
            </author>
            <date day="4" month="August" year="2025"/>
            <abstract>
              <t>   BGP Flow Specification (FlowSpec) [RFC8955] and [RFC8956] has been
   proposed to distribute BGP [RFC4271] FlowSpec NLRI to FlowSpec
   clients to mitigate (distributed) denial-of-service attacks, and to
   provide traffic filtering in the context of a BGP/MPLS VPN service.
   Recently, traffic steering applications in the context of SR-MPLS and
   SRv6 using FlowSpec are being used in networks.  This document
   introduces the usage of BGP FlowSpec to steer packets into an SR
   Policy.


              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-ts-flowspec-srv6-policy-07"/>
        </reference>
      </references>
    </references>
    <?line 188?>

    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-contributors">Contributors</name>
      <t indent="0" pn="section-appendix.a-1">The following people have substantially contributed to this document:</t>
      <contact fullname="Peng Liu">
        <organization showOnFrontPage="true">China Mobile</organization>
        <address>
          <email>liupengyjy@chinamobile.com</email>
        </address>
      </contact>
    </section>	
	
	
	
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA8VazXLbOBK+q0rvgEoOa1eJmthWkokPW6PIdqIq/2gsp2qz
W3uASEjChCI4BClFk/LUPsBe9n32afYF9hW2u/FDkJKcmcxhD04oEmg0+ufr
HyCKom5nfc7Oup1ExRlfiXOWFHxeRtvPaRTzUkd5oUoVq1RHPM9TGfOZTGW5
jV686HZgwDmT2Vx1O7qaraTWUmXlNgcq48uHq26nlGUKPyaOBhuGNNhcFWyk
VnlVymwRDTe8EOwBlp/LmE1LIQp4zY5Gw4fpcbfDZ7NCAK9/7nbY0xRhfLez
WZwz3EC3A1OrcqmKc3yMmNnl+0r+VPGMfeQK6akCho+WMuPsRgEtgS/Fisv0
nG25WprRP8Q4YkUD+rFa4aCa5I9I7y8ggYWn+NeHS9hgkauCl/AhIPoZx/V/
RqK/lESsH2cs5HC05NliA3/sWuIXS/JWbNj7sxF7EPEyU6laSKFZQDiVWexm
9l8MBieDH5ZnMS5A1LudTBUr4GYtznHWOLroS1HOjbLnBSy9UcUnkhVqNhx7
fzV6/ep793h6cvLGPX9/8nrghwxen/j3L1+/CJ79+8GpffbLy6SIZot8EBXz
GL/OpHaDXw4GNZE3L18Gz6/88+DFqXt+c1q/f/P9WT33bPBmd9F5qjY6F3G0
Pn3i4yoHBwBRxMu9bNcDUz4T6e4YlK0boov1qyhXYLXbc2NBoPQoYnymy4LH
Jf5+WErNwCWrlchKxjOebn8BPZdLwRpuyNSceQ9lhUh5KRJWKsbJDZje6lKs
/vvvf/IsYYnQcSFnQGepNjhoVsk0aQ5lsy0Tn0uRJeh74rPU6JvkzvVCfcPw
SiYJekq385yNs7JQSRWjmbMvz2Xw87Hb+fLlgJ09PjI3FNjizH/4PdjQZ08K
LFZFIXSuzJZqaYFXxQoXT1me8kz02ArmLQRRoDdAl+TGS+6G4G+x5mkFgjZy
nPOClvGyqleALcyEFSeoBfBQMV3lAAellXkVLxnXbCXKQsawASABGqpIirgU
EJYFU7kwAMJT0PHPlSyISdQDyn6ksjX8hO+afdCwEOyM5HHh5PHleVyPeaRZ
zwFBipUkCNkakxOshFfAhZjLzJB5SnExwB1sr7IrlqEG+naN+4Bbdg2QVIGA
8RtjDBf8JLYMyCWaPbv5MH141jP/s9s7er6//PHD+P7yAp+n74fX1/7BjCA6
8OLuw7Udg0/17NHdzc3l7YUhAG9Z69XN8OMz0qkhdDd5GN/dDq+f7eyHofmh
xwi0V1HkhUBH49o7Fcng7WhClE4GIDmLkSApekaMhOfNUmTGjFSWbu1PUPMW
HVuALQEZnqZEJua5LHmqe7iQBmPL2FIUwqkdLagZ/u7WolhLiBCgcFRXAytA
78OGcv92QLd/J4YM/dohwTLBn6sCHSrTYKgawYcGRtObITsyTqblLBXkvRCP
shL+0Cc08hULZ+jHdoXo9msTM1HS6u2Jk+nT8+A3QAZ5fMlxACixgFB53HN+
BUQeRrtESosxccohnYEncjzCGLLokYWMCQFEU/xDhB0QjXGmBrgEqICmRE4D
9uQdXtQid2AA0rVi68G3DIfHS6VFuLecl0uNX/xsO+VPZJmAR8g+AsVbjksC
rDyl9jUvpKookADIgdnHDoE9V8j9YRsyoyIaIFFwQHSzlIByLbRAXvvsvdoI
MFmj1EBCqKEwv0HF1NgYcDMvIK8h9F2AIjVbACxv+NZJBIY2XiPzIJQ0ZRUg
cgH71OBy8bJ/iRhtjCAMEHFaJYJ9HN6+67G37yY1xvPSqq0HFrqhbzxJaK05
X8l022NXEO+nEO97GAZgQHQNGx5nOI4k0yMAdKP8sk5QPmpgMI9BDysFcciY
iQb1mEgLNhJq3dgDaLuxThkaY8MMAWDIOYCMHZCSx+z1AS8PzzPqCYXDgDeR
9psbkhjPa/tOPAugu6VKyC5Ss5+ahpkVo7PyVP6yM4vWABcAUKglRjP1PsHZ
DWyNkCiO271pF6Fu6pj/tEvftJOD/R5tcggSDbA+lwtEzCDB0n126axoMoZ9
48iH++HoMiC4AltFZwFTJSFYh3FoqJ0Y6hmxqiCVa23f5A0CvR4zT9SkoTO1
5jJOMCeYS1FoyKWm//nHv8YXGrBumEKMyyjzR1Ou9XNgoUJQTqNLmAJbiyFP
8cUDZjIzVdmMh7Jgg9YKEEJRGpdXUCJp4XVygYp6Whtka3VidkAZFilrdDTa
BzFYgGjmhjViAkxSImwV5YmPJ+vBd/DPK3Tq4AeAGJver1/Z0HyoPIVViQ0b
ng/U1i5BG7+bfGeAY0+Ve2MRcAQ+a8AAZw1/c/amLYKc9Qf9syDg39qAa+iz
4QIN/ogi9TF6pxNttwOgCtnIHkUTRJVkeCZBILBNwaat/RqkMNHf2FNsdkGj
WyG/20kxRvAFIVOYaIN82NEY0zEJAnlnMd7J/pgdif6i32N308lV9HBJSRgW
p7B59LnxNBpPGRToJjuDSvXx8Zi+QNafwIpgygRPq0Z8ncCuwX+QW1j0CDMR
yCrge6GqxdICPTt6C0mt2GUKa/lPUL/A62O/MHDUN2Xgt6nvNFCf8+y2+qa/
XX0ulmiJJQ4KBN+YaKmqAgo1ykc3AsIo117blc8HEzmfQ5qa1aRkBiMymGlK
NZcyIsyFmq+H1zw5weaFXKNJUfo951Quaq1iSRXvRoJWVlVayjyt6WDsgIK6
Xt7UcxatGqolNba1KExWgHUVulwriXVohcH/sH9eBCXdt6m4VjAJLRMioZQv
lJzP0yLbA8DmXG74kVaLlu1eLTcjApIdZyPwhwsa2EpKd3PAhtD6TqO3h5iz
Du1YY09wtrt6Cw1MER2sbqGE1GewpNKe75lDc0pw3DZwlTZZzMVFSRWxmT2D
WACLXZoEEn0rujLRBDyhpOxjLSEZgtwMB1DL5ZDd0YoyW6tPoUQhka8yo2Jb
1CP0QNipCeF74IMsDc3sEKyQa/PMOEc0rEqVqRUm8lPT1DkaTo8hiFWN/gSw
wkuoizAD1NZxg/YDiKzbcXMaKBEXSutQOaCFcemyDQ2iKzcCCpYaB4ZTVwZg
dHazbBIO24UlUuq2JCB/ZML6vgIXpG5mbQeF4PDGOlqDLepw7ajQVEhUQNj0
L9O2U+3ASHwGqMNdooh93bF18YNgGnuSNnAEPruna4lBJKx1dou8bqdtfL6K
MU6018AdXv4+5/SIZuynBWhUhFkUm4wu98GYjScRpwacb8h9e7Aa9BxrXlm6
ra0wc7OlCJ/DYIcqxEBz93t8GtLYDLub6IMJT1Vm+wZWO9y7H2SrSAgGgKmC
2XMUBjuiSG92bCzsMqX0/9jZzaEBdbQ/QqkeY5QE3zCGhN1s7HrWodh4oN2L
hyuqiHEB502GK5uf7K49SiWF+sloBJkPaE5ReIc5tncR4KRxRWABe0WmjWWo
o2gcODV0YkzUldMtNDw6QG90TImG2Dtp5voRIciXKjeuFzo2LU2e0Wdvq9IV
Q73QzNEz5rLQZbq11bF1tf2LuxaQi0g7eYqt32pJkBDaCcc+B2yw3u1Y5qfI
/E6k4qneQYda5Kbcdllvs1KpgzUUTti3gBJ3OhrDy9DlyadrnwdXZy5jia72
FRU+e4R6xHk5oSJW9Wxqa0iztyNDxYWeLCqrPPXNQWSSGliYukOJjkcn+C4u
JObr3AQf54rIiHGG8cS7PB4qmvY4coCFo69iDQdAGvfFTtjR1XR90vQzPCmy
gO3GnTq/OkAPqZziSaMjc+igCPP1YW00mklXRydYNsKm8gKQ8bPpDwcQ2eTL
/X4FvzFfawQNjWccxK2TB1AA6fjgCQtdn/mPc4klO9WqVeqixs0Eklg6kWp/
b4QoSqlIQ+31DomgPg6zWylbq6kiyGJWxppMjkSjnL+bXbuE7RrnRtzEiv2h
Zf95G+oDEhByp2YO6GyXOlJeqjmPPwk8GoZ8SaG6pvdsQgdybL/uDxzf4bp/
KBJ+U3AKu2MgQNu3E4XRufVtBMSlSPNGLrADNpje7Smk9nR9sQpsWySgm00i
nKpdthK+cs0stAJj2ofgDAHIKyIsxa6mTRTzZVc9/KuZC+xAUgMVI6d2AdFF
tEwlgmRfb9IaCTM2UjfQTCSIYQOJNWocPRULCv33NmG2bB15Dgmdup02HOBh
deBDzU0dziNhDJmgFD7hWwoOKJQ0QBCPv8FIrY22DPv/YJxEpZXF7tkK2c84
TDZQrBi3v2qodFVieh8RzKBUsSvX7Jv6FbfONMMuNdauvCi25vwg6I+2Wu3m
/NhbVW6sarbdo8Zd2/2I1zpuqOF9OAiPbPu4Lm+CFvTvVmnY49s555Z45NM6
TPPt2Z5vZOMP00IJj9rCzjTgYBsHqOyygvZ1rjlKdVTcAbLY5azRR0/q6r91
ch90gnGGTbiGpnNtOCBpt/mgEz9DriXrmpO+AwtXDAf0qLBHybtvzaMM5+24
TCDEegH64QnramYOCYIcxF5cwVCDPBjS1GCAZBVPik3WyDVA006jpbGrnKNh
lGjLwdmAN4raR8xun5AaAmJl8M4JkEjU7hgkwX1z7ci19Y2Snrq/dVUfb9qO
q43Wf8DiA/vYY+t198wEC+3ul8D8bscFAgTChS8GPFgdbDZSTlI3xNxRFOo+
PJeo44y3A98h0P6GCB4z9NhXgE3ugUzPgMhinusq5b5zEETgbofCR2F7EbKE
Imrudih2qNLWSJC1RUggFDvivksbQnYzjlq5mSDR6JbZA2OVZaDLOmXYw4Y1
LYDMGBwL7GeEak3sbRnNvjzX9ksUN748Op9231nze/Nax1P2ZhrKxt/aHTYM
+GhP7nQnFWYv4UUZtvfmUrLnqhe1oNVKNMgbWSUKMpiyvkoFZLZ0MB00fEyH
ZHNox/bkajy8He5KUQJb+yQ4qgrs76Xb1m2ZRAlNHK34J2TGkLXdTG3VhlfI
ZmD8/hKTicGq0Oa+kv/plTWHVEJtSMJCYbG55GtBqAmGU0oAwy3zE53hBHzR
rcZff/0VD1uwPBZ0ubKCfTRufl66m5RVDiO2P23b9z6ZpdPt/A9r7CnzQSsA
AA==

-->

</rfc>
