One document matched: draft-liang-idr-flowspec-mpls-action-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3031.xml">
<!ENTITY RFC3032 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3032.xml">
<!ENTITY RFC3107 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3107.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC4360 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4360.xml">
<!ENTITY RFC4364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY RFC5575 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5575.xml">
<!ENTITY RFC7153 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7153.xml">
<!ENTITY RFC7674 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7674.xml">
<!ENTITY I-D.ietf-idr-flow-spec-v6 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-flow-spec-v6.xml">
<!ENTITY I-D.ietf-idr-flowspec-l2vpn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-flowspec-l2vpn.xml">
<!ENTITY I-D.ietf-idr-bgp-flowspec-oid
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-bgp-flowspec-oid.xml">
<!ENTITY I-D.hares-idr-flowspec-combo
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-idr-flowspec-combo.xml">
<!ENTITY I-D.filsfils-spring-segment-routing-central-epe
SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.filsfils-spring-segment-routing-central-epe.xml">
]>
<?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 category="std" docName="draft-liang-idr-flowspec-mpls-action-00" ipr="trust200902">
<front>
<title abbrev="FlowSpec MPLS Action">BGP Flow Specification MPLS action </title>
<author fullname="Qiandeng Liang" initials="Q" surname="Liang">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhuatai District</street>
<city>Nanjing</city>
<region></region>
<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</city>
<region>MI</region>
<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>
<region></region>
<code>210012</code>
<country>China</country>
</postal>
<email>youjianjie@huawei.com </email>
</address>
</author>
<author fullname="Robert Raszuk" initials="R" surname="Raszuk" >
<organization>Bloomberg LP</organization>
<address>
<postal>
<street>731 Lexington Ave </street>
<city>New York City</city>
<region>NY</region>
<code>10022</code>
<country>USA</country>
</postal>
<email>robert@raszuk.net</email>
</address>
</author>
<author fullname="Dan Ma" initials="D" surname="Ma">
<organization>Cisco</organization>
<address>
<email>danma@cisco.com</email>
</address>
</author>
<date year="2016" />
<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>BGP-FS MPLS action</keyword>
<abstract>
<t> This document specifies a BGP Flow specification policy
action to push/pop/swap MPLS labels.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t> This section provides the background for proposing a new action for
BGP Flow specification <xref target="RFC5575"></xref> that push/pops MPLS labels
or swaps MPLS labels. For those familiar with BGP Flow
specification (<xref target="RFC5575"></xref>, <xref target="RFC7674"></xref>
<xref target="I-D.ietf-idr-flow-spec-v6"></xref>, <xref target="I-D.ietf-idr-flowspec-l2vpn"></xref>,
and MPLS (<xref target="RFC3107"></xref>) can skip this background section.
</t>
<section title="Background">
<t><xref target="RFC5575"></xref> 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"></xref>
also defines a set of filtering actions, such as rate limit,
redirect, marking, associated with each flow specification. A new
Border Gateway Protocol (<xref target="RFC4271"></xref>) 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>
<xref target="RFC3107"></xref> 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 <length, label, prefix>. The NLRI
contains a label is indicated by using Subsequent Address Family
Identifier (SAFI) value 4.
</t>
<t><xref target="RFC4364"></xref> 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 title="MPLS Flow Specification Deployment">
<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 title="Terminology">
<t>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.
</t>
<section title="Requirements Language ">
<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"></xref>.</t>
</section>
</section>
<section title="Overview of Proposal">
<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>draft-ietf-yong-flowspec-mpls-match
provides a match BGP-FS that may be used with this
action to match and direct MPLS packets.
</t>
</section>
<section title="Protocol Extensions">
<t>A new label-action is defined as BGP extended
community value based on Section 7 of [RFC5575].
</t>
<t>
<figure>
<artwork>
+--------+--------------------+--------------------------+
| type | extended community | encoding |
+--------+--------------------+--------------------------+
| TBD1 | label-action | MPLS tag |
+--------+--------------------+--------------------------+
Figure 1
</artwork>
</figure>
</t>
<t>Label-action is described below:
<figure>
<artwork>
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
The use and the meaning of these fields are as follows:
Type: the same as defined in [RFC4360]
Figure 2
</artwork>
</figure>
</t>
<t>
<list style="hanging">
<t hangText="OpCode: Operation code">
<figure>
<artwork>
+------+------------------------------------------------------------+
|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>
</figure>
<list style="symbols">
<t>where:</t>
<t> When the Opcode field is set to 0, the label stack entry
Should be pushed on the MPLS label stack.
</t>
<t>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.
</t>
<t>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.
</t>
<t>Note-1: 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"></xref>.
</t>
<t>The OpCode 2 can be used in traditional BGP MPLS/VPN networks.
</t>
</list>
</t>
<t hangText="Reserved: all zeros"></t>
<t hangText="Order: within multiple label actions">
A FlowSpec rule MAY be associated with one or more ordering label-action
each in an extended community. If multiple label-actions occur,
this field gives the order of this action within that group.
If two MPLs actions arrive with the same order the last mpls action
received for an order will be used.
</t>
<t hangText="Label: ">the same as defined in <xref target="RFC3032"></xref>
</t>
<t hangText="Bottom of Stack (S): ">the same as defined in
<xref target="RFC3032"></xref>. It SHOULD be invalid,
and set to zero by default. It MAY be modified by the
forwarding router locally.
</t>
<t hangText=" Time to Live (TTL): ">the same as defined in
<xref target="RFC3032"></xref>. It MAY be
modified by the forwarding router locally.
</t>
<t hangText="Experimental Use (Exp): ">the same as defined
in <xref target="RFC3032"></xref>. It MAY
be modified by the forwarding router according to the local
routing policy.
</t>
</list>
</t>
</section>
<section title="Deployment Examples">
<section title="Exampel 1 - MPLS Filter + MPLS Action">
<t>
<figure>
<artwork>
Forwarding information for the traffic
for source: IP2, Destination: IP1
Purpose of BGP-FS filters: send DDoS traffic to IDS/IPS server
PE1: in(<IP2,IP1>) --> out(Label1)
ASBR1: in(Label1) --> out(Label1)
ASBR2: in(Label1) --> out(Label2)
PE2: in(Label2) --> out(--)
|<------AS1----->| |<------AS2----->|
+-----+ +------+ +------+ +-----+
VPN 1,IP1..| PE1 |====|ASBR-1|----|ASBR-2|====| PE2 |..IDS/IPS
IP2 +-----+ +------+ +------+ +-----+
|-----label 1---------||-label 2---------|
|---------BGP VPN Flowspec LSP--------->|
Figure 1 - Forwarding Diagram
</artwork>
</figure>
</t>
<t>
<figure>
<artwork>
locally configured filters
Filters:
destination ip prefix:IP2/32
source ip prefix:IP1/32
Action:
put on LSP with Label 1
PE-2 Installs:
BGP-FS Filter:
MPLS filter for Label 1 and label 2
BGP-FS Actions:
Traffic-Rate limit
MPLS POP
PE-2 Sends to ASBR-2
BGP-FS Filter
MPLS filter for label 1 and Label 2
BGP-FS Actions:
Traffic-Rate limit
Label SWAP 1 to 2
PE-1 Sends to ASBR 1
BGP-FS filter
MPLS filter for label 1
BGP-FS Actions
Traffic-Rate limit
</artwork>
</figure>
</t>
</section>
<section title="Example 2 - IP filter + MPLS action">
<t>
<figure>
<artwork>
Forwarding information for the traffic from IP1 to IP2 in the Routers:
PE1: in(<IP2,IP1>) --> out(Label2)
ASBR1: in(Label2) --> out(Label3)
ASBR2: in(Label3) --> out(Label4)
PE2: in(Label4) --> out(--)
Labels allocated by Flow policy process
Label4 allocated by PE2
Label3 allocated by ASBR2
Label2 allocated by ASBR1
|<------AS1----->| |<------AS2----->|
+-----+ +-----+ +-----+ +-----+
VPN 1,IP1..| PE1 |====|ASBR1|----|ASBR2|====| PE2 |..
IP2 +-----+ +-----+ +-----+ +-----+
| LDP LSP1 | | LDP LSP2 |
| -------> | | -------> |
|-------BGP VPN Flowspec LSP---->|
(Label2) (Label3) (Label4)
Figure 1 - Forwarding Diagram
</artwork>
</figure>
</t>
<t>
<figure>
<artwork>
BGP-FS rule1 (locally configured)
Filters:
destination ip prefix:IP2/32
source ip prefix:IP1/32
Actions:
traffic-marking: 1
MPLS POP
Note:
The following Extended Communities are added/deleted
[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]
BGP Filter rules
</artwork>
</figure>
</t>
<t>
<figure>
<artwork>
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
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
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
PE-1 Receives BGP-FS rule-1d (NLRI + 2 Extended Communities)
Installs BGP-FS rule-1d action [MPLS SWAP 2, traffic-marking]
</artwork>
</figure>
</t>
</section>
</section>
<section title="Security Considerations">
<t> The validation of BGP Flow Specification policy in NLRI is
considered in <xref target="I-D.hares-idr-flowspec-combo"></xref> for option 1, and for
option 2. Additional security has been proposed in <xref target="I-D.ietf-idr-bgp-flowspec-oid"></xref>.
A BGP5575bis document will consider the revised security.
</t>
<t>
For Option 1, the MPLS Match can be one of the match filters, 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-combo"></xref> and/or
an RFC5575bis document.
</t>
<t><xref target="I-D.hares-idr-flowspec-combo"></xref> suggests a default order for filters
and for the BGP-FS action proposed after <xref target="RFC5575"></xref>,
and this document discusses how conflicts between action are handled.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This section complies with <xref target="RFC7153"></xref>
</t>
<t>
IANA is requested to a new entry in “Flow Spec action types registry”
with the following values:
<figure>
<artwork>
Value Name: Value Reference
=========== ===== =========
Lable Action TBD [this document]
</artwork>
</figure>
</t>
</section>
<section title="Acknowledgement">
<t>
The authors would like to thank Shunwan Zhuang, Zhenbin Li, Peng Zhou
and Jeff Haas for their comments.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3031;
&RFC3032;
&RFC3107;
&RFC4271;
&RFC4360;
&RFC4364;
&RFC5575;
&RFC7153;
&RFC7674;
</references>
<references title="Informative References">
&I-D.ietf-idr-flow-spec-v6;
&I-D.ietf-idr-flowspec-l2vpn;
&I-D.hares-idr-flowspec-combo;
&I-D.ietf-idr-bgp-flowspec-oid;
&I-D.filsfils-spring-segment-routing-central-epe;
<reference anchor="I-D.yong-idr-flowspec-mpls-match">
<front>
<title>BGP Flow Specification Filter for MPLS Label</title>
<author fullname="Lucy Yong " initials="L." surname="Yong "></author>
<author fullname="Susan Hares " initials="S." surname="Hares "></author>
<author fullname="Qiandeng Liang " initials="Q." surname="Liang "></author>
<author fullname="Jianjie You " initials="J." surname="You "></author>
<date month="March" year="2016" />
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 10:07:53 |