<?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' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-idr-flowspec-mpls-match-02" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.15.1 -->
  <front>
    <title abbrev="FlowSpec MPLS Match">BGP Flow Specification Filter for MPLS Label </title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-idr-flowspec-mpls-match-02"/>
    <author fullname="Lucy Yong" initials="L" surname="Yong">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>lucy.yong@huawei.com</email>
      </address>
    </author>
    <author fullname="Susan Hares" initials="S" surname="Hares">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>7453 Hickory Hill</street>
          <city>Saline</city>
          <region>MI</region>
          <code>48176</code>
          <country>USA</country>
        </postal>
        <email>shares@ndzh.com</email>
      </address>
    </author>
    <author fullname="Qiandeng Liang" initials="Q" surname="Liang">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>101 Software Avenue, Yuhuatai District</street>
          <city>Nanjing</city>
          <region/>
          <code>210012</code>
          <country>China</country>
        </postal>
        <email>liangqiandeng@huawei.com </email>
      </address>
    </author>
    <author fullname="Jianjie You" initials="J" surname="You">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>101 Software Avenue, Yuhuatai District</street>
          <city>Nanjing</city>
          <region/>
          <code>210012</code>
          <country>China</country>
        </postal>
        <email>youjianjie@huawei.com </email>
      </address>
    </author>
    <date year="2022" month="October" day="20"/>
    <area>Routing Area</area>
    <workgroup>IDR Working Group</workgroup>
    <keyword>RFC</keyword>
    <keyword>Request for Comments</keyword>
    <keyword>I-D</keyword>
    <keyword>Internet-Draft</keyword>
    <keyword>BGP Flow Specification</keyword>
    <keyword>MPLS Match</keyword>
    <abstract>
      <t>This draft proposes BGP flow specification rules that are 
   used to filter MPLS labeled packets.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t> BGP Flow Specification (BGP-FS) <xref target="RFC5575" format="default"/>
     is an extension to that allows for the dissemination of 
	 traffic flow specification rules via BGP (<xref target="RFC4271" format="default"/>).
     BGP-FS policies have a match condition that may 
	 be n-tuple match in a policy, and an action that modifies the 
	 packet and forwards/drops the packet. Via BGP, new filter rules 
	 can be sent to all BGP peers simultaneously without 
	 changing router configuration, and the BGP peer can install these 
	 routes in the forwarding table. The typical application of BGP-FS 
	 is to automate the distribution of traffic filter lists to routers for DDOS mitigation.
      </t>
      <t><xref target="RFC5575" format="default"/> defines a new BGP Network Layer 
     Reachability Information (NLRI) format
     used to distribute traffic flow specification rules. NLRI (AFI=1, SAFI=133) is
     for IPv4 unicast filtering. NLRI (AFI=1, SAFI=134)is for BGP/MPLS VPN filtering.
    <xref target="I-D.ietf-idr-flow-spec-v6" format="default"/> defines flow-spec extension 
	 for IPv6 data packets. <xref target="I-D.ietf-idr-flowspec-l2vpn" format="default"/>
	 extends the flow-spec rules for layer 2 Ethernet packets 
	 (AFI=25, SAFI=133, SAFI=134). All these flow specifications 
	 match parts only reflect single layer IP (source/destination IP prefix,
	 protocol type, ports, etc.) and Ethernet information 
	 with matches for source/destination MAC
      </t>
      <t><xref target="I-D.hr-idr-rfc5575bis" format="default"/> provides updates to 
		<xref target="RFC5575" format="default"/> to resolve unclear sections in text
		and conflicts with interactions of filtering actions.
      </t>
      <t>MPLS technologies <xref target="RFC3031" format="default"/> have been widely 
   deployed in WAN networks. MPLS label stack <xref target="RFC3032" format="default"/> 
   is the foundation for label switched data plane. A label on a label 
   stack may represent a label switch path (LSP), application identification 
   such as Pseudo Wire (PW), a reserved label that triggers a specific data 
   plane action, or etc. The data plane label switching operations 
   includes pop, push, or swap label on the label stack. 
      </t>
      <t>For value added services, it is valuable for a MPLS network to have 
   BGP-FS policy filter that matches on the MPLS portion of a packet and an 
   action to modify the MPLS packet header and/or monitor 
   the packets that match the policy. This document specifies an MPLS match filter. 
   <xref target="I-D.ietf-idr-bgp-flowspec-label" format="default"/>
   specifies a BGP action to modify the MPLS label.   
      </t>
      <t><xref target="I-D.hares-idr-flowspec-v2" format="default"/> describes the following
   two options for extending <xref target="RFC5575" format="default"/>: 
    creating a version 2 of BGP Flow Specification which 
	can run in parallel to the original BGP Flow specification. Version 2 may also 
	include improved security features (ROAs or <xref target="I-D.ietf-idr-bgp-flowspec-oid" format="default"/>)
      </t>
      <t>This MPLS match option can be used for RFC5575 (<xref target="RFC5575" format="default"/>, 
	<xref target="I-D.hr-idr-rfc5575bis" format="default"/>) or version 2 of the flow specification. 
      </t>
    </section>
    <section numbered="true" toc="default">
      <name>The Flow Specification Encoding for MPLS Match</name>
      <t>This document proposes new flow specifications rules that is encoded in NLRI.  
      </t>
      <dl newline="false" spacing="normal">
        <dt>Type TBD1- MPLS Match1</dt>
        <dd>
          <dl newline="false" spacing="normal">
            <dt/>
            <dd>Function: The match1 applies to MPLS Label field on the label stack. 
	</dd>
            <dt/>
            <dd>Encoding:
	&lt;type(1 octet), length(1 octet), [operator,value]+&gt;.
	</dd>
            <dt/>
            <dd>It contains a set of {operator, value} pairs that are used for matching filter.
	</dd>
            <dt/>
            <dd>
              <t>The operator byte is encoded as:
              </t>
              <artwork name="" type="" align="left" alt=""><![CDATA[
	  0   1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+---+
    | e | a | i |  pos  |   Resv    |
    +---+---+---+---+---+---+---+---+
	]]></artwork>
            </dd>
            <dt/>
            <dd>
              <t>where:
              </t>
              <dl newline="false" spacing="normal">
                <dt>e - end of list bit: </dt>
                <dd> Set in the last {op, value} pair in the list.
	</dd>
                <dt>a - AND bit: </dt>
                <dd> If unset, the previous term is logically ORed with
	the current one. If set, the operation is a logical AND. 
	It should be unset in the first operator byte of a sequence.  
	The AND operator has higher priority than OR for the purposes of 
	evaluating logical expressions.  
	</dd>
                <dt>i - before bit: </dt>
                <dd>If unset, apply matching filter before 
	MPLS label data plane action; if set, apply matching filter after 
	MPLS label data plane action.
	</dd>
                <dt>pos - the label position indication bits:</dt>
                <dd>
                  <t> where:
                  </t>
                  <dl newline="false" spacing="normal">
                    <dt>00:any position on the label stack</dt>
                    <dd> -  the presented 
	label value is used to match any label on the label stack.
	When apply it, at least one label on the stack match the value 
	</dd>
                    <dt>01:top label indication- </dt>
                    <dd> the presented 
	label value MUST be used to match the top label on the label stack.  
	</dd>
                    <dt>10: bottom label indication- </dt>
                    <dd> If it is set, the 
     presented label value MUST match the bottom label on the label stack. 
	 When it is clear, the present label value can match to any label on the label stack
	</dd>
                    <dt>11: </dt>
                    <dd>(for reserved labels) 
	</dd>
                  </dl>
                </dd>
              </dl>
            </dd>
            <dt/>
            <dd>
              <t>The value field is encoded as:
              </t>
              <artwork name="" type="" align="left" alt=""><![CDATA[
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                Label                  |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	]]></artwork>
            </dd>
          </dl>
        </dd>
        <dt>Type TBD2 - MPLS Match2</dt>
        <dd>
          <dl newline="false" spacing="normal">
            <dt/>
            <dd>Function: MPLS Match2 applies to MPLS Label experiment bits (EXP) on 
	the top label in the label stack.
	</dd>
            <dt/>
            <dd>
              <t>Encoding:  &lt;type (1 octet), [op, value]+&gt;
              </t>
              <dl newline="false" spacing="normal">
                <dt/>
                <dd>[op,value] - Defines a list of {operation, value} pairs used to 
	match 3-bit exp field on the top label of packets <xref target="RFC3032" format="default"/>. 
	</dd>
                <dt/>
                <dd>Values are encoded using a single byte, where the five most significant 
	bits are zero and the three least significant bits contain the exp value.
	</dd>
              </dl>
            </dd>
          </dl>
        </dd>
      </dl>
    </section>
    <section numbered="true" toc="default">
      <name>Deployment Example: DDoS Traffic</name>
      <t> In this example, 5 local policy rules in the 
   filter-based RIBs (FB-RB, aka Policy Routing) will match n-tuples 
   (destination IP address, Destination Port, source IP address, Source IP Address, protocols
   (ICMP and STCP). These policy rules can be created by standard yang modules 
   for filter-based RIBS (configuration, and ephemeral configuration) or ACLs, or
   vendor based policy.  These policies will put the DDoS attack data onto one LSP (LSP1)
   in order to send the DDoS traffic to the IDS/IPS processing attached to PE2. 
      </t>
      <t>
  The MPLS Filter allows the BGP Flow specification to match on the LSP label 
  rather than the IP address so that PE2 (with the FB-RIBs on PE2) can forward 
  the traffic to a set of IDS/IPS machines. The BGP Flow Specification (BGP-FS) 
  can forward this simple match policy along with an action policy that 
  constraints the traffic on this Flow to a certain rate (bytes/second).  
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[ 
      |<---------------- AS1 ----------------->|
     +---------+   +-----+    +-----+    +-----+
  ===| PE1     |---|IBGP |----|IBGP |----| PE2 |--IDS-1/IPS
     | Filters |   |     |    |     |    |     |--IDS-2/IPS
     +---------+   +-----+    +-----+    +-----+
         |-------------------------------|
        MPLS travel on LSP-1 with label-1 
  
               BGP Flow Specification Filter 1

     BGP Flow Specification
     Match Policy 
	    Destination IP address (0/0) [Required by RFC5575]
        MPLS Label match (label-1)
     Action Policy 
        Traffic-rate (n bytes)  
  ]]></artwork>
    </section>
    <section numbered="true" toc="default">
      <name>Security Considerations</name>
      <t> The validation of BGP Flow Specification policy relies on the security
  of the BGP protocol and RFC 5575 checks (<xref target="RFC5575" format="default"/>,
  <xref target="I-D.hr-idr-rfc5575bis" format="default"/>) for BGP Flow specification version 1
  and BGP Flow specification version 2 (<xref target="I-D.hares-idr-flowspec-v2" format="default"/>).
  For Option 1, the MPLS Match can be one of the match filtes, and  
  and the final match is an "AND" of all the filters. Match filters are tested in 
  the order specified in <xref target="I-D.hares-idr-flowspec-v2" format="default"/> and/or
  an RFC5575bis document.   
      </t>
    </section>
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This section complies with <xref target="RFC7153" format="default"/>
      </t>
      <t>
   IANA is requested to a new entry in "Flow Spec component types registry" 
   with the following values:  
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
    Value Name:    Value  Reference 
	===========    =====  =========
    MPLS-Match1    TBD1    [This Document]
    MPLS-Match2    TBD2    [This Document] 
	]]></artwork>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC3031" target="https://www.rfc-editor.org/info/rfc3031" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml">
          <front>
            <title>Multiprotocol Label Switching Architecture</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="A. Viswanathan" initials="A." surname="Viswanathan"/>
            <author fullname="R. Callon" initials="R." surname="Callon"/>
            <date month="January" year="2001"/>
            <abstract>
              <t>This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3031"/>
          <seriesInfo name="DOI" value="10.17487/RFC3031"/>
        </reference>
        <reference anchor="RFC3032" target="https://www.rfc-editor.org/info/rfc3032" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml">
          <front>
            <title>MPLS Label Stack Encoding</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="D. Tappan" initials="D." surname="Tappan"/>
            <author fullname="G. Fedorkow" initials="G." surname="Fedorkow"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <author fullname="A. Conta" initials="A." surname="Conta"/>
            <date month="January" year="2001"/>
            <abstract>
              <t>This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well.  This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3032"/>
          <seriesInfo name="DOI" value="10.17487/RFC3032"/>
        </reference>
        <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="RFC5575" target="https://www.rfc-editor.org/info/rfc5575" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5575.xml">
          <front>
            <title>Dissemination of Flow Specification Rules</title>
            <author fullname="P. Marques" initials="P." surname="Marques"/>
            <author fullname="N. Sheth" initials="N." surname="Sheth"/>
            <author fullname="R. Raszuk" initials="R." surname="Raszuk"/>
            <author fullname="B. Greene" initials="B." surname="Greene"/>
            <author fullname="J. Mauch" initials="J." surname="Mauch"/>
            <author fullname="D. McPherson" initials="D." surname="McPherson"/>
            <date month="August" year="2009"/>
            <abstract>
              <t>This document defines a new Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.</t>
              <t>Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service.</t>
              <t>The information is carried via the BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5575"/>
          <seriesInfo name="DOI" value="10.17487/RFC5575"/>
        </reference>
        <reference anchor="RFC7153" target="https://www.rfc-editor.org/info/rfc7153" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7153.xml">
          <front>
            <title>IANA Registries for BGP Extended Communities</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <date month="March" year="2014"/>
            <abstract>
              <t>This document reorganizes the IANA registries for the type values and sub-type values of the BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute.  This is done in order to remove interdependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries.  This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries.  These changes are compatible with the existing allocations and thus do not affect protocol implementations.  The changes will, however, impact the "IANA Considerations" sections of future protocol specifications.  This document updates RFC 4360 and RFC 5701.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7153"/>
          <seriesInfo name="DOI" value="10.17487/RFC7153"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="I-D.ietf-idr-flow-spec-v6" target="https://www.ietf.org/archive/id/draft-ietf-idr-flow-spec-v6-22.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-flow-spec-v6.xml">
          <front>
            <title>Dissemination of Flow Specification Rules for IPv6</title>
            <author fullname="Christoph Loibl" surname="Christoph Loibl">
              <organization>next layer Telekom GmbH</organization>
            </author>
            <author fullname="Robert Raszuk" surname="Robert Raszuk">
              <organization>Bloomberg LP</organization>
            </author>
            <author fullname="Susan Hares" surname="Susan Hares">
              <organization>Huawei</organization>
            </author>
            <date day="14" 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. 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="Internet-Draft" value="draft-ietf-idr-flow-spec-v6-22"/>
        </reference>
        <reference anchor="I-D.ietf-idr-flowspec-l2vpn" target="https://www.ietf.org/archive/id/draft-ietf-idr-flowspec-l2vpn-20.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/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>Futurewei Technologies</organization>
            </author>
            <author fullname="Stephane Litkowski" initials="S." surname="Litkowski">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Shunwan Zhuang" initials="S." surname="Zhuang">
              <organization>Huawei Technologies</organization>
            </author>
            <date day="9" month="October" year="2022"/>
            <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-20"/>
        </reference>
        <reference anchor="I-D.ietf-idr-bgp-flowspec-label" target="https://www.ietf.org/archive/id/draft-ietf-idr-bgp-flowspec-label-01.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-idr-bgp-flowspec-label.xml">
          <front>
            <title>Carrying Label Information for BGP FlowSpec</title>
            <author fullname="Qiandeng Liang"/>
            <author fullname="Susan Hares "/>
            <author fullname="Jianjie You"/>
            <author fullname="Robert Raszuk"/>
            <author fullname="Dan Ma "/>
            <date day="6" month="December" year="2016"/>
            <abstract>
              <t>This document specifies a method in which the label mapping information for a particular FlowSpec rule is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the FlowSpec rule. Based on the proposed method, the Label Switching Routers (LSRs) (except the ingress LSR) on the Label Switched Path (LSP) can use label to indentify the traffic matching a particular FlowSpec rule; this facilitates monitoring and traffic statistics for FlowSpec rules.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-flowspec-label-01"/>
        </reference>
        <reference anchor="I-D.hares-idr-flowspec-v2" target="https://www.ietf.org/archive/id/draft-hares-idr-flowspec-v2-05.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.hares-idr-flowspec-v2.xml">
          <front>
            <title>BGP Flow Specification Version 2</title>
            <author fullname="Susan Hares" surname="Susan Hares">
              <organization>Hickory Hill Consulting</organization>
            </author>
            <author fullname="Donald Eastlake" surname="Donald Eastlake">
              <organization>Futurewei Technologies</organization>
            </author>
            <author fullname="Chaitanya Yadlapalli" surname="Chaitanya Yadlapalli">
              <organization>ATT</organization>
            </author>
            <author fullname="Sven Maduschke" surname="Sven Maduschke">
              <organization>Verizon</organization>
            </author>
            <date day="4" month="February" year="2022"/>
            <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-hares-idr-flowspec-v2-05"/>
        </reference>
        <reference anchor="I-D.hr-idr-rfc5575bis" target="https://www.ietf.org/archive/id/draft-hr-idr-rfc5575bis-03.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.hr-idr-rfc5575bis.xml">
          <front>
            <title>Dissemination of Flow Specification Rules</title>
            <author fullname="Susan Hares" surname="Susan Hares"/>
            <author fullname="Robert Raszuk" surname="Robert Raszuk"/>
            <author fullname="Danny McPherson" surname="Danny McPherson"/>
            <author fullname="Christoph Loibl" surname="Christoph Loibl"/>
            <author fullname="Martin Bacher" surname="Martin Bacher"/>
            <date day="14" month="February" year="2017"/>
            <abstract>
              <t>This document updates RFC5575 which defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. This draft specifies IPv4 traffic flow specifications via a BGP NLRI which carries traffic flow specification filter, and an Extended community value which encodes actions a routing system can take if the packet matches the traffic flow filters. The flow filters and the actions are processed in a fixed order. Other drafts specify IPv6, MPLS addresses, L2VPN addresses, and NV03 encapsulation of IP addresses. This document updates RFC5575 to correct unclear specifications in the flow filters and to provide rules for actions which interfere (e.g. redirection of traffic and flow filtering). Applications which use the bgp flow specification are: 1) application which automate of inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial- of-service attacks; 2) application which control traffic filtering in the context of a BGP/MPLS VPN service, and 3) applications with centralized control of traffic in a SDN or NFV context. Some of deployments of these three applications can be handled by the strict ordering of the BGP NLRI traffic flow filters, and the strict actions encoded in the Extended Community Flow Specification actions.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-hr-idr-rfc5575bis-03"/>
        </reference>
        <reference anchor="I-D.ietf-idr-bgp-flowspec-oid" target="https://www.ietf.org/archive/id/draft-ietf-idr-bgp-flowspec-oid-15.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-bgp-flowspec-oid.xml">
          <front>
            <title>Revised Validation Procedure for BGP Flow Specifications</title>
            <author fullname="James Uttaro" surname="James Uttaro">
              <organization>AT&amp;T</organization>
            </author>
            <author fullname="Juan Alcaide" surname="Juan Alcaide">
              <organization>Cisco</organization>
            </author>
            <author fullname="Clarence Filsfils" surname="Clarence Filsfils">
              <organization>Cisco</organization>
            </author>
            <author fullname="David Smith" surname="David Smith">
              <organization>Cisco</organization>
            </author>
            <author fullname="Pradosh Mohapatra" surname="Pradosh Mohapatra">
              <organization>Sproute Networks</organization>
            </author>
            <date day="3" month="June" year="2021"/>
            <abstract>
              <t>This document describes a modification to the validation procedure defined for the dissemination of BGP Flow Specifications. The dissemination of BGP Flow Specifications as specified in RFC 8955 requires that the originator of the Flow Specification match the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. For an Internal Border Gateway Protocol (iBGP) received route, the originator is typically a border router within the same autonomous system (AS). The objective is to allow only BGP speakers within the data forwarding path to originate BGP Flow Specifications. Sometimes it is desirable to originate the BGP Flow Specification from any place within the autonomous system itself, for example, from a centralized BGP route controller. However, the validation procedure described in RFC 8955 will fail in this scenario. The modification proposed herein relaxes the validation rule to enable Flow Specifications to be originated within the same autonomous system as the BGP speaker performing the validation. Additionally, this document revises the AS_PATH validation rules so Flow Specifications received from an External Border Gateway Protocol (eBGP) peer can be validated when such a peer is a BGP route server. This document updates the validation procedure in RFC 8955.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-flowspec-oid-15"/>
        </reference>
      </references>
    </references>
  </back>
</rfc>
