<?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-bgp-flowspec-label-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="BGP FlowSpec">Carrying Label Information for BGP
    FlowSpec</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-flowspec-label-02"/>
    <author fullname="Qiandeng Liang" initials="Q." surname="Liang">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>101 Software Avenue, Yuhuatai District</street>
          <city>Nanjing,</city>
          <code>210012</code>
          <country>China</country>
        </postal>
        <email>liangqiandeng@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, MI</city>
          <code>48176</code>
          <country>USA</country>
        </postal>
        <email>shares@ndzh.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>
          <code>210012</code>
          <country>China</country>
        </postal>
        <email>youjianjie@huawei.com</email>
      </address>
    </author>
    <author fullname="Robert Raszuk" initials="R." surname="Raszuk">
      <organization>Nozomi</organization>
      <address>
        <email>robert@raszuk.net</email>
      </address>
    </author>
    <author fullname="Dan Ma " initials="D." surname="Ma">
      <organization>Cisco Systems</organization>
      <address>
        <email>danma@cisco.com</email>
      </address>
    </author>
    <date year="2022" month="October" day="20"/>
    <area>Rtg 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, FlowSpec</keyword>
    <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>
    <note>
      <name>Requirements Language</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref target="RFC2119" format="default"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>This section provides the background for proposing a new action for
      BGP Flow specification that push/pops MPLS or swaps MPLS tags. For those
      familiar with BGP Flow specification (<xref target="RFC5575" format="default"/>,
      <xref target="RFC7674" format="default"/>, <xref target="I-D.ietf-idr-flow-spec-v6" format="default"/>, <xref target="I-D.ietf-idr-flowspec-l2vpn" format="default"/>, <xref target="I-D.ietf-idr-bgp-flowspec-oid" format="default"/> and MPLS (<xref target="RFC3107" format="default"/>) can skip this background section.</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>
      <section numbered="true" toc="default">
        <name>Background</name>
        <t><xref target="RFC5575" format="default"/> defines the flow specification
        (FlowSpec) that is an n-tuple consisting of several matching criteria
        that can be applied to IP traffic. The matching criteria can include
        elements such as source and destination address prefixes, IP protocol,
        and transport protocol port numbers. A given IP packet is said to
        match the defined flow if it matches all the specified criteria. <xref target="RFC5575" format="default"/> also defines a set of filtering actions, such
        as rate limit, redirect, marking, associated with each flow
        specification. A new Border Gateway Protocol Network Layer
        Reachability Information (BGP NLRI) (AFI/SAFI: 1/133 for IPv4,
        AFI/SAFI: 1/134 for VPNv4) encoding format is used to distribute
        traffic flow specifications.</t>
        <t>[Note:  <xref target="I-D.hr-idr-rfc5575bis" format="default"/> updates <xref target="RFC5575" format="default"/>.]
        </t>
        <t><xref target="RFC3107" format="default"/> specifies the way in which the label
        mapping information for a particular route is piggybacked in the same
        Border Gateway Protocol Update message that is used to distribute the
        route itself. Label mapping information is carried as part of the
        Network Layer Reachability Information (NLRI) in the Multiprotocol
        Extensions attributes. The Network Layer Reachability Information is
        encoded as one or more triples of the form &lt;length, label,
        prefix&gt;. The NLRI contains a label is indicated by using Subsequent
        Address Family Identifier (SAFI) value 4.</t>
        <t><xref target="RFC4364" format="default"/> describes a method in which each
        route within a Virtual Private Network (VPN) is assigned a
        Multiprotocol Label Switching (MPLS) label. If the Address Family
        Identifier (AFI) field is set to 1, and the SAFI field is set to 128,
        the NLRI is an MPLS-labeled VPN-IPv4 address.</t>
      </section>
      <section numbered="true" toc="default">
        <name>MPLS Flow Specification Deployment</name>
        <t>In BGP VPN/MPLS networks when flow specification policy rules exist
        on multiple forwarding devices in the network bound with labels from
        one or more LSPs, only the ingress LSR (Label Switching Router) needs
        to identify a particular traffic flow based on the matching criteria
        for flow. Once the flow is match by the ingress LSR, the ingress LSR
        steers the packet to a corresponding LSP (Label Switched Path). Other
        LSRs of the LSP just need to forward the packet according to the label
        carried in it.</t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Terminology</name>
      <t>This section contains definitions of terms used in this document.</t>
      <ul empty="true" spacing="normal">
        <li>Flow Specification (FlowSpec): A flow specification is an n-tuple
          consisting of several matching criteria that can be applied to IP
          traffic, including filters and actions. Each FlowSpec consists of a
          set of filters and a set of actions.</li>
      </ul>
    </section>
    <section numbered="true" toc="default">
      <name>Overview of Proposal</name>
      <t>This document proposes adding a BGP-FS action in an extended
      community alters the label switch path associated with a matched flow.
      If the match does not have a label switch path, this action is
      skipped.</t>
      <t>The BGP flow specification (BGP-FS) policy rule could match on the
      destination prefix and then utilize a BGP-FS action to adjust the label
      path associated with it (push/pop/swap tags.) Or a BGP-FS policy rule
      could match on any set of BGP-FS match conditions associated with a
      BGP-FS action that adjust the label switch path (push/pop/swap).</t>
      <t><xref target="I-D.ietf-idr-flowspec-mpls-match" format="default"/> provides a
      match BGP-FS that may be used with this action to match and direct MPLS
      packets.</t>
      <t>Example of Use:</t>
      <t>Forwarding information for the traffic from IP1 to IP2 in the
      Routers:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[       PE1:   in(<IP2,IP1>) --> out(Label2)
       ASBR1: in(Label2) --> out(Label3)
       ASBR2: in(Label3) --> out(Label4)
       PE2:   in(Label4) --> out(--)]]></artwork>
      <t>Labels allocated by flow policy process:</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[       Label4 allocated by PE2
       Label3 allocated by ASBR2
       Label2 allocated by ASBR1]]></artwork>
      <artwork align="left" name="" type="" alt=""><![CDATA[
           |<------AS1----->|    |<------AS2----->|
           +-----+    +-----+    +-----+    +-----+
VPN 1,IP1..| PE1 |====|ASBR1|----|ASBR2|====| PE2 |..VPN1,IP2
           +-----+    +-----+    +-----+    +-----+
             | LDP LSP1 |          | LDP LSP2 |
             | -------> |          | -------> |
             |-------BGP VPN Flowspec LSP---->|
          (Label1)    (Label2)   (Label3)   (Label4)
                   
              Figure 1: Usage of FlowSpec with Label
]]></artwork>
      <t>BGP-FS rule1 (locally configured):</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[       Filters:
          destination ip prefix:IP2/32
          source ip prefix:IP1/32

       Actions: Extended Communities 
          traffic-marking: 1   
          MPLS POP      ]]></artwork>
      <t>Note:</t>
      <t>The following Extended Communities are added/deleted</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[       [rule-1a] BGP-FS action MPLS POP [used on PE2]  
       [rule-1b] BGP-FS action SWAP 4   [used on ASBR-2]
       [rule-1c] BGP-FS action SWAP 3   [used on ASBR-1]
       [rule-1d] BGP-FS action push 2   [used on PE1] ]]></artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[PE-2 Changes BGP-FS rule-1a to rule-1b prior to sending
     Clears Extended Community: BGP-FS action MPLS POP 
     Adds   Extended Community: BGP-FS action MPLS SWAP 4]]></artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[ASBR-2 receives BGP-FS rule-1b (NRLI + 2 Extended Community)
       Installs the BGP-FS rule-1b (MPLS SWAP 4, traffic-marking)  
       Changes BGP-FS rule-1b to rule-1c prior to sending to ASBR1 
       Clear Extended Community: BGP-FS action MPLS SWAP 4
       Adds  Extended Community: BGP-FS action MPLS SWAP 3]]></artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[ASBR-1 Receives BGP-FS rule-1c (NLRI + 2 Extended Community)
       Installs the BGP-FS rule-1c (MPLS SWAP 3, traffic-marking
       Changes BGP-FS rule-1c to rule-1d prior to sending to PE-2 
       Clear Extended Community: BGP-FS action MPLS SWAP 3
       Adds  Extended Community: BGP-FS action MPLS SWAP 2 ]]></artwork>
      <artwork name="" type="" align="left" alt=""><![CDATA[PE-1 Receives BGP-FS rule-1d (NLRI + 2 Extended Communities)
     Installs BGP-FS rule-1d action [MPLS SWAP 2, traffic-marking]  ]]></artwork>
    </section>
    <section numbered="true" toc="default">
      <name>Protocol Extensions</name>
      <t>In this document, BGP is used to distribute the FlowSpec rule bound
      with label(s). A new label-action is defined as BGP extended community
      value based on Section 7 of <xref target="RFC5575" format="default"/>.</t>
      <artwork align="center" name="" type="" alt=""><![CDATA[
+--------+--------------------+--------------------------+
| type   | extended community | encoding                 |
+--------+--------------------+--------------------------+
| TBD1   | label-action       | MPLS tag                 |
+--------+--------------------+--------------------------+
]]></artwork>
      <t>Label-action is described below:</t>
      <artwork name="" type="" align="left" alt=""><![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  (TBD1              | OpCode|Reserve| order         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
 |                Label                  | Exp |S|       TTL     | Stack
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
]]></artwork>
      <t>The use and the meaning of these fields are as follows:</t>
      <ul empty="true" spacing="normal">
        <li>Type: the same as defined in <xref target="RFC4360" format="default"/></li>
        <li>
          <t>OpCode: Operation code</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[+------+------------------------------------------------------------+
|OpCode| Function                                                   |
+------+------------------------------------------------------------+
|  0   | Push the MPLS tag                                          |
+------+------------------------------------------------------------+
|  1   | Pop the outermost MPLS tag in the packet                   |
+------+------------------------------------------------------------+
|  2   | Swap the MPLS tag with the outermost MPLS tag in the packet|
+------+------------------------------------------------------------+
| 3~15 | Reserved                                                   |
+------+------------------------------------------------------------+]]></artwork>
          <ul spacing="normal">
            <li>When the Opcode field is set to 0, the label stack entry
              Should be pushed on the MPLS label stack.</li>
            <li>When the OpCode field is set to 1, the label stack entry is
              invalid, and the router SHOULD pop the existing outermost MPLS
              tag in the packet.</li>
            <li>When the OpCode field is set to 2, the router SHOULD swap the
              label stack entry with the existing outermost MPLS tag in the
              packet. If the packet has no MPLS tag, it just pushes the label
              stack entry.</li>
            <li>The OpCode 0 or 1 may be used in some SDN networks, such as
              the scenario described in <xref target="I-D.filsfils-spring-segment-routing-central-epe" format="default"/>.</li>
            <li>The OpCode 2 can be used in traditional BGP MPLS/VPN
              networks.</li>
          </ul>
        </li>
        <li>Reserved: all zeros.</li>
        <li>Order: A FlowSpec rule MAY include one or more ordering
          label-action(s). If multiple label action extended communities are
          associated with a BGP-FS Rule, this gives the order of this in the
          list. The Last action received for an order will be used.</li>
        <li>Label: the same as defined in <xref target="RFC3032" format="default"/>.</li>
        <li>Bottom of Stack (S): the same as defined in <xref target="RFC3032" format="default"/>. It SHOULD be invalid, and set to zero by
          default. It MAY be modified by the forwarding router locally.</li>
        <li>Time to Live (TTL): the same as defined in<xref target="RFC3032" format="default"/>. It MAY be modified by the forwarding
          router locally.</li>
        <li>Experimental Use (Exp): the same as defined in <xref target="RFC3032" format="default"/>. It MAY be modified by the forwarding
          router according to the local routing policy.</li>
      </ul>
    </section>
    <section numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>For the purpose of this work, IANA should allocate the following
      Extended community:</t>
      <ul empty="true" spacing="normal">
        <li>TBD1 for label-action</li>
      </ul>
    </section>
    <section numbered="true" toc="default">
      <name>Security considerations</name>
      <t>This extension to BGP does not change the underlying security issues
      inherent in the existing BGP.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Acknowledgement</name>
      <t>The authors would like to thank Shunwan Zhuang, Zhenbin Li, Peng Zhou
      and Jeff Haas for their comments.</t>
    </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="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="RFC3107" target="https://www.rfc-editor.org/info/rfc3107" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3107.xml">
          <front>
            <title>Carrying Label Information in BGP-4</title>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <date month="May" year="2001"/>
            <abstract>
              <t>This document specifies the way in which the label mapping information for a particular route is piggybacked in the same Border Gateway Protocol (BGP) Update message that is used to distribute the route itself. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3107"/>
          <seriesInfo name="DOI" value="10.17487/RFC3107"/>
        </reference>
        <reference anchor="RFC4364" target="https://www.rfc-editor.org/info/rfc4364" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml">
          <front>
            <title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <date month="February" year="2006"/>
            <abstract>
              <t>This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers.  This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other.  Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4364"/>
          <seriesInfo name="DOI" value="10.17487/RFC4364"/>
        </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="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="RFC7674" target="https://www.rfc-editor.org/info/rfc7674" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7674.xml">
          <front>
            <title>Clarification of the Flowspec Redirect Extended Community</title>
            <author fullname="J. Haas" initials="J." role="editor" surname="Haas"/>
            <date month="October" year="2015"/>
            <abstract>
              <t>This document updates RFC 5575 ("Dissemination of Flow Specification Rules") to clarify the formatting of the BGP Flowspec Redirect Extended Community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7674"/>
          <seriesInfo name="DOI" value="10.17487/RFC7674"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="I-D.filsfils-spring-segment-routing-central-epe" target="https://www.ietf.org/archive/id/draft-filsfils-spring-segment-routing-central-epe-05.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.filsfils-spring-segment-routing-central-epe.xml">
          <front>
            <title>Segment Routing Centralized Egress Peer Engineering</title>
            <author fullname="Clarence Filsfils" surname="Clarence Filsfils"/>
            <author fullname="Stefano Previdi" surname="Stefano Previdi"/>
            <author fullname="Keyur Patel" surname="Keyur Patel"/>
            <author fullname="Ebben Aries" surname="Ebben Aries"/>
            <author fullname="Steve Shaw " surname="Steve Shaw"/>
            <author fullname="Daniel Ginsburg" surname="Daniel Ginsburg"/>
            <author fullname="Dmitry Afanasiev" surname="Dmitry Afanasiev"/>
            <date day="29" month="August" year="2015"/>
            <abstract>
              <t>Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS dataplane with no change on the forwarding plane. It requires minor extension to the existing link-state routing protocols. This document illustrates the application of Segment Routing to solve the Egress Peer Engineering (EPE) requirement. The SR-based EPE solution allows a centralized (SDN) controller to program any egress peer policy at ingress border routers or at hosts within the domain. This document is on the informational track.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-filsfils-spring-segment-routing-central-epe-05"/>
        </reference>
        <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-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>
        <reference anchor="I-D.ietf-idr-flowspec-mpls-match" target="https://www.ietf.org/archive/id/draft-ietf-idr-flowspec-mpls-match-01.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-idr-flowspec-mpls-match.xml">
          <front>
            <title>BGP Flow Specification Filter for MPLS Label</title>
            <author fullname="Lucy Yong"/>
            <author fullname="Susan Hares"/>
            <author fullname="Qiandeng Liang"/>
            <author fullname="Jianjie You"/>
            <date day="6" month="December" year="2016"/>
            <abstract>
              <t>This draft proposes BGP flow specification rules that are used to filter MPLS labeled packets.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-flowspec-mpls-match-01"/>
        </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>
      </references>
    </references>
  </back>
</rfc>
