<?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.39 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-geng-grow-bmp-rel-enhancement-02" category="std" consensus="true" submissionType="IETF" version="3">
  <!-- xml2rfc v2v3 conversion 3.34.0 -->
  <front>
    <title abbrev="bmp-rel-enhancement">Log More Routing Events in the BGP Monitoring Protocol (BMP)</title>
    <seriesInfo name="Internet-Draft" value="draft-geng-grow-bmp-rel-enhancement-02"/>
    <author initials="N." surname="Geng" fullname="Nan Geng">
      <organization>Huawei</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>gengnan@huawei.com</email>
      </address>
    </author>
    <author initials="Y." surname="Gao" fullname="Yujia Gao">
      <organization>Zhongguancun Laboratory</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>gaoyj@zgclab.edu.cn</email>
      </address>
    </author>
    <author initials="S." surname="Zhuang" fullname="Shunwan Zhuang">
      <organization>Huawei</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>zhuangshunwan@huawei.com</email>
      </address>
    </author>
    <author initials="H." surname="Wang" fullname="Haibo Wang">
      <organization>Huawei</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>rainsword.wang@huawei.com</email>
      </address>
    </author>
    <date year="2026" month="July" day="19"/>
    <area>OPS</area>
    <workgroup>GROW</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 62?>

<t>The Route Event Logging (REL) message is defined in <xref target="I-D.ietf-grow-bmp-rel"/>, which enables monitored routers to report event-driven operational data to BMP collectors.</t>
      <t>This document defines additional event code points for BGP FlowSpec <xref target="RFC8956">RFC8955</xref> and BGP SR Policies <xref target="I-D.ietf-idr-sr-policy-safi"/>. These extensions enhance monitoring visibility for policy execution failures and improve network operation and troubleshooting capabilities.</t>
    </abstract>
  </front>
  <middle>
    <?line 68?>

<section anchor="sec-intro">
      <name>Introduction</name>
      <t>BGP Adj-RIB-In, Loc-RIB, and Adj-RIB-Out are generated through BGP route exchange and routing policy processing. The BGP Monitoring Protocol (BMP) provides comprehensive monitoring for BGP Adj-RIB-In <xref target="RFC7854"/>, BGP Loc-RIB <xref target="RFC9069"/>, and BGP Adj-RIB-Out <xref target="RFC8671"/>.</t>
      <t>The Route Event Logging (REL) message defined in <xref target="I-D.ietf-grow-bmp-rel"/> is designed to deliver event-driven fault logs and runtime status information from network devices to BMP monitoring servers.</t>
      <t>In modern networks, BGP FlowSpec and BGP SR Policy are widely deployed for traffic filtering, redirection and segment routing traffic engineering. However, existing BMP REL mechanisms lack dedicated event logging for common failure scenarios of these advanced BGP features.</t>
      <t>This document supplements new REL event types to cover typical abnormal failures of BGP FlowSpec and BGP SR Policy, filling the monitoring gap for policy control and forwarding execution anomalies.</t>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" 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>
        <?line -18?>

</section>
    </section>
    <section anchor="bgp-flowspec-routing-event-extensions">
      <name>BGP FlowSpec Routing Event Extensions</name>
      <!-- Log Action TLV is defined in {{I-D.ietf-grow-bmp-rel}}, the first byte defines the nature of the logging, depending on the code point additional data may follow. the following code points are defined for BGP Flowspec in this document:

* TBD1 = Redirect-to-VRF-Fail. The BGP flowspec redirect to VRF action is defined in [RFC8955]. It is used to redirect the specified traffic into a Virtual Routing and Forwarding (VRF) instance that matched the flow specification's Network Layer Reachability Information (NLRI). The VRF instance may fail due to various reasons. As a result, the BGP FlowSpec will fails to redirect the matched traffic to the specific VRF instance. Data contains a UTF-8 string whose value can be organized freely by an implementation and is meant to give additional information about why the log was made.

* TBD2 = Redirect-to-Nexthop-Fail. The BGP flowspec redirect to IP action is defined in {{I-D.ietf-idr-flowspec-redirect-ip}}. It is used to redirect the specified traffic to a target IPv4 address or a target IPv6 address that matched the flow specification's Network Layer Reachability Information (NLRI). The destination IPv4 address or destination IPv6 address may fail for a variety of reasons. Data contains a UTF-8 string whose value can be organized freely by an implementation and is meant to give additional information about why the log was made.

