One document matched: draft-li-idr-flowspec-rpd-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-li-idr-flowspec-rpd-02" ipr="trust200902">
<front>
<title abbrev="BGP FS RPD">BGP FlowSpec Extensions for Routing Policy
Distribution (RPD)</title>
<author fullname="Zhenbin Li" initials="Z. " surname="Li">
<organization>Huawei</organization>
<address>
<postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>lizhenbin@huawei.com</email>
</address>
</author>
<author fullname="Liang Ou" initials="L. " surname="Ou">
<organization>China Telcom Co., Ltd.</organization>
<address>
<postal>
<street>109 West Zhongshan Ave,Tianhe District</street>
<city>Guangzhou</city>
<code>510630</code>
<country>China</country>
</postal>
<email>oul@gsta.com</email>
</address>
</author>
<author fullname="Yujia Luo" initials="Y. " surname="Luo">
<organization>China Telcom Co., Ltd.</organization>
<address>
<postal>
<street>109 West Zhongshan Ave,Tianhe District</street>
<city>Guangzhou</city>
<code>510630</code>
<country>China</country>
</postal>
<email>luoyuj@gsta.com</email>
</address>
</author>
<author fullname="Sujian Lu" initials="S." surname="Lu">
<organization>Tencent</organization>
<address>
<postal>
<street>Tengyun Building,Tower A ,No. 397 Tianlin Road</street>
<city>Shanghai</city>
<region>Xuhui District</region>
<code>200233</code>
<country>China</country>
</postal>
<phone/>
<facsimile/>
<email>jasonlu@tencent.com</email>
<uri/>
</address>
</author>
<author fullname="Shunwan Zhuang" initials="S. " surname="Zhuang">
<organization>Huawei</organization>
<address>
<postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>zhuangshunwan@huawei.com</email>
</address>
</author>
<author fullname="Nan Wu" initials="N. " surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>eric.wu@huawei.com</email>
</address>
</author>
<date day="17" month="June" year="2016"/>
<abstract>
<t>This document describes a mechanism to use BGP Flowspec address
family as routing-policy distribution protocol. This mechanism is called
BGP FlowSpec Extensions for Routing Policy Distribution (BGP-FS
RPD).</t>
</abstract>
<note 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">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>Some difficulties exist when optimize traffic paths on a traditional
IP network:<list style="symbols">
<t>Traffic can only be adjusted device by device. All routers that
the traffic traverses need to be configured. The configuration
workload is heavy. The operation is not only time consuming but also
prone to misconfiguration for Service Providers.</t>
<t>The routing policies used to control network routes are complex,
posing difficulties to subsequent maintenance, high maintenance
skills are required.</t>
</list></t>
<t>Hence, an automatic mechanism for setting up routing policies is
desirable which can simplify the complexity of routing policies
configuration. This document describes a mechanism to use BGP Flowspec
address family <xref target="RFC5575"/> as route-policy distribution
protocol. This mechanism is called BGP FlowSpec Extensions for Routing
Policy Distribution (BGP-FS RPD).</t>
</section>
<section title="Definitions and Acronyms">
<t>BGP Flow Specification route: BGP Flow Specification routes are
defined in RFC 5575. Each BGP Flow Specification route contains BGP
Network Layer Reachability Information (NLRI) and Extended Community
Attributes, which carry traffic filtering rules and actions to be taken
on filtered traffic.</t>
<t>BGP Flow Specification peer relationship: A BGP Flow Specification
peer relationship is established between the device that generates BGP
Flow Specification routes and each network ingress that will transmit
the BGP Flow Specification routes. After receiving the BGP Flow
Specification routes, the peer delivers preferred BGP Flow Specification
routes to the forwarding plane. The routes are then converted into
traffic policies that control attack traffic.</t>
<t><list style="symbols">
<t>ACL:Access Control List</t>
<t>BGP: Border Gateway Protocol</t>
<t>FS: Flow Specification</t>
<t>PBR:Policy-Based Routing</t>
<t>RPD: Routing Policy Distribution</t>
<t>VPN: Virtual Private Network</t>
</list></t>
</section>
<section title="Problem Statements">
<t>It is obvious that providers have the requirements to adjust their
business traffic from time to time because:<list style="symbols">
<t>Business development or network failure introduces link
congestion and overload.</t>
<t>Network transmission quality decreased as the result of delay,
loss and need to adjust traffic to other paths.</t>
<t>To control OPEX and CPEX, prefer the transit provider with lower
price.</t>
</list></t>
<section title="Inbound Traffic Control">
<t>In the scenario below, for reasons above, the provider of AS100
saying P may wish the inbound traffic from AS200 enters AS100 through
link L3 instead of others. Since P doesn't have administration over
AS200, so there is no way for P to modify the route selection criteria
directly.<figure align="center">
<artwork><![CDATA[ Traffic from PE1 to Prefix1
----------------------------------->
+-----------------+ +-------------------------+
| +---------+ | L1 | +----+ +----------+|
| |Speaker1 | +------------+ |IGW1| |policy ||
| +---------+ |** L2**| +----+ |controller||
| | ** ** | +----------+|
| +---+ | **** | |
| |PE1| | **** | |
| +---+ | ** ** | |
| +---------+ |** L3**| +----+ |
| |Speaker2 | +------------+ |IGW2| AS100 |
| +---------+ | L4 | +----+ |
| | | |
| AS200 | | |
| | | ... |
| | | |
| +---------+ | | +----+ +-------+ |
| |Speakern | | | |IGWn| |Prefix1| |
| +---------+ | | +----+ +-------+ |
+-----------------+ +-------------------------+
Prefix1 advertise from AS100 to AS200
<----------------------------------------
Figure 1: Inbound Traffic Control case
]]></artwork>
</figure></t>
</section>
<section title="Outbound Traffic Control">
<t>In this scenario, the provider of AS100 saying P wishes to prefer
link L3 for the traffic to the destination Prefix2 among multiple
exits and links. This preference can be dynamic and change frequently
because of the reasons above. So the provider P expects an efficient
and convenient solution.<figure align="center">
<artwork><![CDATA[ Traffic from PE2 to Prefix2
----------------------------------->
+-------------------------+ +-----------------+
|+----------+ +----+ |L1 | +---------+ |
||policy | |IGW1| +------------+ |Speaker1 | |
||controller| +----+ |** **| +---------+ |
|+----------+ |L2** ** | +-------+|
| | **** | |Prefix2||
| | **** | +-------+|
| |L3** ** | |
| AS100 +----+ |** **| +---------+ |
| |IGW2| +------------+ |Speaker2 | |
| +----+ |L4 | +---------+ |
| | | |
|+---+ | | AS200 |
||PE2| ... | | |
|+---+ | | |
| +----+ | | +---------+ |
| |IGWn| | | |Speakern | |
| +----+ | | +---------+ |
+-------------------------+ +-----------------+
Prefix2 advertise from AS200 to AS100
<----------------------------------------
Figure 2: Outbound Traffic Control case
]]></artwork>
</figure></t>
</section>
</section>
<section title="Proposed Solution">
<t>BGP FlowSpec <xref target="RFC5575"/> leverages the BGP control plane
to simplify the distribution of filter rules. New filter rules can be
injected to all BGP peers simultaneously without changing router
configuration. Though the typical application of it is for DDOS
mitigation, it doesn’t mean BGP Flowspec only takes effect on the
forwarding plane.</t>
<t>This document introduces a mechanism that uses BGP Flowspec as a
route-policy distribution protocol. It can be the same powerful as the
device-based route-policy while still has the efficiency and convenience
of BGP Flowspec.</t>
<t>This draft will use the term BGP-FS RPD as the abbreviation of
FlowSpec Extensions for Routing Policy Distribution.</t>
</section>
<section title="Protocol Extensions">
<t/>
<section title="FlowSpec Traffic Actions for Routing Policy Distribution">
<t>The traffic-action extended community consists of 6 bytes of which
only the 2 least significant bits of the 6th byte (from left to right)
are currently defined in <xref target="RFC5575"/>. Terminal Action
(bit 47) and Sample (bit 46) defines in <xref target="RFC5575"/>, this
document defines Route Policy Distribution Flag(Bit 45).</t>
<t>The Flow Specification Traffic Actions for Routing Policy
Distribution:</t>
<t><figure>
<artwork align="center"><![CDATA[
40 41 42 43 44 45 46 47
+---+---+---+---+---+---+---+---+
| reserved | R | S | T |
+---+---+---+---+---+---+---+---+
Figure 3: FlowSpec Traffic-action
]]></artwork>
</figure>Route Policy Distribution Flag(Bit 45): When this bit is
set, the corresponding filtering rules will be used as Route
Policy.</t>
</section>
<section title="Option 1: BGP Policy Attribute">
<t>This document defines and uses a new BGP attribute called the "BGP
Policy attribute". This is an optional BGP attribute. The format of
this attribute is defined as follows:</t>
<t><figure>
<artwork align="center"><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Match fields (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Action fields (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: BGP Policy Attribute
]]></artwork>
</figure>Match fields: Match Fields define the matching criteria for
the BGP Policy Attribute.</t>
<t>Action fields: Action fields define the action being applied to the
target route.</t>
<t/>
<section title="Match Fields Format">
<t>Match Fields define the matching criteria for the BGP Policy
Attribute.</t>
<t><figure>
<artwork align="center"><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Match Type (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Sub-TLVs (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sub-TLVs (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Match Fields Format
]]></artwork>
</figure></t>
<t>Match Type:</t>
<t>0: Permit, specifies the permit mode of a match rule. If a route
matches the matching criteria of the BGP Policy Attribute, the
actions defined by the Action fields of the BGP Policy Attribute are
performed. If a route does not match the matching criteria for the
BGP Policy Attribute, then nothing needs to do with this route.</t>
<t>1: Deny, specifies the deny mode of a match rule. In the deny
mode, If a route does not match the matching criteria of the BGP
Policy Attribute, the actions defined by the Action fields of the
BGP Policy Attribute are performed. If a route matches the matching
criteria of the BGP Policy Attribute, then nothing needs to do with
this route.</t>
<t>Number of Sub-TLVs: The number of Sub-TLVs contain in Match
fields.</t>
<t/>
<t>The contents of Match fields are encoded as Sub-TLVs, where each
TLV has the following format:</t>
<t><figure>
<artwork align="center"><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Values (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Sub-TLVs Format
]]></artwork>
</figure></t>
<t>Type: The Type field contains a value of 1-65534. The values 0
and 65535 are reserved for future use.</t>
<t>Length: The Length field represents the total length of a given
TLV's value field in octets.</t>
<t>Values: The Value field contains the TLV value.</t>
<t>Supported format of the TLVs can be:</t>
<t>Type 1: IPv4 Neighbor</t>
<t>Type 2: IPv6 Neighbor</t>
<t>Type 3: ASN List</t>
<t>...</t>
<t>To be added in later versions.</t>
</section>
<section title="Action Fields Format">
<t>Action fields define the action being applied to the targeted
route.</t>
<t><figure>
<artwork align="center"><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action Type (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Action Values (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Action Fields Format
]]></artwork>
</figure>Action Type: The Action Type field contains a value of
1-65534. The values 0 and 65535 are reserved for future use.</t>
<t>Action Length: The Action Length field represents the total
length of the Action Values in octets.</t>
<t>Action Values: The Action Values field contain parameters of the
action.</t>
<t>Supported format of the TLVs can be:</t>
<t>Type 1: Route-Preference</t>
<t>Type 2: Route-Prepend-AS</t>
<t>...</t>
<t>To be added in later versions.</t>
</section>
<section title="Operation Examples">
<t/>
<section title="Inbound Traffic Control">
<t>The traffic destined for Prefix1 needs to be scheduled to link
Speaker1 -> IGW2 for transmission.</t>
<t>The Policy Controller constructs a BGP-FS RPD route and pushes
it to all the IGW routers, the route carries:<list style="numbers">
<t>Prefix1 in the Destination Prefix component of the BGP-FS
NLRI;</t>
<t>Flow Specification Traffic Action Extended Community with
the Route Policy Distribution Flag(Bit 45) set. When this bit
is set, the corresponding filtering rules will be used as
Routing Policies.</t>
<t>NO_ADVERTISE Community <xref target="RFC1997"/></t>
<t>BGP Policy Attribute:<list style="symbols">
<t>Match Type: 2, Deny</t>
<t>IPv4 Neighbor Sub-TLV: Local BGP Speaker IGW2, Remote
BGP Peer Speaker1</t>
<t>Action Type: Route-Prepend-AS</t>
<t>Action Value: Prepend-AS times is 5</t>
</list></t>
</list></t>
<t>IGW1 processes the received BGP-FS RPD route as follows:<list
style="numbers">
<t>IGW1 gets the target prefix Prefix1 from the Destination
Prefix component in the BGP FS NLRI of the BGP FS RPD
route;</t>
<t>IGW1 identifies the Route Policy Distribution Flag carrying
in the Flow Specification Traffic Action Extended Community,
then IGW1 knows that the corresponding filtering rules will be
used as Routing Policies.</t>
<t>IGW1 uses the target prefix Prefix1 to choose the matching
routes, in this case, IGW1 will choose the current best route
of Prefix1;</t>
<t>IGW1 gets the matching criteria from the BGP Policy
Attribute: Local BGP Speaker IGW2, Remote BGP Speaker1;</t>
<t>IGW1 gets the action from the BGP Policy Attribute:
Route-Prepend-AS, 5 times;</t>
</list></t>
<t>IGW1 checks the matching criteria and finds that it doesn't
hits the matching criteria: Local BGP Speaker IGW2, Remote BGP
Speaker1, at the same time the Match Type is "Deny" mode, so IGW1
sends the best route of Prefix1 to Speaker1 and Speaker2 with
performing the Action instructions from the BGP-FS RPD route:
Prepend Local AS 5 times.</t>
<t>IGW2 processes the received BGP FS RPD route as follows:<list
style="numbers">
<t>IGW2 gets the target prefix Prefix1 from the Destination
Prefix component in the BGP-FS NLRI of the BGP FS RPD
route;</t>
<t>IGW2 identifies the Route Policy Distribution Flag carrying
in the Flow Specification Traffic Action Extended Community,
then IGW2 knows that the corresponding filtering rules will be
used as Routing Policies.</t>
<t>IGW2 uses the target prefix Prefix1 to choose the matching
routes, in this case, IGW2 will choose the current best route
of Prefix1;</t>
<t>IGW2 gets the matching criteria from the BGP Policy
Attribute: Local BGP Speaker IGW2, Remote BGP Speaker1;</t>
<t>IGW2 gets the action from the BGP Policy Attribute:
Route-Prepend-AS, 5 times;</t>
</list></t>
<t>IGW2 checks the matching criteria and finds that there is a
speaker which hits the matching criteria: Local BGP Speaker IGW2,
Remote BGP Peer Speaker1, but the Match Type is "Deny" mode, so
IGW2 sends the best route of Prefix1 to Speaker1, without
performing the Action instructions from the BGP-FS RPD route. At
the same time, IGW2 sends the best route of Prefix1 to Speaker2
with performing the Action instructions from the BGP-FS RPD route:
Prepend Local AS 5 times.</t>
<t>In the similar manner, other IGWs will perform the same Action
instructions as IGW1. Then the traffic destined for Prefix1 has
been be scheduled to link L3 for transmission.</t>
</section>
<section title="Outbound Traffic Control">
<t>In this scenario, if the bandwidth usage of a link exceeds the
specified threshold, the Policy Controller automatically
identifies which traffic needs to be scheduled and the Policy
Controller automatically calculates traffic control paths based on
network topology and traffic information.</t>
<t>For example, the outbound traffic destined for Prefix2 needs to
be scheduled to link IGW2 -> Speaker1 for transmission.</t>
<t>The Policy Controller sends a BGP-FS RPD route to IGW2, the
route carries:<list style="numbers">
<t>Prefix2 in the Destination Prefix component of the BGP-FS
NLRI;</t>
<t>Flow Specification Traffic Action Extended Community with
the Route Policy Distribution Flag(Bit 45) set. When this bit
is set, the corresponding filtering rules will be used as
Routing Policies.</t>
<t>NO_ADVERTISE Community <xref target="RFC1997"/></t>
<t>BGP Policy Attribute:<list style="symbols">
<t>Match Type: 1, Permit</t>
<t>IPv4 Neighbor Sub-TLV: Local BGP Speaker IGW2, Remote
BGP Peer Speaker1</t>
<t>Action Type: Route-Preference</t>
<t>Action Value: none</t>
</list></t>
</list>IGW2 processes the received BGP FS RPD route as
follows:<list style="numbers">
<t>IGW2 gets the target prefix Prefix2 from the Destination
Prefix component in the BGP-FS NLRI of the BGP FS RPD
route;</t>
<t>IGW2 identifies the Route Policy Distribution Flag carrying
in the Flow Specification Traffic Action Extended Community,
then IGW2 knows that the corresponding filtering rules will be
used as Routing Policies.</t>
<t>IGW2 uses the target prefix Prefix2 to choose the matching
routes, in this case, the prefix Prefix2 has two more
routes:<figure align="center">
<artwork><![CDATA[ Prefix Next-Hop Local BGP Speaker Remote BGP Peer
Prefix2 Speaker1 IGW2 Speaker1
Prefix2 Speaker2 IGW2 Speaker2
...
]]></artwork>
</figure></t>
<t>IGW2 gets the matching criteria from the BGP Policy
Attribute: Local BGP Speaker IGW2, Remote BGP Peer
Speaker1;</t>
<t>IGW2 gets the action from the BGP Policy Attribute:
Route-Preference;</t>
</list></t>
<t>So IGW2 chooses the BGP route received from Speaker1 instead of
Speaker2 as the best route and the outbound traffic destined for
Prefix2 can be scheduled to link L3 for transmission.</t>
</section>
</section>
</section>
<section title="Option 2: BGP Wide Community">
<t>This section describes the option 2 for protocol extensions, which
is completely different from section 5.2 by reusing BGP Wide Community
introduced in <xref target="I-D.ietf-idr-wide-bgp-communities"/>.</t>
<t>BGP Wide Community Attribute is a very useful tool that it can be
used to convey different kinds of routing policies.</t>
<section title="New Wide Community Atoms">
<t>Wide Community Atoms define in <xref
target="I-D.ietf-idr-wide-bgp-communities"/> , in that draft it
defines Type 1 to Type 8.</t>
<t>New wide community atoms have to be introduced since the entrance
and exit of traffic need to be designated precisely.</t>
<figure align="center">
<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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Wide Community Atoms
]]></artwork>
</figure>
<t>Supported format of the TLVs can be:<list style="symbols">
<t>Type 1: Autonomous System number list</t>
<t>Type 2: IPv4 prefix (1 octet prefix length + prefix) list</t>
<t>Type 3: IPv6 prefix (1 octet prefix length + prefix) list</t>
<t>Type 4: Integer list</t>
<t>Type 5: IEEE Floating Point Number list</t>
<t>Type 6: Neighbor Class list</t>
<t>Type 7: User-defined Class list7</t>
<t>Type 8: UTF-8 String</t>
<t>Type TBD: BGP IPv4 neighbor --- Newly introduced in this
draft, which contains the BGP session IPv4 local address and the
BGP session IPv4 peer address.</t>
<t>Type TBD: BGP IPv6 neighbor --- Newly introduced in this
draft, which contains the BGP session IPv6 local address and the
BGP session IPv6 peer address.</t>
</list></t>
</section>
<section title="Operation examples">
<t/>
<section title="Inbound Traffic Control">
<t>As required in the case, traffic from PE1 to Prefix1 need to
enter through L3, so IGWs except IGW2 should prepend ASN list to
Prefix1 when populating to AS100. As shown in figure below,
community "PREPEND N TIMES BY AS" and "Exclude Target(s) TLV" are
be used.</t>
<t>The encoding example using BGP Wide Community:</t>
<t><figure align="center">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Container Type 1 (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+
| Hop Count: 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length: 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Community: PREPEND N TIMES BY AS 17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Own ASN 100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context ASN# 100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ExcTargetTLV(2)| Length: 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4Neig(TBD)| Length: 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Speaker #IGW2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Speaker #Speaker1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Param TLV (3) | Length: 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer (4) | Length: 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prepend # 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Example encoding for Inbound Traffic Control case
]]></artwork>
</figure>"PREPEND N TIMES BY AS" Wide Community has been defined
in <xref
target="I-D.ietf-idr-registered-wide-bgp-communities"/>.</t>
<t>The traffic destined for Prefix1 needs to be scheduled to link
Speaker1 -> IGW2 for transmission.</t>
<t>The Policy Controller constructs a BGP-FS RPD route and pushes
it to all the IGW routers, the route carries:</t>
<t><list style="numbers">
<t>Prefix1 in the Destination Prefix component of the BGP-FS
NLRI;</t>
<t>Flow Specification Traffic Action Extended Community with
the Route Policy Distribution Flag(Bit 45) set. When this bit
is set, the corresponding filtering rules will be used as
Routing Policies.</t>
<t>NO_ADVERTISE Community <xref target="RFC1997"/></t>
<t>Wide BGP Community Attribute:<figure>
<artwork><![CDATA[PREPEND N TIMES BY AS:
Type: 0x0001 S = src AS #
F = 0x80 C = 0x00000000
H = 0 T = none
L = 36 octets E = Type_TBD (BGP IPv4 neighbor)
R = 17 P = Type_4 (0x05)
Where "BGP IPv4 neighbor" Atom TLV contains:
The BGP session IPv4 local address: Local BGP Speaker IGW2
The BGP session IPv4 peer address: Remote BGP Peer Speaker1
]]></artwork>
</figure></t>
</list>IGW1 processes the received BGP-FS RPD route as
follows:</t>
<t><list style="numbers">
<t>IGW1 gets the target prefix Prefix1 from the Destination
Prefix component in the BGP FS NLRI of the BGP FS RPD
route;</t>
<t>IGW1 identifies the Route Policy Distribution Flag carrying
in the Flow Specification Traffic Action Extended Community,
then IGW1 knows that the corresponding filtering rules will be
used as Routing Policies.</t>
<t>IGW1 uses the target prefix Prefix1 to choose the matching
routes, in this case, IGW1 will choose the current best route
of Prefix1;</t>
<t>IGW1 gets the action type from the Wide BGP Community
Attribute: PREPEND N TIMES BY AS;</t>
<t>IGW1 gets the matching criteria from the Wide BGP Community
Attribute: Exclude the BGP IPv4 neighbor: <Local BGP
Speaker IGW2, Remote BGP Speaker1>;</t>
<t>IGW1 gets the parameter for "PREPEND N TIMES BY AS" from
the Wide BGP Community Attribute: 5 times;</t>
</list>IGW1 checks the matching criteria and finds that it
doesn't hits the exclude matching criteria: Local BGP Speaker
IGW2, Remote BGP Speaker1, so IGW1 sends the best route of Prefix1
to Speaker1 and Speaker2 with performing the Action instructions
from the BGP-FS RPD route: Prepend Local AS 5 times.</t>
<t>IGW2 processes the received BGP FS RPD route as follows:</t>
<t><list style="numbers">
<t>IGW2 gets the target prefix Prefix1 from the Destination
Prefix component in the BGP-FS NLRI of the BGP FS RPD
route;</t>
<t>IGW2 identifies the Route Policy Distribution Flag carrying
in the Flow Specification Traffic Action Extended Community,
then IGW2 knows that the corresponding filtering rules will be
used as Routing Policies.</t>
<t>IGW2 uses the target prefix Prefix1 to choose the matching
routes, in this case, IGW2 will choose the current best route
of Prefix1;</t>
<t>IGW2 gets the action type from the Wide BGP Community
Attribute: PREPEND N TIMES BY AS;</t>
<t>IGW2 gets the matching criteria from the BGP Policy
Attribute: Exclude the BGP IPv4 neighbor: <Local BGP
Speaker IGW2, Remote BGP Speaker1>;</t>
<t>IGW2 gets the parameter for "PREPEND N TIMES BY AS" from
the Wide BGP Community Attribute: 5 times;</t>
</list>IGW2 checks the matching criteria and finds that there is
a speaker which hits the exclude matching criteria: Local BGP
Speaker IGW2, Remote BGP Peer Speaker1, so IGW2 sends the best
route of Prefix1 to Speaker1 without performing the Action
instructions from the BGP-FS RPD route, at the same time, IGW2
sends the best route of Prefix1 to Speaker2 with performing the
Action instructions from the BGP-FS RPD route: Prepend Local AS 5
times.</t>
<t>In the similar manner, other IGWs will perform the same Action
instructions as IGW1. Then the traffic destined for Prefix1 has
been be scheduled to link L3 for transmission.</t>
</section>
<section title="Outbound Traffic Control">
<t>As required in the case, traffic from PE2 to Prefix2 need to
exit through L3, so IGWs should perfer the route from IGW2 to
Speaker1. As shown in figure below, community "LOCAL PREFERENCE"
and "Target(s) TLV" are be used.</t>
<t>The encoding example using BGP Wide Community:</t>
<t><figure>
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Container Type 1 (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+
| Hop Count: 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length: 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Community: LOCAL PREFERENCE 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Own ASN 100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context ASN# 100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TargetTLV(1) | Length: 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4Neig(TBD)| Length: 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Speaker #IGW2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Speaker #Speaker1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Param TLV (3) | Length: 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer (4) | Length: 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Increment # 100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Example encoding for Outbound Traffic Control case ]]></artwork>
</figure>"LOCAL PREFERENCE" Wide Community has been defined in
<xref target="I-D.ietf-idr-registered-wide-bgp-communities"/></t>
<t>In this scenario, if the bandwidth usage of a link exceeds the
specified threshold, the Policy Controller automatically
identifies which traffic needs to be scheduled and the Policy
Controller automatically calculates traffic control paths based on
network topology and traffic information.</t>
<t>For example, the outbound traffic destined for Prefix2 needs to
be scheduled to link IGW2 -> Speaker1 for transmission.</t>
<t>The Policy Controller sends a BGP-FS RPD route to IGW2, the
route carries:</t>
<t><list style="numbers">
<t>Prefix2 in the Destination Prefix component of the BGP-FS
NLRI;</t>
<t>Flow Specification Traffic Action Extended Community with
the Route Policy Distribution Flag(Bit 45) set. When this bit
is set, the corresponding filtering rules will be used as
Routing Policies.</t>
<t>NO_ADVERTISE Community <xref target="RFC1997"/></t>
<t>Wide BGP Community Attribute:<figure>
<artwork><![CDATA[LOCAL PREFERENCE:
Type: 0x0001 S = src AS #
F = 0x80 C = 0x00000000
H = 0 T = Type_TBD (BGP IPv4 neighbor)
L = 36 octets E = none
R = 20 P = Type_4 (0x64)
Where "BGP IPv4 neighbor" Atom TLV contains:
The BGP session IPv4 local address: Local BGP Speaker IGW2
The BGP session IPv4 peer address: Remote BGP Peer Speaker1
]]></artwork>
</figure></t>
</list>IGW2 processes the received BGP FS RPD route as
follows:</t>
<t><list style="numbers">
<t>IGW2 gets the target prefix Prefix2 from the Destination
Prefix component in the BGP-FS NLRI of the BGP FS RPD
route;</t>
<t>IGW2 identifies the Route Policy Distribution Flag carrying
in the Flow Specification Traffic Action Extended Community,
then IGW2 knows that the corresponding filtering rules will be
used as Routing Policies.</t>
<t>IGW2 uses the target prefix Prefix2 to choose the matching
routes, in this case, the prefix Prefix2 has two more
routes:<figure align="center">
<artwork><![CDATA[ Prefix Next-Hop Local BGP Speaker Remote BGP Peer
--------------------------------------------------------
Prefix2 Speaker1 IGW2 Speaker1
Prefix2 Speaker2 IGW2 Speaker2
...
]]></artwork>
</figure></t>
<t>IGW2 gets the action type from the Wide BGP Community
Attribute: LOCAL PREFERENCE;</t>
<t>IGW2 gets the matching criteria from the Wide BGP Community
Attribute: Local BGP Speaker IGW2, Remote BGP Peer
Speaker1;</t>
<t>IGW2 gets the parameter for "LOCAL PREFERENCE" from the
Wide BGP Community Attribute: increment 100;</t>
</list>So IGW2 chooses the BGP route received from Speaker1
instead of Speaker2 as the best route and the outbound traffic
destined for Prefix2 can be scheduled to link L3 for
transmission.</t>
<t/>
</section>
</section>
</section>
<section title="Capability Negotiation">
<t>It is necessary to negotiate the capability to support BGP FlowSpec
Extensions for Route Policy Distribution (RPD). The BGP FS RPD
Capability is a new BGP capability <xref target="RFC5492"/>. The
Capability Code for this capability is to be specified by the IANA.
The Capability Length field of this capability is variable. The
Capability Value field consists of one or more of the following
tuples:</t>
<t><figure>
<artwork align="center"><![CDATA[
+--------------------------------------------------+
| Address Family Identifier (2 octets) |
+--------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+--------------------------------------------------+
| Send/Receive (1 octet) |
+--------------------------------------------------+
Figure 11: BGP FS RPD Capability
]]></artwork>
</figure></t>
<t>The meaning and use of the fields are as follows:</t>
<t>Address Family Identifier (AFI): This field is the same as the one
used in <xref target="RFC4760"/>.</t>
<t>Subsequent Address Family Identifier (SAFI): This field is the same
as the one used in <xref target="RFC4760"/>.</t>
<t>Send/Receive: This field indicates whether the sender is (a)
willing to receive Route Policies via BGP FLowSpec from its peer
(value 1), (b) would like to send Route Policies via BGP FLowSpec to
its peer (value 2), or (c) both (value 3) for the <AFI,
SAFI>.</t>
</section>
</section>
<section title="Consideration">
<t/>
<section title="Route-Policy">
<t>Routing policies are used to filter routes and control how routes
are received and advertised. If route attributes, such as
reachability, are changed, the path along which network traffic passes
changes accordingly.</t>
<t>When advertising, receiving, and importing routes, the router
implements certain policies based on actual networking requirements to
filter routes and change the attributes of the routes. Routing
policies serve the following purposes:<list style="symbols">
<t>Control route advertising: Only routes that match the rules
specified in a policy are advertised.</t>
<t>Control route receiving: Only the required and valid routes are
received. This reduces the size of the routing table and improves
network security.</t>
<t>Filter and control imported routes: A routing protocol may
import routes discovered by other routing protocols. Only routes
that satisfy certain conditions are imported to meet the
requirements of the protocol.</t>
<t>Modify attributes of specified routes Attributes of the routes:
that are filtered by a routing policy are modified to meet the
requirements of the local device.</t>
<t>Configure fast reroute (FRR): If a backup next hop and a backup
outbound interface are configured for the routes that match a
routing policy, IP FRR, VPN FRR, and IP+VPN FRR can be
implemented.</t>
</list>Routing policies are implemented using the following
procedures:<list style="numbers">
<t>Define rules: Define features of routes to which routing
policies are applied. Users define a set of matching rules based
on different attributes of routes, such as the destination address
and the address of the router that advertises the routes.</t>
<t>Implement the rules: Apply the matching rules to routing
policies for advertising, receiving, and importing routes.</t>
</list></t>
</section>
</section>
<section title="Contributors">
<t>The following people have substantially contributed to the definition
of the BGP-FS RPD and to the editing of this document:<figure
align="left">
<artwork><![CDATA[Peng Zhou
Huawei
Email: Jewpon.zhou@huawei.com
]]></artwork>
</figure></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>TBD.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Acee Lindem, Jeff Haas, Jie Dong,
Haibo Wang, Lucy Yong, Qiandeng Liang, Zhenqiang Li for their comments
to this work.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.1997'?>
<?rfc include='reference.RFC.4271'?>
<?rfc include='reference.RFC.4760'?>
<?rfc include='reference.RFC.5575'?>
<?rfc include='reference.RFC.5492'?>
<?rfc include='reference.I-D.ietf-idr-wide-bgp-communities'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-idr-registered-wide-bgp-communities'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:36:50 |