<?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-zzd-idr-flowspec-scheduling-03" category="std" consensus="true" submissionType="IETF" version="3">
  <!-- xml2rfc v2v3 conversion 3.29.0 -->
  <front>
    <title abbrev="BGP FlowSpec Scheduling">BGP Flow Specification Extensions for Scheduling</title>
    <seriesInfo name="Internet-Draft" value="draft-zzd-idr-flowspec-scheduling-03"/>
    <author initials="L." surname="Zhang" fullname="Li Zhang" role="editor">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>Beiqing Road</street>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>zhangli344@huawei.com</email>
      </address>
    </author>
    <author initials="T." surname="Zhou" fullname="Tianran Zhou">
      <organization>Huawei</organization>
      <address>
        <email>zhoutianran@huawei.com</email>
      </address>
    </author>
    <author initials="Z." surname="Li" fullname="Zhenqiang Li">
      <organization>China Mobile</organization>
      <address>
        <email>lizhenqiang@chinamobile.com</email>
      </address>
    </author>
    <author initials="J." surname="Dong" fullname="Jie Dong">
      <organization>Huawei</organization>
      <address>
        <email>jie.dong@huawei.com</email>
      </address>
    </author>
    <date year="2025" month="July" day="04"/>
    <area>General</area>
    <workgroup>IDR</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 48?>

<t>BGP Flow Specification allows conveying flow specifications and traffic Action/Rules associated to perform different actions based on the traffic features. One of the applications is to steer one specific flow into its specific path. However, in some scenarios, the traffic forwarding paths are not constant and change over time.</t>
      <t>This document extends BGP Flow Specification with scheduling time information to identify the packets arrived at different time slot. Based on that, the headend can perform different actions at different time for the same traffic.</t>
    </abstract>
  </front>
  <middle>
    <?line 55?>