* TBD3 = Redirect-to-SR-Policy-Fail. Data contains a UTF-8 string whose value can be organized freely by an implementation and is meant to give additional information about why the log was made.

* TBD4 = Flowspec Validation Fail. The BGP Flowspec Validation Procedure is defined in [RFC8955]. Data contains a UTF-8 string whose value can be organized freely by an implementation and is meant to give additional information about why the log was made. -->

<t>The Log Action TLV is defined in <xref target="I-D.ietf-grow-bmp-rel"/>. The first byte defines the nature of the logging event, and additional data may follow depending on the code point. The following code points are defined for BGP FlowSpec in this document:</t>
      <ul spacing="normal">
        <li>
          <t>TBD1 = Redirect-to-VRF-Fail. The BGP FlowSpec redirect-to-VRF action is defined in <xref target="RFC8955"/>. This event indicates that a received FlowSpec redirect-to-VRF action cannot be resolved, installed, or executed on the monitored device for the target Virtual Routing and Forwarding (VRF) instance. For example, the target VRF instance may be unavailable or the corresponding redirect action may fail during local processing. Data contains a UTF-8 diagnostic string.</t>
        </li>
        <li>
          <t>TBD2 = Redirect-to-Nexthop-Fail. The BGP FlowSpec redirect-to-IP action is defined in <xref target="I-D.ietf-idr-flowspec-redirect-ip"/>. This event indicates that a received FlowSpec redirect-to-IP action cannot be resolved, installed, or executed on the monitored device for the target IPv4 or IPv6 next hop. Data contains a UTF-8 diagnostic string.</t>
        </li>
        <li>
          <t>TBD3 = Redirect-to-SR-Policy-Fail. This event indicates that a received FlowSpec action that redirects traffic to an SR Policy cannot be resolved, installed, or executed on the monitored device. For example, the referenced SR Policy may be unavailable or may not provide a usable forwarding behavior when the FlowSpec action is processed. Data contains a UTF-8 diagnostic string.</t>
        </li>
        <li>
          <t>TBD4 = FlowSpec-Validation-Fail. The BGP FlowSpec validation procedure is defined in <xref target="RFC8955"/>. This event indicates that a received FlowSpec route fails the FlowSpec validation procedure on the monitored device. This event is distinct from failures that occur while locally resolving, installing, or executing a FlowSpec traffic action. Data contains a UTF-8 diagnostic string.</t>
        </li>
      </ul>
      <t>The UTF-8 diagnostic string is intended to provide additional implementation-specific information for troubleshooting. Its format is not specified by this document. When available, the diagnostic string <bcp14>SHOULD</bcp14> describe the local reason that caused the event to be generated. The Log Action code point defines the common semantics of the reported event.</t>
    </section>
    <section anchor="bgp-sr-policy-routing-event-extensions">
      <name>BGP SR Policy Routing Event Extensions</name>
      <t>Log Action TLV is defined in <xref target="I-D.ietf-grow-bmp-rel"/>, the first byte defines the nature of the logging, depending on the code point additional data may follow. The following code points are defined for BGP SR Policies in this document:</t>
      <ul spacing="normal">
        <li>
          <t>TBD5 = Invalid-Candidate-Path. This event indicates that a candidate path is considered invalid. The validity of a candidate path is described in Section 5 of <xref target="RFC9256"/>. Data contains a UTF-8 string whose value can be organized freely by an implementation and is meant to give additional information about why the log was made.</t>
        </li>
        <li>
          <t>TBD6 = Invalid-Segment-List. This event indicates that a segment list of a candidate path is considered invalid. The validity of a segment list is described in Section 5 of <xref target="RFC9256"/>. Data contains a UTF-8 string whose value can be organized freely by an implementation and is meant to give additional information about why the log was made.</t>
        </li>
        <li>
          <t>TBD7 = Exceeded-Spec-Limit. Data contains a UTF-8 string to indicate violations including exceeding the maximum number of SR Policies or Segment Lists.</t>
        </li>
      </ul>
      <t>The UTF-8 diagnostic string is intended to provide additional implementation-specific information for troubleshooting. Its format is not specified by this document. When available, the diagnostic string <bcp14>SHOULD</bcp14> describe the local reason that caused the event to be generated. The Log Action code point defines the common semantics of the reported event.</t>
      <!-- RFC9830 -->

