<?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.19 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-zzd-idr-flowspec-scheduling-02" category="std" consensus="true" submissionType="IETF" version="3">
  <!-- xml2rfc v2v3 conversion 3.24.0 -->
  <front>
    <title abbrev="BGP FlowSpec Scheduling">BGP Flow Specification Extensions for Scheduling</title>
    <seriesInfo name="Internet-Draft" value="draft-zzd-idr-flowspec-scheduling-02"/>
    <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="2024" month="November" day="03"/>
    <area>General</area>
    <workgroup>IDR</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 50?>

<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 57?>

<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, 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>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="motivation">
      <name>Motivation</name>
      <t><xref target="RFC9657"/> introduces the time variant network use cases, the tidal network is one of the typical time variant network scenarios. In the tidal network, the traffic volume varies greatly at different time. In order to reduce the power consumption, some of the links and nodes may be shut down when the traffic is at a low level.</t>
      <t>In this scenario, the controller can generate a FlowSpec with scheduling time rule to identify the packets arriving time and corresponding paths. The headend doesn't need to wait for the advertisement of topology change and just steer traffic in to different paths based on the flowSpec with scheduling time information, the affection of topology change is minimized.</t>
    </section>
    <section anchor="FSv1">
      <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(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 <xref target="FSv1"/> 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.</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<xref target="I-D.ietf-idr-flowspec-l2vpn"/>:</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-06" 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="16" month="October" year="2024"/>
            <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-06"/>
        </reference>
        <reference anchor="I-D.ietf-idr-flowspec-l2vpn" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-l2vpn-24" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-flowspec-l2vpn.xml">
          <front>
            <title>BGP Dissemination of L2 Flow Specification Rules</title>
            <author fullname="Hao Weiguo" initials="H." surname="Weiguo">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Donald E. Eastlake 3rd" initials="D. E." surname="Eastlake">
              <organization>Independent</organization>
            </author>
            <author fullname="Stephane Litkowski" initials="S." surname="Litkowski">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Shunwan Zhuang" initials="S." surname="Zhuang">
              <organization>Huawei Technologies</organization>
            </author>
            <date day="6" month="October" year="2024"/>
            <abstract>
              <t>This document defines a Border Gateway Protocol (BGP) Flow Specification (flowspec) extension to disseminate Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with L3 flowspecs. AFI/ SAFI 6/133 and 25/134 are used for these purposes. New component types and two extended communities are also defined.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-flowspec-l2vpn-24"/>
        </reference>
      </references>
    </references>
    <?line 197?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+Va63LbNhb+z6fAOj/W3lqqpThOol4dXxp3HMdrO51pd3Y6
EAlZiClCAUg7Suw+yz7LPtl+5wAgKcl2Nl33z1adTkgQODjX75wDuNPpJKUu
czUQL344Fvu5uRKnU5XqkU5lqU0h9t6XqnB4cmJkrDhNxyqrcl2cJ3I4tOqy
WUjr2t8zkxZyAsqZlaOy8+FD1tGZ7Yww1WFqx9VTOxv9xAydyVWp3CCpppnk
B/pnkIARdW7sbCBcmSWuGk60I4bOZlMQP9g7208SPbUDUdrKlf2NjecgJ62S
A/GDKpSVeXJl7MW5NdUU83dPkgs1w0iGl6JUtlBlZ5dYTBJZlWNjB4noJELo
wg3EYVf8MpaQRggvzKGuB4w9l4X+wHoaiJeVvFIaw2oidT4QH2hWrh9vbn4/
5k/d1Ezw2RrStsp0aSxeXWmVKqFFpd9BFeLEyAzDqS5nPPhW816pqYqSdLAz
1oVsMXhGDJqq5u9My8LKIg5+ikdTlX7BHJM19V+6ELim/ctYFe8w/dwPztNm
xsQrM9S5anbI9Ye46PuUZkx4wsI2P3bFrmkp+Uet4sD9ArzVqpthYpt7/Apj
J1hxCe9JdDFq3kTS7XaTpNPpCDmE6mUKqyd3uL7MyVWh+uJSzcg25LrCtec4
IYsMjidHGBHbKY19eVLlCh+cM6mG7+K7EVNliQ2R6dFIWVWUQqaewFA6TMF2
5VjVlEZKlpVVriteF0qYEX+U02le76sdkXWlUhaLVc2WZ1IX+KhL1wxPZTnu
ipfmSl0qu44JwpkJlqWqkFYbtz6/v7FX0mYkNC2ENFaJwpSkDFdKYh9yp+Ti
YA8URaknqiuS5GwMzhD61YSEVIQembsLXK50ORYNDjARURuMdAIpMhDSoxnz
N5XphSqJHQt7ZkKWLY3yapebsiteNEqVpRdtrCQogWkEx93WWCZIqEfrHTwz
6ie40ERnGZw9eURAYk1WMRHx8ZGm15sk+fjxLyf7O8+eP3lyc8Maqwe2MJCp
kYbliDjp5+PH7/Bts/+0h2+3KGs1guwaS/Vg7tltrLO4GEZXRWoy6JJMpb2T
vjr+9WRve+flr0eHJwe8A0beHLXHytLqYQUQDxJvPt3auLnpCuE3X92O6q65
WJvbTYfEQ887ZjKpCuBhQzbq6rGnSl6Hte+1K9mLohPrHPAurJcXbEYjg3qd
sGhXmV/JmRMKdk8JJ3jylc7zEF91EEXKHF4UdRQceEiVGCpVwKI5llsf8i2n
awUeRmlH/D+RxayJP2/TQvm1ISYUskVVNlEYDICMRRmtSw5Geni+9eQpfEYH
JyRphVMl4UblFDzeYeiKN+YgN1OTm/NZxJVALoSzE1MIoNNSDvNZV5y1F4SA
n0g8SiLNGBLIRBYvZa6zddZhDvEZ/UhNgDOVKx8iiCmoo8BYKvO0ytnh5rW0
OH9uqijlBYuJSNYmYxYQrOuQUqdjbzvJ5gyQ0UY0hi5mf2rNMFcTwGSFVdLF
yZl2qA9geZoaxnLjXItDyg+15hjHGrUtaSygKzaHUA5AmilxUVD0jirC+Vvm
65KRqnYEWr+EyvAHmV1K+J/Xt3dXrrBI7Q2SBW/wq5qMQ/hG5rFkjNtUNbJm
AtdmrbE6sXA4W2K3++fB/eTRI3Gi3lXaKpLUiUNooJLnyoMQSktBtaUTK6/e
nJ6trPt/xdFrfj7Z+/ubg5O9XXo+fbl9eFg/JGHG6cvXbw53m6dm5c7rV6/2
jnb9YoyKuaFk5dX2zyveDVZeH58dvD7aPlzxiNG2jGRvg00JLpSF6cmm0iWZ
cinQ1YPvi53jf/+rtxnQu9/rPQe+hOTVe7qJF8BJ4XczRT4Lr9DXLEGZoqRl
30QUpnKqS5nDoxFebmyuCkFABE3+7R+kmX8OxNfDdNrb/DYMkMBzg1Fnc4Os
s+WRpcVeibcM3bJNrc258QVNz/O7/fPce9R7a/Dr73JK8p3es+++Je9BhYwU
4738bvxmmCYvvERyoHIrIk2N56Fe05nM64+ws2nKxXI2Rbzlt9Op804Xtcsy
qflq8NLkVaAB3oBhssxnyyHDpDxuwsOAhhDFRy9A03LpWE2mJPn6XOKAgi58
giZgdJxe4J9uXGEHchhyrjmGNAesFIQsObArpxrgILh6FM3LgF2h1TwnBoAA
59wRooKQTQlwKxpZBt37YKieyvnEWED71BQNOvvcGeEnM8oVf20y/JXUZY0x
AHFlS+0YUlgtCxmXtniL7jYgfFOHzMP8Ir5TzrhXyhbmenV5lOeUu8wFlDvR
hZ7oD6gayZebbh99J8gdtCC8VWRd9lAT759e9m6ix4eS2FfATvT6VOVBe4yo
ba23PMzL7Fog36a1voBzkTQl6auG+pJJ2ZQxSjhFBhNT5r8rXUD4PapUITgi
HYGmxGpPGKRHJJ2zF7u9tXX4ZXEOjcdxjNyX8FY5QFE6rH0BmNgNzNcwMJcb
qVDEM6i5+0Qg/9PUH0TR4xo9unUZouPgONYAodJ0qZnyx3t4X/SEJYbbntBn
Dzjo7Ha1KkfzB0KXfbhEqLWVrx2WWxpx2V+FK/XXyJIyy7ig4uLKuQqrMuQz
LlOyyjI3+JSpaW5mMbbuotsDfjV+w1qea4m5m/BN0VyuDJUZhGVFVcPO2eFP
7D9LzivYVcYSLUbzLbQpYaEjKNsPuAB7EJ2fjo/oMXCwLkh+4GtFYeAxro4d
zz7zNR8d9dsWvfle9A47OHu5RW3VGSVqSKbWQ5tw1XKmuBFBWCvOeV8O9RtG
6dyZeG5BdfHc7L4X9LAvzrx67o/hqNmRXxPtMSfxaQCvx2SK+9zsYWBAcM3X
GH8RDyPLOpY+kk5RuW8fJMlvv/2WiA2x/OvdMta/ZewxLe/h02OxKZ6ILfFU
PBPPP2cs+aLzP/6XXDMrdBjrmfLvhx79wvsJWjlLdTu9n8aW5qiaDJW9Fg/G
xO//XSdfLg7dl9tu+X35ADyQQ3wciEeIuk5pOiN9Dk/g4/lvVhbZOfWutYKU
6g/CkXYQUF7vAw/eyNOxxoJvV/BUrXKOFE5JQJKYdYDhC2YZYFpG2BiSTMGj
rVTAXV9c5DxTLdQf+FLUigkApFmzLpRMx01b22zCRV57Td3WuU/VGsndYbiU
jP4kIRkNA+gLIXmMktjSKVp4b8Ukve/n8tzR8/H16fUfG5GnpbSlN+J90fB/
zcMe8grvvrpbWfbMtT8nE/tWvatUkc7E6mvuDWV+BxN/FA8nKq3QvNEhLt+y
3cfHQ/CwjPL9RZRn2D49EccGhdOMML4VzwPxrDNE88iQ7kuzqtBQYqxotG/A
M38cXmk3XgDdcJbftMCh8PJJgsu23KQyHvZhg7pXDv2zscDkiChLDIFCyDRO
cJEaG/h48l3lpZ7mrbQg+NBYhJKbj9ymRhdl6KH1OdZG9uqMEYanEdj4roPL
/ZHEDkA8xfVaqhrJehtgnLEOXAtwjYzkzU9HGnyU1edhZpSY9xo2xH3zwQbw
JC2I1WN/CO2TzBpnPlbICPtwpRlYXmgV4ul1lzqy4296vJPvJ8KxNhXDdasB
U0j0/4Rb/oBS53RyR/cahaAjhjAKxX8lDkBRfLPx2STJakyS+qfQb9ZfKOGL
1dpHqZn5lLTc8LCs0dZd4u2UWNPlQo1ROyjbYSz9cZbmG8c0uHqDF8TmYuwG
CZDZqzzjC0s+6EzzKmuatVACfOUZ6d3HCPFQe2tkxH0+Jy0uSIl18hmIrc3F
YG5VWio1dIrudBFO0tTUpOMFhuvTsTpIg0UN35KEay0+sliC+8X9w9EAm7Lx
SNpuqQr8nbwNsW5ChxBFfd3GHtHaduOztm2UubD3mA4HTTgCqPefV0ltw1UT
QX8gHvfnVLLAhfsUG+EsJXpLvAqcn1Co92U9JZzUxOq87Ym2catR7W/UAdPZ
ur9TCttwoc/HnzHOWkTvCgiOROih5b07nAPvVccdjYFJIxF0xtTZq/dygsBh
t/JqpHso6KPfwqVWVoJIVk0VZYErnfo85eeEQ6GsCbr/UrxjFg/dAwlISWIH
fTvypPd/x52DU/6+yv+VE9ib+4umzDBdmREwzvxJRCQWzpyChesL6Kk1pUlN
zjsfbB9tL+7KY+CehXHhT0Ri0g3HHYycoW2DLpcawFb/s9I63wTGrdQ3bq1x
ahLdCnY8B5N2hl7nWvzE1K/FLicEtjjeTuqseZ1cd/wv/rv8hjl84kldxL0t
87WYvyK8Th5EDQHM+aZr5bB/223jnUq48wQs719Oi5ubh1ZS/zYlxYb0Fv34
vzIZyvQi8b//ALpyyOqvJwAA

-->

</rfc>