<section anchor="intro">
      <name>Introduction</name>
      <t><xref target="RFC8955"/> and <xref target="RFC8956"/> define the BGP <xref target="RFC4271"/> Flow Specification (FlowSpec) that allows conveying flow specifications and traffic Action/Rules associated. BGP Flow specifications are encoded within the MP_REACH_NLRI and MP_UNREACH_NLRI attributes <xref target="RFC4760"/>.  Rules (Actions associated) are encoded in Extended Community attribute <xref target="RFC4360"/>.</t>
      <t>The existing traffic filter rules and actions in FlowSpec are always effective and will steer specific traffic into one path once been delivered to the headend. However, there are many scenarios that need to schedule routing paths in the network.</t>
      <t><xref target="RFC9657"/> introduces a set of use cases where the topology of the network changes predictably. The topology change may cause some of the paths invalid, and lead to path reselection or even recalculation. However, the reselection or recalculation takes a period of time, which will affect packet forwarding and cause problems such as packet disorder and packet loss. However, on a network with predictable topology changes, if the ingress node knows future topology changes, it can schedule the forwarding paths in advance, and steer flows to different set of paths based on time to prevent packet forwarding from being affected by topology changes.</t>
      <t>Another case is in tidal networks, the traffic in network changes periodically(e.g. IP carrier backbone network). In some rush hours(typicall 20-22 o'clock), the increased traffic may lead to network congestion. One possiable solution is to divert some traffic to onther paths or limit the bandwidth of some flows to reduce the congestion in ruch hours.</t>
      <t>This document extends BGP Flow Specification with scheduling time information to identify the packets arrived at different time slot. Based on that, the headend can perform different actions at different time for the same traffic.</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="scheduling-time-information-in-flowspecv1">
      <name>Scheduling Time Information in FlowSpecv1</name>
      <t><xref target="RFC8955"/> defines 12 Components to identify different traffics. Based on <xref target="RFC8955"/>, this document defines a new Component to identify the arrival time of packets and perform different actions.</t>
      <t>Encoding: &lt;type (1 octet, TBD1), length (1 octet), scheduling time information (variable)+&gt;</t>
      <t>Defines the time information that matches the arrival time of packets. This component matches if the arrival time of an IP packet in the scope of scheduling time information.</t>
    </section>
    <section anchor="scheduling-time-information-in-flowspecv2">
      <name>Scheduling time information in FlowSpecv2</name>
      <t><xref target="I-D.ietf-idr-flowspec-v2"/> specifies BGP flow specification v2 to address the issues detected during the deployment of BGP flow specification v1. It defines that the traffic filters are described in the format of sub-TLV and different traffic type have different filter sub-TLVs. This document defines a new sub-TLV for IP filters and L2 filters defined in <xref section="3" sectionFormat="of" target="I-D.ietf-idr-flowspec-v2"/> to identify the arrival time of packets and perform different actions. The format of Scheduling Time sub-TLV is shown as follows:</t>
      <t><xref target="I-D.ietf-idr-flowspec-v2"/>  specifies BGP flow specification v2(FSv2) to address the issues detected during the deployment of BGP flow specification v1. It defines that the traffic filters are described in the format of sub-TLV and different traffic type have different filter sub-TLVs.</t>
      <t>For the IP and VPN IP filters, FSv2 reused the components defined in <xref target="RFC8955"/>, <xref target="RFC8956"/>, and <xref target="I-D.ietf-idr-flowspec-srv6"/>. Therefore, the new component defined for FlowSpecv1 in Section 3 is also applicable for FlowSpecv2</t>
      <t>For L2 Traffic, this document defines a new sub-TLV for L2 filters defined in <xref section="3" sectionFormat="of" target="I-D.ietf-idr-flowspec-v2"/>  to identify the arrival time of packets and perform different actions. The format of Scheduling Time sub-TLV is shown as follows:</t>
      <figure anchor="ref-to-fig1">
        <name>Scheduling Time Sub-TLV</name>
        <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Length    |   Reserved    |Schedule Number|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                Scheduling Time Information                    /
|                                                               |
]]></artwork>
      </figure>
      <t>Type: TBD2</t>
      <t>Length: the size of the value field in octets, variable.</t>
      <t>Schedule Number: indicates the number of schedules.</t>
      <t>Schedules Time information: one or more schedules, each schedule indicates when one or more time slots.</t>
    </section>
    <section anchor="scheduling-time-information">
      <name>Scheduling Time Information</name>
      <t>The format of Scheduling time information sub-TLV is shown as follows:</t>
      <figure anchor="ref-to-fig2">
        <name>Schedule of SR Policy</name>
        <artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Schedule-id  |    Priority   |    Reserved   |   Flags   |P|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Start Time                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Start Time                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      End Time (Duration)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      End Time (Duration)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Frequency (Optional)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Recurrence count(Optional)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>Schedule-id: 8-bit value, the unique identifier to distinguish each schedule within a FlowSpec, this value is allocated by the FlowSpec generator.</t>
      <t>Priority: 8-bit value, this field is used when there are multiple schedules valid at the same point. The higher value indicates higher priority and the default Preference value is 10.</t>
      <t>Flags: 8 bits, currently only 2 bits are used, the other bits are reserved.</t>
      <t>P (Period format): one-bit flag to indicate the format of a period. if P=1, then the period is described by a start time filed and an end time field; If P =0, then the period is described by a start time field and a duration time field.</t>
      <t>S (Schedule type): one-bit flag to indicate the type of a schedule. If S=0, it indicates the schedule only has one instance, the Frequency and Recurrence count field should not be included in the sub-TLV; If S=1, it indicates the schedule has multiple instances, the Frequency and Recurrence count field should be included.</t>
      <t>Start Time: 64-bit value, the number of seconds since the epoch, it indicates when the FlowSpec start to take effect.The epoch is 1 January 1970 at 00:00 UTC.</t>
      <t>End Time (Duration): 64-bit value, if the flag P=1, then it is the number of seconds since the epoch, it indicates when the FlowSpec becomes ineffective. If the flag P=0, then it is the number of seconds since the Start Time, it indicates how long the FlowSpec take effect.</t>
      <t>Frequency(optional): 32-bit value, it is the numbers of seconds since the Start Time of an instance to the Start Time of next instance. This field indicates the recurrence frequency for all the instance of this schedule. This field should not be included if S=0.</t>
      <t>Recurrence Count(optional): 32-bit value, it indicates the number of occurrences. For example, if it is set to 2, then the schedule will repeat twice with the specified Frequency. This field should not be included if P=0.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>These extensions to BGP FlowSpec do not add any new security issues to the existing protocol.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is requested to allocate a new type value for "Scheduling Time Information” Component in “Flow Spec Component Types” registry:</t>
      <table>
        <thead>
          <tr>
            <th align="left">Value</th>
            <th align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">TBD1</td>
            <td align="left">Scheduling Time Information</td>
            <td align="left">This document</td>
          </tr>
        </tbody>
      </table>
      <t>IANA is requested to allocate a new type value for “Scheduling Time sub-TLV” in “L2 Flow Specification Component Types” registry:</t>
      <table>
        <thead>
          <tr>
            <th align="left">Value</th>
            <th align="left">Description</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">TBD2</td>
            <td align="left">Scheduling Time sub-TLV</td>
            <td align="left">This document</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <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="RFC4760" target="https://www.rfc-editor.org/info/rfc4760" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml">
          <front>
            <title>Multiprotocol Extensions for BGP-4</title>
            <author fullname="T. Bates" initials="T." surname="Bates"/>
            <author fullname="R. Chandra" initials="R." surname="Chandra"/>
            <author fullname="D. Katz" initials="D." surname="Katz"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <date month="January" year="2007"/>
            <abstract>
              <t>This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4760"/>
          <seriesInfo name="DOI" value="10.17487/RFC4760"/>
        </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>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC4271" target="https://www.rfc-editor.org/info/rfc4271" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml">
          <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="RFC4360" target="https://www.rfc-editor.org/info/rfc4360" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4360.xml">
          <front>
            <title>BGP Extended Communities Attribute</title>
            <author fullname="S. Sangli" initials="S." surname="Sangli"/>
            <author fullname="D. Tappan" initials="D." surname="Tappan"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <date month="February" year="2006"/>
            <abstract>
              <t>This document describes the "extended community" BGP-4 attribute. This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4360"/>
          <seriesInfo name="DOI" value="10.17487/RFC4360"/>
        </reference>
        <reference anchor="RFC9657" target="https://www.rfc-editor.org/info/rfc9657" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9657.xml">
          <front>
            <title>Time-Variant Routing (TVR) Use Cases</title>
            <author fullname="E. Birrane, III" initials="E." surname="Birrane, III"/>
            <author fullname="N. Kuhn" initials="N." surname="Kuhn"/>
            <author fullname="Y. Qu" initials="Y." surname="Qu"/>
            <author fullname="R. Taylor" initials="R." surname="Taylor"/>
            <author fullname="L. Zhang" initials="L." surname="Zhang"/>
            <date month="October" year="2024"/>
            <abstract>
              <t>This document introduces use cases where Time-Variant Routing (TVR) computations (i.e., routing computations that take into consideration time-based or scheduled changes to a network) could improve routing protocol convergence and/or network performance.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9657"/>
          <seriesInfo name="DOI" value="10.17487/RFC9657"/>
        </reference>
        <reference anchor="I-D.ietf-idr-flowspec-v2" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-v2-04" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-flowspec-v2.xml">
          <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-srv6" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-srv6-07" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-flowspec-srv6.xml">
          <front>
            <title>BGP Flow Specification for SRv6</title>
            <author fullname="Zhenbin Li" initials="Z." surname="Li">
              <organization>Huawei</organization>
            </author>
            <author fullname="Huaimo Chen" initials="H." surname="Chen">
              <organization>Futurewei</organization>
            </author>
            <author fullname="Christoph Loibl" initials="C." surname="Loibl">
              <organization>Next Layer Communications</organization>
            </author>
            <author fullname="Gyan Mishra" initials="G. S." surname="Mishra">
              <organization>Verizon Inc.</organization>
            </author>
            <author fullname="Yanhe Fan" initials="Y." surname="Fan">
              <organization>Casa Systems</organization>
            </author>
            <author fullname="Yongqing Zhu" initials="Y." surname="Zhu">
              <organization>China Telecom</organization>
            </author>
            <author fullname="Lei Liu" initials="L." surname="Liu">
              <organization>Fujitsu</organization>
            </author>
            <author fullname="Xufeng Liu" initials="X." surname="Liu">
              <organization>Volta Networks</organization>
            </author>
            <author fullname="Shunwan Zhuang" initials="S." surname="Zhuang">
              <organization>Huawei</organization>
            </author>
            <date day="12" month="May" year="2025"/>
            <abstract>
              <t>This document proposes extensions to BGP Flow Specification for SRv6 for filtering packets with a SRv6 SID that matches a sequence of conditions.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-flowspec-srv6-07"/>
        </reference>
      </references>
    </references>
    <?line 193?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+Va624bNxb+L0DvwHV+rL21VEl2nES9Or40LhzbKykF2sWi