</section>
    <section anchor="operational-considerations">
      <name>Operational Considerations</name>
      <!-- Network devices (e.g., routers and switches) receive FlowSpec routes and SR Policy routes distributed by controllers, route reflectors or adjacent BGP peers.

When the local device detects control plane validation errors or forwarding plane execution faults for FlowSpec redirection actions or SR Policy candidate path processing, it will actively encapsulate the corresponding fault type and diagnostic information into a BMP REL message and report to the configured BMP server.

BMP monitoring collectors SHOULD record and analyze these extended routing events for real-time alarm and offline fault diagnosis.  -->

<t>A monitored device may receive FlowSpec routes and SR Policy routes from controllers, route reflectors, or adjacent BGP peers. When the device detects a failure while validating or locally processing those routes or their associated actions, it reports the corresponding event and diagnostic information to the configured BMP monitoring collector using a BMP REL message.</t>
      <t>BMP monitoring collectors <bcp14>SHOULD</bcp14> record, analyze, and correlate these extended routing events with the relevant BMP route or policy context when available. These events can be used for real-time alarming and offline fault diagnosis.</t>
      <t>Appropriate caution <bcp14>SHOULD</bcp14> be taken when picking routing events to report, as next-hop related updates may produce heavy message loads during network instability. Mitigation measures <bcp14>SHOULD</bcp14> be deployed on both reporting and receiving sides. For example, local endpoints can apply event filtering controls, while receivers maintain corresponding processing mechanisms to handle potential high-volume event bursts gracefully.</t>
      <t>The failure events defined in this document do not define a corresponding recovery indication. Operators should use these events together with other BMP information and local operational state to determine whether the reported condition is still present.</t>
    </section>
    <section anchor="sec-security">
      <name>Security Considerations</name>
      <t>This document inherits all security requirements and considerations documented in Section 11 of <xref target="RFC7854"/>. BMP control sessions <bcp14>SHOULD</bcp14> only be established between authenticated and trusted monitoring devices to prevent unauthorized access to network internal routing information.</t>
      <t>The UTF-8 diagnostic strings carried in extended REL events may contain sensitive data such as VRF names, policy identifiers and network address prefixes. Operators are recommended to properly isolate BMP monitoring data and restrict access permissions.</t>
      <t>No new protocol interactions or message modes are introduced in this extension. Therefore, no additional security risks are introduced beyond the baseline BMP protocol.</t>
    </section>
    <section anchor="sec-iana">
      <name>IANA Considerations</name>
      <t>This document requests IANA to assign seven new code points in the BMP Log Action TLV Registry established by <xref target="I-D.ietf-grow-bmp-rel"/>.</t>
      <t>The requested code point assignments are as follows:</t>
      <ul spacing="normal">
        <li>
          <t>Redirect-to-VRF-Fail (TBD1)</t>
        </li>
        <li>
          <t>Redirect-to-Nexthop-Fail (TBD2)</t>
        </li>
        <li>
          <t>Redirect-to-SR-Policy-Fail (TBD3)</t>
        </li>
        <li>
          <t>FlowSpec-Validation-Fail (TBD4)</t>
        </li>
        <li>
          <t>Invalid-Candidate-Path (TBD5)</t>
        </li>
        <li>
          <t>Invalid-Segment-List (TBD6)</t>
        </li>
        <li>
          <t>Exceeded-Spec-Limit (TBD7)</t>
        </li>
      </ul>
      <t>After permanent code points are allocated, all TBD markers will be replaced in subsequent document revisions.</t>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>Many thanks to the comments from Jeffrey Haas and Narasimha Prasad.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="RFC7854" target="https://www.rfc-editor.org/info/rfc7854" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7854.xml">
        <front>
          <title>BGP Monitoring Protocol (BMP)</title>
          <author fullname="J. Scudder" initials="J." role="editor" surname="Scudder"/>
          <author fullname="R. Fernando" initials="R." surname="Fernando"/>
          <author fullname="S. Stuart" initials="S." surname="Stuart"/>
          <date month="June" year="2016"/>
          <abstract>
            <t>This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7854"/>
        <seriesInfo name="DOI" value="10.17487/RFC7854"/>
      </reference>
      <reference anchor="RFC8671" target="https://www.rfc-editor.org/info/rfc8671" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8671.xml">
        <front>
          <title>Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)</title>
          <author fullname="T. Evens" initials="T." surname="Evens"/>
          <author fullname="S. Bayraktar" initials="S." surname="Bayraktar"/>
          <author fullname="P. Lucente" initials="P." surname="Lucente"/>
          <author fullname="P. Mi" initials="P." surname="Mi"/>
          <author fullname="S. Zhuang" initials="S." surname="Zhuang"/>
          <date month="November" year="2019"/>
          <abstract>
            <t>The BGP Monitoring Protocol (BMP) only defines access to the Adj-RIB-In Routing Information Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Adj-RIB-Out RIBs. It also adds a new flag to the peer header to distinguish between Adj-RIB-In and Adj-RIB-Out.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8671"/>
        <seriesInfo name="DOI" value="10.17487/RFC8671"/>
      </reference>
      <reference anchor="RFC8955" target="https://www.rfc-editor.org/info/rfc8955" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8955.xml">
        <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" target="https://www.rfc-editor.org/info/rfc8956" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8956.xml">
        <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="RFC9069" target="https://www.rfc-editor.org/info/rfc9069" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9069.xml">
        <front>
          <title>Support for Local RIB in the BGP Monitoring Protocol (BMP)</title>
          <author fullname="T. Evens" initials="T." surname="Evens"/>
          <author fullname="S. Bayraktar" initials="S." surname="Bayraktar"/>
          <author fullname="M. Bhardwaj" initials="M." surname="Bhardwaj"/>
          <author fullname="P. Lucente" initials="P." surname="Lucente"/>
          <date month="February" year="2022"/>
          <abstract>
            <t>The BGP Monitoring Protocol (BMP) defines access to local Routing Information Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Local Routing Information Base (Loc-RIB), as defined in RFC 4271. The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9069"/>
        <seriesInfo name="DOI" value="10.17487/RFC9069"/>
      </reference>
      <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="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
        <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="RFC9256" target="https://www.rfc-editor.org/info/rfc9256" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml">
        <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="I-D.ietf-grow-bmp-rel" target="https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-rel-05" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-grow-bmp-rel.xml">
        <front>
          <title>Logging of routing events in BGP Monitoring Protocol (BMP)</title>
          <author fullname="Paolo Lucente" initials="P." surname="Lucente">
            <organization>NTT</organization>
          </author>
          <author fullname="Camilo Cardona" initials="C." surname="Cardona">
            <organization>NTT</organization>
          </author>
          <date day="2" month="March" year="2026"/>
          <abstract>
            <t>The BGP Monitoring Protocol (BMP) does provide for BGP session event logging (Peer Up, Peer Down), state synchronization (Route Monitoring), debugging (Route Mirroring) and Statistics messages, among others. This document defines a new Route Event Logging (REL) message type for BMP with the aim of covering use cases with affinity to alerting, reporting and on-change analysis.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-grow-bmp-rel-05"/>
      </reference>
      <reference anchor="I-D.ietf-idr-sr-policy-safi" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-13" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-idr-sr-policy-safi.xml">
        <front>
          <title>Advertising Segment Routing Policies in BGP</title>
          <author fullname="Stefano Previdi" initials="S." surname="Previdi">
            <organization>Huawei Technologies</organization>
          </author>
          <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
            <organization>Cisco Systems</organization>
          </author>
          <author fullname="Ketan Talaulikar" initials="K." surname="Talaulikar">
            <organization>Cisco Systems</organization>
          </author>
          <author fullname="Paul Mattes" initials="P." surname="Mattes">
            <organization>Microsoft</organization>
          </author>
          <author fullname="Dhanendra Jain" initials="D." surname="Jain">
            <organization>Google</organization>
          </author>
          <date day="6" month="February" 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, each comprising one or more segment lists. A headend can be provisioned with these candidate paths using various mechanisms, such as CLI, NETCONF, PCEP, or BGP. This document specifies how BGP can be used to distribute SR Policy candidate paths. It introduces a BGP SAFI for advertising a candidate path of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute to signal information related to these candidate paths. Furthermore, this document updates RFC9012 by extending the Color Extended Community to support additional steering modes over SR Policy.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-idr-sr-policy-safi-13"/>
      </reference>
      <reference anchor="I-D.ietf-idr-flowspec-redirect-ip" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-redirect-ip-16" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-flowspec-redirect-ip.xml">
        <front>
          <title>BGP Flow-Spec Redirect-to-IP Action</title>
          <author fullname="Jeff Haas" initials="J." surname="Haas">
            <organization>HPE</organization>
          </author>
          <author fullname="Wim Henderickx" initials="W." surname="Henderickx">
            <organization>Nokia</organization>
          </author>
          <author fullname="Adam Simpson" initials="A." surname="Simpson">
            <organization>Nokia</organization>
          </author>
          <date day="21" month="May" year="2026"/>
          <abstract>
            <t>Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications, but the primary one for many network operators is the distribution of traffic filtering actions for distributed denial of service (DDoS) mitigation. The flow-spec standard, RFC 8955, defines a redirect-to-VRF (Virtual Routing and Forwarding) action for policy- based forwarding. This mechanism can be difficult to use, particularly in networks without Layer 3 VPN infrastructure. This document defines a new redirect-to-IP flow-spec action that provides a simpler method of policy-based forwarding. The details of the action, including the IPv4 or IPv6 target address, are encoded in newly defined BGP extended communities [RFC4360].</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-idr-flowspec-redirect-ip-16"/>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1a23LcuBF951dg7YfYW8Mpy+urarO7siWvldItkmyX4/ID