oGYoic1oOCE5VhQ7RR9kF9hn2Ufpk+w5h+RcJNlp2nSx2DoIPMMheW7fufDQ
rVar2bDSJqLPnn51xU4TtWDDTERyIiNupUrZyWsrUgNPhk2UZsNoJuI8kem0
2eDjsRbX5UpcWJsQqyjlc9g71nxiW2/exC0Z69YE5hqY2zLF3FZnr9lQY6MS
YYXpNxt5FnP3hL/hF7Ajpkov+8zYuNkw+XguDfI1WmZA4exkdNpsNBsy031m
dW5sr9N50ukBl1rwPvtKpELzpNlYKP1yqlWewZrjQbPxUixhKIa31AqdCts6
RmZxL57bmdJAm4GWGJOp6bPzNvtuxlE4xpxs57IcUXrKU/mGNNdnz3K+EBLH
xZzLpM/e4LxE7u3vfzmjb+1IzfG7VmgBEUurNL4bq4WwoFkhX4F22EDxGMcj
aZc0+oN0BCOVpxaVcjSTKa9xOkJOVV4yOpI81TwtRt/JrMqtW1LntiTxXRuk
Lwl8NxPpK1gx9aN1AsQhe67GMhEVMol8E5Z9GeGUOc1Yo/V1mx2rqt6/lqIY
eYcoP0jRjmFqTY5mI1V6DkuuEV6AnHRSe2+32/ir1WoxPgaD8IhA0Wzc4Sg8
QViDRdJrsUSjIcyZqc4xjKcxoJNPYIQdRjj28SBPBHwwRkUSMA7fFcuERmZY
LCcToUVqGY/cBmNuYAqQszNR7DQR3OZamDa7TAVTE/rIsywp6EqD2xorhIbF
omDLMSlT+CitKYczbmdt9kwtxLXQuzCBGTWHZZFIuZbK7NbpK73gOkahcSFI
owVLlUVlGMuRfZA7QvQDe7Ajs3IuSL2jGbAGcSKfo5QCg01s7opFC2lnrAwa
tAsr7IZKATFi2EhOlsRgxqOXwiI/GswaM24rKqXVJlG2zZ6WWuXWyTYTHHYC
rsFj7jbH+oYYJHG9AZAGBRVAmss4RvQ3Gw8w3mgV57QRu3kg8fUtfrq5+dPg
9Ojxk4cP374lxRUDBzAQi4kEAyIJ1NLNzRfwbb/3qAvfNqhsOwTmHZLtg6G0
XdpodTHYXqSRikGjaDDpsPr86vvByeHRs+8vzgdnRAFGXlxUx6zVcpxD1PcS
7z866Lx922bMEd8+DEovuNipUZM+W+HzkZrP8xTCZblt0NUe7erAB4tfS2MJ
TAHMMoFEwLQTGPgMtobtiyyHZHmy4EvDBJg/wqhBkxcySbyfFc4UdiY3Q+9D
J4GHSLCxECmYNIHl2rl+BXsVB4RRpAj/5zxdln7ojJoKt9a7hoB8ktvSG70F
ILdh8ms7jKEqnhw8fASwkR6JKC8zwmIEyY0A6BsYWhBpcneVqURNlyHC+A29
YxuWgQgysnycLNtsVF3gXX/O4ZHj1hRN/DaByWueyHiXtJiAAigOoqIgsIlE
OD8B5wKFpDAW8STKE8JcXU+r82tTmeUvSUxwaaliYgG8dheklNHMWY+TQX3s
qMY2CmLEfqbVOBFzCJg5rOImTI6lgVoCbI9T/ViijKlwiJmi0BwFtFJtaxqD
OCudkoA+yGUgqsaCvUzRhyc5Bv1NSyxFrQINuH4tRAMoeHzNAYRO5Q6zVJqh
5suo5gHhVpXpB2MdWkijPTZpa6LVHPBNiiONwsLxco1dguMhJAuAGSEOcxUi
VsY8CYpayTfweQ17ZE8IQkmy3BbtaZudXcF2EPdh2zEwN0bH86t24KvPaFAp
zhhUOtps22VG61mv0+r1mPpzlKjo5c6u138EdSQKH5hAMAecFtwoZMZhElNx
BraXZFiobHMCoPTqBTBYx0LYkIIDqcHpGrCbyDkYE+mPwUYLGWPcmLhlhakA
PuC7NKukjzrSCE6S7Q+WaiG9PmAD8SqXWqCwhp0DSnI+FSHqQ9XPsOw3bOv5
i+Foa9f9ZheX9Dw4+euLs8HJMT4Pnx2enxcPDT9j+Ozyxflx+VSuPLp8/vzk
4tgthlFWG2psPT/8dsu53Nbl1ejs8uLwfMuF6Kp5OHk2+A9GZ6HBzdB/uGnE
wkSQz1y6e3p09e9/dfd9vux1u08gnPtyoftoH14geqeOmkqTpX8FpS0bUB8K
rikOAOYjnknLE3A0iGZmphYpw7jfbjT+8jfUzN/77NNxlHX3P/cDKHBtMOis
Nkg6Wx9ZW+yUuGFoA5lCm7XxFU3X+T38tvYe9F4Z/PSLBMuqVvfxF583PIYq
Z1k4PAHGzir4r1QD190ypfqyzVVphnV7WIlkEHsQhVWfqWDZIddUfKO61+4K
MsLWmEUW5e5rDkmOCCGUXIUCuHdQTE13eRm5zwnWUyA0aAdiomDbXaYgfIO3
jp4edyEgJiKdQngI4zByX6TYvoZSBYPgzkef4/bHXgCK6GthBesZeIb9zH1i
YIEhsY4N4oc1Pl+uLoPQAgnBZylfEJlIZfTxHu7ba0hYY7mKhJ5HwlnruC2F
ndT7Hdc9gIYvC4ULvevlN7vuoS15HFPCp+RjTA7zY4gBlEbjXBMn8CkWWaKW
BAwQ5K4du5DwSuSQjmvnNyp5Xeleiy++cgBBSU35uDU6/4YQtAZfRlCZcaiD
y2++lvYLg9HugHLYHsM62KpgCqid94pXt4a4u7kZ+jJvD9m7T+kfxjmoqC31
sRoeggAyRFCOPTM6cPXfjYtfAozt0+F1b+f/Fh6opFOf1AEBuNE3VxcVMOwy
VABUPDlVYlTxFNG1hoxq/CzeDvDNnajvsITR1wd45Bxh8gPRxK4/6SwqoSYQ
QqCWOQDplngEDEA2VaELgyVgbXovyArQHjkV3R/oq97xm93hf8Mffvzxx2aD
ddj6T3fDWG/D2B6t78K3PbbPHrID9og9Zk/eZ6zZ+Kj1G/81G7fEDXaiHV/u
/dylSf8+gGOpxsoY34fhbHaRz8dC335ALn79D3Dx8erYfSXQhp+PPwgXBIyb
PnsAPtiyqjWRU0AE3VN8trXK0dChbIt6Z+4yAMoU8i9ngL5L9vJN0XEApOcA
XCkSchwqYiC2hDqF4tCKhfowEY+X1pclKY1Wigd/kg3LjGOuUif0qfUD3juH
sFKu2mWCR7PysF6SwVq9tqY4RZn1qmTVOOGgs9E710qYP5SnBhNBXPSeeqWl
0tgr9O8VV8X304RPDT5f3Q5/d08dWq6tM+e9PvL/zsUJZB6iv32ca0Lpzh+X
jVMtXuUijZZs+zJDJnhyBxu/HxcDEeUa0n8k3K3jfZx8GC42pIHeahqgmD4c
sCsFZdbSJYGKg/fZ49ZYWhfxXS2XpxJ0GcofbA9SP44uAXJpZivx2F9h8KJ0
82WayyFU5iUq4qG7CQSKS4Ip3TlbpSlchyCzxhLs4VORYVTXUuCvdPzzxMos
qeQMRq1y5st0an9lSqbWFWQzOcUmomewSCd+OAuxji556Igw4UABgqCg8i4S
pWzdjqvJMQAC3wz4hoTlcGCTpesp9WiYWEX2nZZdP7f4oH1EdZpg21eu/e4y
0A6lRlLKBChRcerZXjlihL59G4/5V591iZY7h/iGPhbQxREFDMKZoVDmGoYy
wSYa3umkDDuOfhSU/wk7gx3ZZ5333hItR1viucs3MYovriZg2wVa8Rj0Lnnp
qETSBou3kbshMiftSiFSAJVsMYPEjSWDpHvXyEO+DB/I6Kojexkg8efwC69t
qesYJXlcHvN8hfCJY6R7HyPIQ4HZwIh5f04qXDg1Fjmpzw72V926UpCJSGFn
28jUt8VFpqLZCsvByUp39VZVdEfkr/Xao7Cc3IF9zdOc6yXrPnnUQf/rdPqd
DnsxOvKNs7Vkscqqb0+R3UsAI2drdeWvFGMM6+bYCEuLm0mCT4Vs573Ilnpf
oQ2VIkuU7zQU9Kvao+ARTL6tQsLos71eTSkrfJh3MeI7egFc4d60PiEVr20x
xbeeQs1fBa4uUTgp4InHbOyLu7sfT4aOD1gjF25Z2fQu/yHHJU1U4H5EGfRe
hdxx3FBR2ATO39hAEK/5HDyNoOUUiTd2oJFeJZRV0hkIpUUmMHksZOQSnJvj
+09x6aW/UMArL+ADbIDklF2OVGogxTovMP40YoS7dnJ/TgYs1v5yLFa0N48x
ni5d0yNs51tc3s7FnX2mlVWRSjz1s8OLwzXKNAhCkEzG/4FNSNq+uUIR158K
QaVrZ8zKwernn/5ZabpDdPz5p38U92eVL3gSNThZiylwq5d0kLpl3xCVW3ZM
KYUAAG+DIvdC6XTbcj/h9/obTqJmPB5Q7j2i3660XG+Ri1+hEpDyjvYOyujU
cN7bdJP4X1ZJb5NKwvl2ozbCH+fgLXF4d//+A7LMh/4fKQAA

-->

</rfc>