hsTMwCIJBiBnPN7yv+Rb8mU53QBvo5Fs7Sap3VReJA4BAt0Hpy9oII7jqNJV
prbFgZmJQ2OVODV1pYuZ2FuoonJCF6KaK/Hs5xM0F7oylhpPrKlMYjJx59nh
yd1ITiZWLbbFJC9jq7JYFXNZJCrHCFFqkkLmmCG1clrFM1XM4pk1y3hD5/je
/chMnMlUpdx2VJep5Af6tx0l+DszdrUtXJVGrp7k2jltivNVieH3985fRJEu
7baobO2q+/fuPcVw0iq5LY5PzqKlsReYuC63xc+nx2+iC7XCqxRfFpWyhari
XZIwimRdzY3djkQcCejvtsXRWPwMufHTq3Iki+aFsTNZ6E+ygiDb4mUtl0rj
tcqlzrYFaVvI4qc5vx8nJkdboivo8EzpD5qHSExdVKTW87kuZG/at5hWmnbW
t/UHLcOb4bR/m5tiNqsBY12IAzkxVmKhVj05pFl9+OnTLMnkZKzSepwUNxHk
bIwpMHyHwNm8LpZAoX19PQ6fuJvzH/1KNF6OxZu+CC+lnpjm1fXTW4kRaLHH
mH52o/mjwtgcwy5AQCFOXzx//OThg/D45NHjrebx6cOH3eOj8Pj03qOn4fH+
1lbz+GTrcTPC0/u+7368O9aqmg4sY9CgUxs7G5cm08kqdnKqLzVPM7N0pUrw
baqtSqpYl9vRbaA37XSIxuNxFMVxLOTEVVYmIPz53Ju98kZPvmBGVn7ndO/g
rsiVc3KmhHYiVVNdqJScwi+/bJT58+eRWM51MheqkJNMOZF7r4GvLE1hnaiM
sKo0thKKpotTC8kKYUplef1kJmDwkvrBu2BBsgzKGOvGJCqJYZKa3EWQxwmZ
pjp8yUPim1SJ0mjyYFCe3dcLwHMGeMS7sF7vm6dH74UsUu50dipOCGKNUXsq
Xkb/8+exAG5OCfWxUgX5ISeCK2t0JgwX2umJzkAyFsSPgG9UUpPEYgqC1pZ0
gAQ6L61ZKAFnRN6qg4RbKwBIkM6NYQ+dyFLy0BA2rGmu0zRTERYdTs2atE74
619uO9BC06vPUUR67qQf4tP9Z/F+McJyJ/Q84kmahuO6EvCd5MFIBixfNcf8
sznDxEsJLRLoC2rQhzbEjaAhFElAHLxhnK4PINR7oVOgAJssrZoToIsBjs0q
doLz6pE1vh9xS1CDX5PhvR+1q9pX6l0w3PfjryX+17DeW4fTM+oI4qYqgwJ2
yPCprLNKZGbmV9vC0ehcIZrJqnadmRIrrMlbFqRqoYFlYw89UJyymIQWH3Dk
4Lwtmq/caEj6dYKveHWXAD1bYYYyMytITijDKUynOhFTncFcMc1INA6lYaJT
M7a/Zs2bTxDtgBR/NBYvzRLa2xFooh13I+mBLIAl3miXO5HJhBRMdcIc89ab
hWUgaUCIvDMT4RL4FauNE2ZKiQnsT6YLMjqv3lQBS6suuwpXl2XGSYYDREuW
w89WIX1gcBNDK4afECaDe2TPn3UWihmvh3REmGUMyHxA3pks+9afGLLEjAfA
66W0KfXqnIIsDGb2Zn37tjhVf6+Bvxf+ABZXg5aevUhiBAU2J24dvjo7vzXy
/8XRMT+f7v311f7p3i49n73cOThoH6LQ4+zl8auD3e6p+/L58eHh3tGu/xhv
xeBVdOtw5+0tb2K3jk/O94+Pdg5u+XSxjzuxDNhOED8ozYJx0zpLF8FaEqsn
3q6ePT/55z+2HsC+vgmxEiblf1C0xI8lfIKfzRRgrP8JmFeRLEslLY0is4yc
oq5kBvpLJ+Aql4WYK6sA5LfvCJn32+L7SVJuPfghvCCFBy8bzAYvGbPLby59
7EHc8GrDNC2ag/drSA/l3Xk7+N3g3nv5/Y8goBLx1pMff4goEAwoO0juxV4b
uaLvv0H0oD3Ajrfy84PXXx/wie1TbV0lJqtKtVGZXhdsjsFYG8MekcNRBZPe
+P1FF7D7wZzTgFxS6MygwtjPxM8cAHtRnnjWSNuP+JQQXWIl0qBvxfmz3S3x
ZxhXSJYqE78+fRG/gLl3IavJqVoXSGRGNyE9TkOM2sxiLPYraqudDwfd1xiX
xtNTTS3Bb0IDI6R4rW1VQ+1mlYjtLzr/cAfz3qVcuOIko5rLCuBUyZyDs2JZ
m8ETjiN/cuIoBJEDuYJzO1USrjfkI/u9gHPn6OB0/67Xm9RrZ2H0AYlIazbk
BXlfRCtsqxyIMxY7wB6/HELbqN0qtoRbwiHy9+4SDK3oAQS099BJBmKMxS5R
gRwnpfKY8dX5i/gJQif71+XcIBAsZAYZE+xK4G3ChoDYYBXFuAkiXkEZlo8C
XVqFZcqVLHhlZ5R19AjYj8nYViF9WM5XDZXFEi4mlyk7F6LT/TU6HSE1nJvy
ayi1f7KZUWs56KYUnzLRG7GNuVZJO1MV5l08IIWxgAhwdtDwqG34j1ENQQBM
9+/XRVlr66RpKTllgYmRCnPAx7Sk/COw5bs1tpydxj6NCHz5I+jwADq0XvY1
UpbUfzlk/KYeJ7Q/SCk2XOlCf9cAiDj+wadgvy5qenRuEjV9uupzoKtj5HWh
Ncx5o/h59tviZzuEHXb7Yvzk7N0n6Lrw24PghyjaJAqrln5xdBCjMBVxA47D
ZPhk5ENKltEj1PQ5t0obsLpqhd91+R0RGoJbvFGIHlMTppDEwNFgmPUQCxHr
Qi6AHVVNRJg0MRaCl8avZ+vWg3a90MwmkRnat/Q33pstKNVyVhg41yQY083i
10bQf2P8+vWr3U38719sjkh4xdGnABgCaNwY1S/5+ZvpHpTl9gYHNwjtRW+P
/9sx2cBhq6bYUfGWu5tpM4npLQkQ6jvQqHbc1tv2TtRcLjQ6056OJ1hXFvgE
Vqv0xvA3IYoGjLsAdBWpF12IKr8com7IWy41hWy4r+fGSa9ckP6kEIyLK/AK
XDNqixUshEmSmnDVmfLeAUHRE4F3YYEJ/NxSgb1aJ1rDLL8UN0GfoL2ileSm
ckCR+oS1pUcvDA+idtzuCgZVMq5WDYqilApzyRddaBYiX5cBT1bDODYWb4hz
LWU9vy+LG7bwTckiRGXytj7j9Ggn0ifgaAyVJa57tBVUz7ZeutDb9Pajfyh5
OZUjRdFJU+oKRfOmSjZuNvedDV65u//9b+xvlpj0q/RX5SYPYff7BVtW/Bxh
mgxMxSeyml9vtknTV5ToS1iB7Q7stAwXD+jl5Uftdx6bvhtUuM5C+fQh9X4X
jn5+90luwPJRD8szX/uND+B3rkeyqRJn6HkVRl+H7WCk/ylkHwPZvY+JUvCE
MYeoA53r6gvSY94GbYHQmfF0ZApJVodSMg3ZVqLlR53XuSjqfIKdOWDqGxBs
KqypoDV1/3fd/wXXzfVW4uqT7+75reRtcdw7AH0e7MKvrO9+tHYedEeNZ+NR
e6zKBzNLTUUad7fJPtaSD9+rixjhJeUQQIfzwEl7PpFh1DA85XzhEJarROkH
mRBM5IxL5Y+g3jTpm4c3pNSpqjhDbc48ykwWqp/wKGvDqL2c0Pfqn5LWWTjK
vbQLYEtLvAUQl/vJb9/bdBsjZD6Vr0zSdwuydaSzsnR1Rr0v77z8wR0dFDF+
PZb1OR2quN0plz8+5KM+f94dSpzAYqpnNTk96uxP8YDg2uled/DdsBjqGpv6
CgBYsvqkwhkYn0GnqjuFVf72DgEGnmcxHzTKTNrcn6FMp3xM4BUL+mg3Fp6L
O5e3RhSsb8QpTkevZdLoCiqJlklrHJLtMaBPaRsWUbZh2wS3W2eMQV4+COT3
dhpTOmcSzeeNgTdMCL9GbsPye5dwzcpvXtdNS4n9j0+w11jy9as/apbeV4JY
0oa21zABjmEeXFGmFhS8aD6/JMOTSdrnLge+tb3p4IcK8ZI95gaCNWWRqzgG
epVYo9LSEpDnZQiDjuSh5QUmZwlKnVxw5WOoS3uBhA/5aGMeY2MuPA6pCNfG
mLIlX4JQYq7kYtWaZGZk6pqySXPMzrshX68ei0MEs5lfXIR6x1uqTsT2vBzN
EwNgvTiN5t5O+ICeLjWsbaG9e8QihQSX4JRlSU6IedaeuzfW40aB78H+LKmm
OTNYI2qP+r0zdsCFxzSjgAVyVBrTz/VsHi9Mhlgapp3UyPOdmFmY47SGIYU8
oDG5gH1v4zA86E0NR2zfTrneWu2KT9dXTd7Ce0kf8IjhyAHqLCVKNTRuVnqm
8MJ6+hp+JN4Osiwg7jHt3yCiSxXK38QAmjnJBErxAIOAnJCATZUBhp1RBQ0S
hA0WkkuwBHnoMCCHGzUutH5ev22gC0ykyWVhvKYXJu2d43vjHQzafD7Ma7e2
msSWL7uMw6UoH06dcv7qUSAnH46DoYq4jHSZDmwmILgie66hOaUl3vXxjaLa
0XPP7fQumwAHZkZd+BuRnBvLJOETIdOzG7o+SQlVsNLe4lyfSxL3rdVe3dZx
tTczvAWHHBiaAiuK1n7z6OpkTtZPlVS6DwgjCT4MgEJJJI0hJ2rkbI6PoNZU
fySz7PhHm0yiaJ73E1s0A03tDPvXNf/MUnhrJ224LMvQlEQ3vypQ/8jwdZOy
ue/EaPXSlcYl0e0dL4cON7d6RtZeMWNPDPkRmUcwt37W3bFMu4tLI03UyhQ+
wZ1Ip9gxk0KNXEz2/Z2jnc1E14g5l0hOdFbkM/g7yn0cXYCCJHTZibTu7+Ob
i8SHJ+snJqdqRvnnakja1TVnJ55VYX424q7IwDIEEwMG0oW6gtuOonjjaYW4
Q0cZd9da+8Vv7nF/vcewkMt9vqM+V1UbuccD6rG5LsHtD/vt/b02tz6i1g37
RW58fBehdQp6MQWRQK9dhGQ4MnKVFRV/yTXhKxiZvSBb4YSYK8XIvgP7XD1x
hDL793bZ6U6jZ/dtrONFYZaZSmfer0XRoSxoryaLC9clRrlfEU4K/6Km2GGv
xEspvYUeSSudzudSnOBBpuEy40QmF9G/ALYpZLmjLgAA

-->

</rfc>
