< draft-li-idr-flowspec-rpd-04.txt   draft-li-idr-flowspec-rpd-05.txt >
Network Working Group Z. Li Network Working Group Z. Li
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track L. Ou Intended status: Standards Track L. Ou
Expires: September 11, 2019 Y. Luo Expires: January 8, 2020 Y. Luo
China Telcom Co., Ltd. China Telcom Co., Ltd.
S. Lu S. Lu
Tencent Tencent
H. Chen H. Chen
Futurewei
S. Zhuang S. Zhuang
H. Wang H. Wang
Huawei Huawei
March 10, 2019 July 7, 2019
BGP Extensions for Routing Policy Distribution (RPD) BGP Extensions for Routing Policy Distribution (RPD)
draft-li-idr-flowspec-rpd-04 draft-li-idr-flowspec-rpd-05
Abstract Abstract
It is hard to adjust traffic and optimize traffic paths on a It is hard to adjust traffic and optimize traffic paths on a
traditional IP network from time to time through manual traditional IP network from time to time through manual
configurations. It is desirable to have an automatic mechanism for configurations. It is desirable to have an automatic mechanism for
setting up routing policies, which adjust traffic and optimize setting up routing policies, which adjust traffic and optimize
traffic paths automatically. This document describes BGP Extensions traffic paths automatically. This document describes BGP Extensions
for Routing Policy Distribution (BGP RPD) to support this. for Routing Policy Distribution (BGP RPD) to support this.
skipping to change at page 1, line 48 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 8, 2020.
This Internet-Draft will expire on September 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statements . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statements . . . . . . . . . . . . . . . . . . . . . 3
3.1. Inbound Traffic Control . . . . . . . . . . . . . . . . . 4 3.1. Inbound Traffic Control . . . . . . . . . . . . . . . . . 3
3.2. Outbound Traffic Control . . . . . . . . . . . . . . . . 4 3.2. Outbound Traffic Control . . . . . . . . . . . . . . . . 4
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5
4.1. Extensions to BGP Floespec . . . . . . . . . . . . . . . 5 4.1. Using a New AFI and SAFI . . . . . . . . . . . . . . . . 5
4.1.1. Traffic Actions for Routing Policy Distribution . . . 6 4.2. BGP Wide Community . . . . . . . . . . . . . . . . . . . 6
4.2. Using a New AFI and SAFI . . . . . . . . . . . . . . . . 6 4.2.1. New Wide Community Atoms . . . . . . . . . . . . . . 6
4.3. BGP Wide Community . . . . . . . . . . . . . . . . . . . 7 4.3. Capability Negotiation . . . . . . . . . . . . . . . . . 12
4.3.1. New Wide Community Atoms . . . . . . . . . . . . . . 7 5. Consideration . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.2. Application Examples . . . . . . . . . . . . . . . . 12 5.1. Route-Policy . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Capability Negotiation . . . . . . . . . . . . . . . . . 20 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Consideration . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5.1. Route-Policy . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. BGP Policy Attribute . . . . . . . . . . . . . . . . 23
A.1. Match Fields . . . . . . . . . . . . . . . . . . . . . . 23
A.2. Action Fields . . . . . . . . . . . . . . . . . . . . . . 29
A.3. Application Examples . . . . . . . . . . . . . . . . . . 31
A.3.1. Change Attributes . . . . . . . . . . . . . . . . . . 31
A.3.2. Inbound Traffic Control . . . . . . . . . . . . . . . 32
A.3.3. Outbound Traffic Control . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
It is difficult to optimize traffic paths on a traditional IP network It is difficult to optimize traffic paths on a traditional IP network
because of: because of:
o Heavy configuration and error prone. Traffic can only be adjusted o Heavy configuration and error prone. Traffic can only be adjusted
device by device. All routers that the traffic traverses need to device by device. All routers that the traffic traverses need to
be configured. The configuration workload is heavy. The be configured. The configuration workload is heavy. The
operation is not only time consuming but also prone to operation is not only time consuming but also prone to
skipping to change at page 5, line 34 skipping to change at page 5, line 34
| +----+ | | +---------+ | | +----+ | | +---------+ |
+-------------------------+ +-----------------+ +-------------------------+ +-----------------+
Prefix2 advertised from AS200 to AS100 Prefix2 advertised from AS200 to AS100
<---------------------------------------- <----------------------------------------
Outbound Traffic Control case Outbound Traffic Control case
4. Protocol Extensions 4. Protocol Extensions
Two solutions are proposed. One extends BGP Floespec. The other A solution is proposed to use a new AFI and SAFI with the BGP Wide
uses a new AFI and SAFI. These solutions use the same BGP Wide
Community for encoding a routing policy. Community for encoding a routing policy.
4.1. Extensions to BGP Floespec 4.1. Using a New AFI and SAFI
BGP FlowSpec [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. Its typical application is for DDOS mitigation.
This document extends BGP Flowspec as a routing policy distribution
protocol (BGP RPD for short). It can be as powerful as the device-
based routing policy while still has the efficiency and convenience
of BGP Flowspec.
4.1.1. Traffic Actions for Routing Policy Distribution
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 [RFC5575]: Terminal Action (bit 47)
and Sample (bit 46). This document defines Routing Policy
Distribution (RPD, or R for short) Flag (Bit 45). The 6th byte with
this newly defined flag is illustrated below:
40 41 42 43 44 45 46 47
+---+---+---+---+---+---+---+---+
| reserved | R | S | T |
+---+---+---+---+---+---+---+---+
Traffic-action with RPD (R) flag
RPD (R) Flag (Bit 45): When this bit is set, the BGP Wide Community
will be used as a Routing Policy.
4.2. Using a New AFI and SAFI
A new AFI and SAFI are defined: the Routing Policy AFI whose A new AFI and SAFI are defined: the Routing Policy AFI whose
codepoint TBD1 is to be assigned by IANA, and SAFI whose codepoint codepoint TBD1 is to be assigned by IANA, and SAFI whose codepoint
TBD2 is to be assigned by IANA. TBD2 is to be assigned by IANA.
The AFI and SAFI pair uses a new NLRI, which is defined as follows: The AFI and SAFI pair uses a new NLRI, which is defined as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 7, line 17 skipping to change at page 6, line 39
The NLRI containing the Routing Policy is carried in a BGP UPDATE The NLRI containing the Routing Policy is carried in a BGP UPDATE
message, which MUST contain the BGP mandatory attributes and MAY also message, which MUST contain the BGP mandatory attributes and MAY also
contain some BGP optional attributes. contain some BGP optional attributes.
When receiving a BGP UPDATE message, a BGP speaker processes it only When receiving a BGP UPDATE message, a BGP speaker processes it only
if the peer IP address in the NLRI is the IP address of the BGP if the peer IP address in the NLRI is the IP address of the BGP
speaker or 0. speaker or 0.
The content of the Routing Policy is encoded in a BGP Wide Community. The content of the Routing Policy is encoded in a BGP Wide Community.
4.3. BGP Wide Community 4.2. BGP Wide Community
The BGP wide community is defined in The BGP wide community is defined in
[I-D.ietf-idr-wide-bgp-communities]. It can be used to facilitate [I-D.ietf-idr-wide-bgp-communities]. It can be used to facilitate
the delivery of new network services, and be extended easily for the delivery of new network services, and be extended easily for
distributing different kinds of routing policies. distributing different kinds of routing policies.
4.3.1. New Wide Community Atoms 4.2.1. New Wide Community Atoms
A wide community Atom is a TLV (or sub-TLV), which may be included in A wide community Atom is a TLV (or sub-TLV), which may be included in
a BGP wide community container (or BGP wide community for short) a BGP wide community container (or BGP wide community for short)
containing some BGP Wide Community TLVs. Three BGP Wide Community containing some BGP Wide Community TLVs. Three BGP Wide Community
TLVs are defined in [I-D.ietf-idr-wide-bgp-communities], which are TLVs are defined in [I-D.ietf-idr-wide-bgp-communities], which are
BGP Wide Community Target(s) TLV, Exclude Target(s) TLV, and BGP Wide Community Target(s) TLV, Exclude Target(s) TLV, and
Parameter(s) TLV. Each of these TLVs comprises a series of Atoms, Parameter(s) TLV. Each of these TLVs comprises a series of Atoms,
each of which is a TLV (or sub-TLV). A new wide community Atom is each of which is a TLV (or sub-TLV). A new wide community Atom is
defined for BGP Wide Community Target(s) TLV and a few new Atoms are defined for BGP Wide Community Target(s) TLV and a few new Atoms are
defined for BGP Wide Community Parameter(s) TLV. For your reference, defined for BGP Wide Community Parameter(s) TLV. For your reference,
skipping to change at page 8, line 50 skipping to change at page 8, line 33
Type: TBD2 (suggested value 1) for IPv4 Prefix is to be assigned by Type: TBD2 (suggested value 1) for IPv4 Prefix is to be assigned by
IANA. IANA.
Length: N x 8, where N is the number of tuples <M-Type, Flags, IPv4 Length: N x 8, where N is the number of tuples <M-Type, Flags, IPv4
Address, Mask, GeMask, LeMask>. Address, Mask, GeMask, LeMask>.
M-Type: 4 bits for match types, four of which are defined: M-Type: 4 bits for match types, four of which are defined:
M-Type = 0: Exact match. M-Type = 0: Exact match.
M-Type = 1: Match prefix greater and equal to the given maskes. M-Type = 1: Match prefix greater and equal to the given masks.
M-Type = 2: Match prefix less and equal to the given maskes. M-Type = 2: Match prefix less and equal to the given masks.
M-Type = 3: Match prefix within the range of the given maskes. M-Type = 3: Match prefix within the range of the given masks.
Flags: 4 bits. No flags are currently defined. Flags: 4 bits. No flags are currently defined.
IPv4 Address: 4 octets for an IPv4 address. IPv4 Address: 4 octets for an IPv4 address.
Mask: 1 octet for the mask length. Mask: 1 octet for the mask length.
GeMask: 1 octet for match range, must be less than Mask or be 0. GeMask: 1 octet for match range, must be less than Mask or be 0.
LeMask: 1 octet for match range, must be greater than Mask or be 0. LeMask: 1 octet for match range, must be greater than Mask or be 0.
skipping to change at page 12, line 34 skipping to change at page 12, line 7
by IANA. by IANA.
Length: n x 5. Length: n x 5.
ASi: 4 octet. An AS number. ASi: 4 octet. An AS number.
Counti: 1 octet. ASi repeats Counti times. Counti: 1 octet. ASi repeats Counti times.
The sequence of AS numbers are added to the existing AS Path. The sequence of AS numbers are added to the existing AS Path.
4.3.2. Application Examples 4.3. Capability Negotiation
4.3.2.1. Change Attributes
Multiple attributes of a route may be changed when it matches given
criteria. In the example below, the policy has the following
matching criteria:
o match 20.20.15.0/20 to 20.20.15.0/24
o match as-path 6553601 6553601
The actions to be applied are add 12345 to the existing MED and add
AS sequence 123456, 6553602, 6553602, 6553602, 6553602 to the end of
existing AS Path. These actions are listed as follows:
o apply MED = MED + 12345
o apply add as-path 123456, 6553602, 6553602, 6553602, 6553602
The corresponding BGP Wide Community Encoding for these is
illustrated below.
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 |Flags |0|1| Reserved(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length: 71 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Community: Change Attributes TBD11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS 64496 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context AS 64496 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target TLV: 1 | Length: 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PrefxRange:TBD3| Length: 6 | Flags (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaskLen: 20 | LeMaskLen: 24 |IPv4 Prefix: 20.20. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|.15 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Path: TBD5 | Length: 6 | OP: 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS 6553601 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ExcTargetTLV: 2| Length: 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Param TLV: 3| Length: 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ChangeMED: TBD8| Length: 5 | OP: 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value: 12345 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AddASPath: TBD7| Length: 11 | OP: 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS 123456 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS 6553602 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count 4 |
+-+-+-+-+-+-+-+-+
Example BGP Wide Community Encoding for Change Attributes
4.3.2.2. Inbound Traffic Control
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.
The encoding example using BGP Wide Community:
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 |Flags |0|1| Reserved(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length: 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Community: PREPEND N TIMES BY AS 17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS 100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context AS 100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ExcTargetTLV: 2| Length: 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IPv4Sess: TBD1 | Length: 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Address/Speaker #IGW2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Address/Speaker #Speaker1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Param TLV: 3 | Length: 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer: 4 | Length: 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prepend # 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example encoding for Inbound Traffic Control case
"PREPEND N TIMES BY AS" Wide Community has been defined in
[I-D.ietf-idr-registered-wide-bgp-communities].
The traffic destined for Prefix1 needs to be scheduled to link
Speaker1 -> IGW2 for transmission.
The Policy Controller constructs a BGP RPD route and pushes it to all
the IGW routers, the route carries:
1. Prefix1 in the Destination Prefix component of the BGP-FS NLRI;
2. Flow Specification Traffic Action Extended Community with the
Routing Policy Distribution (R) Flag (Bit 45) set. When this bit
is set, the corresponding filtering rules will be used as Routing
Policies.
3. NO_ADVERTISE Community [RFC1997]
4. Wide BGP Community Attribute:
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 session)
R = 17 P = Type_4 (0x05)
Where "BGP IPv4 session" Atom TLV contains:
The BGP session IPv4 local address: Local BGP Speaker IGW2
The BGP session IPv4 peer address: Remote BGP Peer Speaker1
IGW1 processes the received BGP-FS RPD route as follows:
1. IGW1 gets the target prefix Prefix1 from the Destination Prefix
component in the BGP FS NLRI of the BGP FS RPD route;
2. IGW1 identifies the Routing Policy Distribution (R) Flag carrying
in the Flow Specification Traffic Action Extended Community, then
IGW1 knows that the corresponding filtering rules will be used as
Routing Policies.
3. IGW1 uses the target prefix Prefix1 to choose the matching
routes, in this case, IGW1 will choose the current best route of
Prefix1;
4. IGW1 gets the action type from the Wide BGP Community Attribute:
PREPEND N TIMES BY AS;
5. IGW1 gets the matching criteria from the Wide BGP Community
Attribute: Exclude the BGP IPv4 session: <Local BGP Speaker IGW2,
Remote BGP Speaker1>;
6. IGW1 gets the parameter for "PREPEND N TIMES BY AS" from the Wide
BGP Community Attribute: 5 times;
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.
IGW2 processes the received BGP FS RPD route as follows:
1. IGW2 gets the target prefix Prefix1 from the Destination Prefix
component in the BGP-FS NLRI of the BGP FS RPD route;
2. IGW2 identifies the Routing Policy Distribution (R) Flag carrying
in the Flow Specification Traffic Action Extended Community, then
IGW2 knows that the corresponding filtering rules will be used as
Routing Policies.
3. IGW2 uses the target prefix Prefix1 to choose the matching
routes, in this case, IGW2 will choose the current best route of
Prefix1;
4. IGW2 gets the action type from the Wide BGP Community Attribute:
PREPEND N TIMES BY AS;
5. IGW2 gets the matching criteria from the BGP Policy Attribute:
Exclude the BGP IPv4 session: <Local BGP Speaker IGW2, Remote BGP
Speaker1>;
6. IGW2 gets the parameter for "PREPEND N TIMES BY AS" from the Wide
BGP Community Attribute: 5 times;
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.
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.
4.3.2.3. Outbound Traffic Control
As required in the case, traffic from PE2 to Prefix2 need to exit
through L3, so IGWs should prefer the route from IGW2 to Speaker1.
As shown in figure below, community "LOCAL PREFERENCE" and "Target(s)
TLV" are be used.
The encoding example using BGP Wide Community:
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 |Flags |0|1| Reserved(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length: 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Community: LOCAL PREFERENCE 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS 100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context AS 100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TargetTLV: 1 | Length: 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4Sess:TBD1| Length: 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Address/Speaker #IGW2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Address/Speaker #Speaker1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Param TLV: 3 | Length: 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer: 4 | Length: 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Increment # 100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example encoding for Outbound Traffic Control case
"LOCAL PREFERENCE" Wide Community has been defined in
[I-D.ietf-idr-registered-wide-bgp-communities].
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.
For example, the outbound traffic destined for Prefix2 needs to be
scheduled to link IGW2 -> Speaker1 for transmission.
The Policy Controller sends a BGP-FS RPD route to IGW2, the route
carries:
1. Prefix2 in the Destination Prefix component of the BGP-FS NLRI;
2. Flow Specification Traffic Action Extended Community with the RPD
(R) Flag (Bit 45) set. When this bit is set, the corresponding
filtering rules will be used as Routing Policies.
3. NO_ADVERTISE Community [RFC1997]
4. Wide BGP Community Attribute:
LOCAL PREFERENCE:
Type: 0x0001 S = src AS #
F = 0x80 C = 0x00000000
H = 0 T = Type_TBD (BGP IPv4 session)
L = 36 octets E = none
R = 20 P = Type_4 (0x64)
Where "BGP IPv4 session" Atom TLV contains:
The BGP session IPv4 local address: Local BGP Speaker IGW2
The BGP session IPv4 peer address: Remote BGP Peer Speaker1
IGW2 processes the received BGP FS RPD route as follows:
1. IGW2 gets the target prefix Prefix2 from the Destination Prefix
component in the BGP-FS NLRI of the BGP FS RPD route;
2. IGW2 identifies the Routing Policy Distribution (R) Flag carrying
in the Flow Specification Traffic Action Extended Community, then
IGW2 knows that the corresponding filtering rules will be used as
Routing Policies.
3. IGW2 uses the target prefix Prefix2 to choose the matching
routes, in this case, the prefix Prefix2 has two more routes:
Prefix Next-Hop Local BGP Speaker Remote BGP Peer
--------------------------------------------------------
Prefix2 Speaker1 IGW2 Speaker1
Prefix2 Speaker2 IGW2 Speaker2
...
4. IGW2 gets the action type from the Wide BGP Community Attribute:
LOCAL PREFERENCE;
5. IGW2 gets the matching criteria from the Wide BGP Community
Attribute: Local BGP Speaker IGW2, Remote BGP Peer Speaker1;
6. IGW2 gets the parameter for "LOCAL PREFERENCE" from the Wide BGP
Community Attribute: increment 100;
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.
4.4. Capability Negotiation
It is necessary to negotiate the capability to support BGP Extensions It is necessary to negotiate the capability to support BGP Extensions
for Routing Policy Distribution (RPD). The BGP RPD Capability is a for Routing Policy Distribution (RPD). The BGP RPD Capability is a
new BGP capability [RFC5492]. The Capability Code for this new BGP capability [RFC5492]. The Capability Code for this
capability is to be specified by the IANA. The Capability Length capability is to be specified by the IANA. The Capability Length
field of this capability is variable. The Capability Value field field of this capability is variable. The Capability Value field
consists of one or more of the following tuples: consists of one or more of the following tuples:
+--------------------------------------------------+ +--------------------------------------------------+
| Address Family Identifier (2 octets) | | Address Family Identifier (2 octets) |
skipping to change at page 21, line 47 skipping to change at page 13, line 45
6. Contributors 6. Contributors
The following people have substantially contributed to the definition The following people have substantially contributed to the definition
of the BGP-FS RPD and to the editing of this document: of the BGP-FS RPD and to the editing of this document:
Peng Zhou Peng Zhou
Huawei Huawei
Email: Jewpon.zhou@huawei.com Email: Jewpon.zhou@huawei.com
7. IANA Considerations 7. Security Considerations
TBD. Protocol extensions defined in this document do not affect the BGP
security other than those as discussed in the Security Considerations
section of [RFC5575].
8. Security Considerations 8. Acknowledgements
TBD. The authors would like to thank Acee Lindem, Jeff Haas, Jie Dong,
Lucy Yong, Qiandeng Liang, Zhenqiang Li for their comments to this
work.
9. Acknowledgements 9. IANA Considerations
The authors would like to thank Acee Lindem, Jeff Haas, Jie Dong, This document requests assigning a new AFI in the registry "Address
Haibo Wang, Lucy Yong, Qiandeng Liang, Zhenqiang Li for their Family Numbers" as follows:
comments to this work.
+-----------------------+-------------------------+-------------+
| Code Point | Description | Reference |
+-----------------------+-------------------------+-------------+
| TBD (36879 suggested) | Routing Policy AFI |This document|
+-------------------------------------------------+-------------+
This document requests assigning a new SAFI in the registry
"Subsequent Address Family Identifiers (SAFI) Parameters" as follows:
+-----------------------+-------------------------+-------------+
| Code Point | Description | Reference |
+-----------------------+-------------------------+-------------+
| TBD(179 suggested) | Routing Policy SAFI |This document|
+-----------------------+-------------------------+-------------+
This document defines a new registry called "Routing Policy NLRI".
The allocation policy of this registry is "First Come First Served
(FCFS)" according to [RFC8126].
Following code points are defined:
+-------------+-----------------------------------+-------------+
| Code Point | Description | Reference |
+-------------+-----------------------------------+-------------+
| 1 | Export Policy |This document|
+-------------+-----------------------------------+-------------+
| 2 | Import Policy |This document|
+-------------+-----------------------------------+-------------+
This document requests assigning a code-point from the registry "BGP
Community Container Atom Types" as follows:
+---------------------+------------------------------+-------------+
| TLV Code Point | Description | Reference |
+---------------------+------------------------------+-------------+
| TBD1 (48 suggested) | RouteAttr Atom |This document|
+---------------------+------------------------------+-------------+
This document defines a new registry called "Route Attributes Sub-
TLV" under RouteAttr Atom TLV. The allocation policy of this
registry is "First Come First Served (FCFS)" according to [RFC8126].
Following Sub-TLV code points are defined:
+-------------+-----------------------------------+-------------+
| Code Point | Description | Reference |
+-------------+-----------------------------------+-------------+
| 0 | Reserved | |
+-------------+-----------------------------------+-------------+
| 1 | IP Prefix Sub-TLV |This document|
+-------------+-----------------------------------+-------------+
| 2 | AS-Path Sub-TLV |This document|
+-------------+-----------------------------------+-------------+
| 3 | Community Sub-TLV |This document|
+-------------+-----------------------------------+-------------+
| 4 - 255 | To be assigned in FCFS | |
+-------------+-----------------------------------+-------------+
This document defines a new registry called "Attribute Change Sub-
TLV" under Parameter(s) TLV. The allocation policy of this registry
is "First Come First Served (FCFS)" according to [RFC8126].
Following Sub-TLV code points are defined:
+-------------+-----------------------------------+-------------+
| Code Point | Description | Reference |
+-------------+-----------------------------------+-------------+
| 0 | Reserved | |
+-------------+-----------------------------------+-------------+
| 1 | MED Change Sub-TLV |This document|
+-------------+-----------------------------------+-------------+
| 2 | AS-Path Change Sub-TLV |This document|
+-------------+-----------------------------------+-------------+
| 3 - 255 | To be assigned in FCFS | |
+-------------+-----------------------------------+-------------+
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-idr-wide-bgp-communities] [I-D.ietf-idr-wide-bgp-communities]
Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S., Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S.,
and P. Jakma, "BGP Community Container Attribute", draft- and P. Jakma, "BGP Community Container Attribute", draft-
ietf-idr-wide-bgp-communities-05 (work in progress), July ietf-idr-wide-bgp-communities-05 (work in progress), July
2018. 2018.
skipping to change at page 23, line 5 skipping to change at page 16, line 33
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <https://www.rfc-editor.org/info/rfc5492>. 2009, <https://www.rfc-editor.org/info/rfc5492>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<https://www.rfc-editor.org/info/rfc5575>. <https://www.rfc-editor.org/info/rfc5575>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-idr-registered-wide-bgp-communities] [I-D.ietf-idr-registered-wide-bgp-communities]
Raszuk, R. and J. Haas, "Registered Wide BGP Community Raszuk, R. and J. Haas, "Registered Wide BGP Community
Values", draft-ietf-idr-registered-wide-bgp-communities-02 Values", draft-ietf-idr-registered-wide-bgp-communities-02
(work in progress), May 2016. (work in progress), May 2016.
Appendix A. BGP Policy Attribute
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:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr Flag |Attr Type(TBD) | Attr Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Match fields (Variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Action fields (Variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format of BGP Policy Attribute
Match fields: Match Fields define the matching criteria for the BGP
Policy Attribute.
Action fields: Action fields define the action being applied to the
target route.
A.1. Match Fields
Match Fields define the matching criteria for the BGP Policy
Attribute. It has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Match Type (2 octets) | Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs (Variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Match Fields Format
Match Type:
1: 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 be done with this route.
2: 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 be done with this
route.
Length: The total length of the Sub-TLVs in the Match fields.
The contents of Match fields are encoded as Sub-TLVs, where each Sub-
TLV has the following format:
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 (2 octets) | Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Values (Variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-TLV Format
Type: The Type field contains a value of 1-65534. The values 0 and
65535 are reserved for future use.
Length: The Length field represents the total length of a given TLV's
value field in octets.
Values: The Value field contains the TLV value.
The following TLVs are defined:
Type TBD1: BGP IPv4 Session (or IPv4 Session for short), whose TLV
contains the IPv4 local address/speaker and remote address/speaker of
a BGP session. Its TLV (or Sub-TLV) format is illustrated below:
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) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format of IPv4 Session TLV
Type TBD2: BGP IPv6 Session (or IPv6 Session for short), whose TLV
contains the IPv6 local address/speaker and remote address/speaker of
a BGP session. Its TLV (or Sub-TLV) format is illustrated below:
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 (TBD2) | Length (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Local IPv6 Address (16 Bytes) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Remote IPv6 Address (16 Bytes) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format of IPv6 Session TLV
Type TBD3: IPv4 Prefix Range, which represents a range of IPv4
prefixes. Its format is illustrated below:
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 (TBD3) | Length (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaskLen | LeMaskLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaskLen | LeMaskLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format of IPv4 Prefix Range TLV
The IPv4 Prefix Range TLV (or Sub-TLV) contains a number of triple
<IPv4 Address, MaskLen, LeMaskLen>s. Each triple <IPv4 Address,
MaskLen, LeMaskLen> represents an IPv4 prefix range from IPv4-
Address/MaskLen to IPv4-Address/LeMaskLen. For example, triple
<10.10.0.0, 16, 16> represents prefixes 10.10.0.0/16 (i.e., from
10.10.0.0/16 to 10.10.0.0/16). Triple <20.20.15.0, 20, 24>
represents prefixes from 20.20.15.0/20 to 20.20.15.0/24.
The encoding of IPv4 Prefix Range may be optimized to the following
compact format:
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 (TBD3) | Length (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaskLen | LeMaskLen | IPv4 Prefix ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaskLen | LeMaskLen | IPv4 Prefix ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Compact Format of IPv4 Prefix Range TLV
It contains a number of triple <MaskLen, LeMaskLen, IPv4 Prefix>s.
Each triple <MaskLen, LeMaskLen, IPv4 Prefix> represents an IPv4
prefix range from IPv4-Prefix/MaskLen to IPv4-Prefix/LeMaskLen.
LeMaskLen is the length of the prefix. For example, triple <16, 16,
10.10.0.0> represents prefixes 10.10.0.0/16 (i.e., from 10.10.0.0/16
to 10.10.0.0/16). Triple <20, 24, 20.20.15.0> represents prefixes
from 20.20.15.0/20 to 20.20.15.0/24.
Similarly, Type TBD4: IPv6 Prefix Range represents a range of IPv6
prefixes. Its format is illustrated below:
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 (TBD4) | Length (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Address (16 Bytes) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaskLen | LeMaskLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 Address (16 Bytes) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaskLen | LeMaskLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format of IPv6 Prefix Range TLV
The encoding of IPv6 Prefix Range may be optimized to the following
compact format:
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 (TBD4) | Length (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaskLen | LeMaskLen | IPv6 Prefix ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaskLen | LeMaskLen | IPv6 Prefix ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Compact Format of IPv6 Prefix Range TLV
Type TBD5: AS Path, which represents a sequence of AS numbers. For
an AS number occurs multiple times in a row in a path, it is
represented by the AS number and a count indicating the times that
the AS number occurs. Its format is illustrated below:
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 (TBD5) | Length (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count1 |
+-+-+-+-+-+-+-+-+
~ . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Countn |
+-+-+-+-+-+-+-+-+
Format of AS Path TLV
For example, AS Path "123456, 6553603, 6553603, 6553603" is
represented by AS1 = 123456, Count1 = 1, AS2 = 6553603, and Count2 =
3.
Type TBD6: Communities, which represents a list of communities
values. Its format is illustrated below:
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 (TBD6) | Length (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Community 1 Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . . ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Community n Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format of Communities TLV
A.2. Action Fields
Action fields define the action being applied to the targeted route.
It has the following format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action Type (2 octets) | Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Action Values (Variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Action Fields Format
Action Type: The Action Type field contains a value of 1-65534. The
values 0 and 65535 are reserved for future use.
Action Length: The Action Length field represents the total length of
the Action Values in octets.
Action Values: The Action Values field contain parameters of the
action.
Supported format of the TLVs can be:
Type TBD7: Add AS Path, which indicates to add the sequence of AS
numbers represented in the TLV to AS Path. Its TLV (or Sub-TLV)
format is illustrated below:
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 (TBD7) | Length (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count1 |
+-+-+-+-+-+-+-+-+
~ . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Countn |
+-+-+-+-+-+-+-+-+
Format of Add AS Path TLV
When OP = 1, the sequence of AS numbers are added in the end of the
existing AS Path. When OP = 2, the sequence of AS numbers are added
in the front of the existing AS Path.
Type TBD8: Change Med, which indicates to change the Med according to
OP. Its TLV (or Sub-TLV) format is illustrated below:
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 (TBD8) | Length (5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format of Change Med TLV
When OP = 1, assign the Value to the existing Med. When OP = 2, add
the Value to the existing Med. If the sum of them is greater than
the maximum value for Med, assign the maximum value to Med. When OP
= 3, subtract the Value from the existing Med. If the existing Med
minus the Value is less than 0, assign 0 to Med.
Type TBD9: Deny, which indicates Deny action. Its TLV (or Sub-TLV)
format is illustrated below:
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 (TBD9) | Length (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format of Atom Deny
A.3. Application Examples
A.3.1. Change Attributes
Multiple attributes of a route may be changed when it matches given
matching criteria. In the example below, the policy has the
following matching criteria:
o match 20.20.15.0/20 to 20.20.15.0/24
o match as-path 6553601 6553601
The actions to be applied are add 12345 to the existing MED and add
AS sequence 123456, 6553602, 6553602 to the end of existing AS Path.
These actions are listed as follows:
o apply MED = MED + 12345
o apply add as-path 123456, 6553602, 6553602
The corresponding BGP Policy Attribute Encoding for these is
illustrated below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MatchType: 1 | Length: 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PrefxRange:TBD3 | Length: 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags (0) | MaskLen: 20 | LeMaskLen: 24 |IPv4 Prefix:20.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|20.15 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Path: TBD5 | Length: 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP: 1 | AS 6553601 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS-Contiue | Count 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ActionType: 3 | Length: 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Change MED: TBD8 | Length: 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP: 2 | Value: 12345 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Value-Contiue |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Add AS Path: TBD7 | Length: 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP: 1 | AS 123456 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS-Contiue | Count 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS 6553602 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count 2 |
+-+-+-+-+-+-+-+-+
Example BGP Policy Attribute Encoding for Change Attributes
A.3.2. Inbound Traffic Control
The traffic destined for Prefix1 needs to be scheduled to link
Speaker1 -> IGW2 for transmission.
The Policy Controller constructs a BGP-FS RPD route and pushes it to
all the IGW routers, the route carries:
1. Prefix1 in the Destination Prefix component of the BGP-FS NLRI;
2. Flow Specification Traffic Action Extended Community with the
Routing Policy Distribution (R) Flag (Bit 45) set. When this bit
is set, the corresponding filtering rules will be used as Routing
Policies.
3. NO_ADVERTISE Community [RFC1997]
4. BGP Policy Attribute:
* Match Type: 2, Deny
* IPv4 Session Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer
Speaker1
* Action Type: Route-Prepend-AS
* Action Value: Prepend-AS times is 5
IGW1 processes the received BGP-FS RPD route as follows:
1. IGW1 gets the target prefix Prefix1 from the Destination Prefix
component in the BGP FS NLRI of the BGP FS RPD route;
2. IGW1 identifies the Routing Policy Distribution (R) Flag carrying
in the Flow Specification Traffic Action Extended Community, then
IGW1 knows that the corresponding filtering rules will be used as
Routing Policies.
3. IGW1 uses the target prefix Prefix1 to choose the matching
routes, in this case, IGW1 will choose the current best route of
Prefix1;
4. IGW1 gets the matching criteria from the BGP Policy Attribute:
Local BGP Speaker IGW2, Remote BGP Speaker1;
5. IGW1 gets the action from the BGP Policy Attribute: Route-
Prepend-AS, 5 times;
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.
IGW2 processes the received BGP FS RPD route as follows:
1. IGW2 gets the target prefix Prefix1 from the Destination Prefix
component in the BGP-FS NLRI of the BGP FS RPD route;
2. IGW2 identifies the Routing Policy Distribution (R) Flag carrying
in the Flow Specification Traffic Action Extended Community, then
IGW2 knows that the corresponding filtering rules will be used as
Routing Policies.
3. IGW2 uses the target prefix Prefix1 to choose the matching
routes, in this case, IGW2 will choose the current best route of
Prefix1;
4. IGW2 gets the matching criteria from the BGP Policy Attribute:
Local BGP Speaker IGW2, Remote BGP Speaker1;
5. IGW2 gets the action from the BGP Policy Attribute: Route-
Prepend-AS, 5 times;
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.
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.
A.3.3. Outbound Traffic Control
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.
For example, the outbound traffic destined for Prefix2 needs to be
scheduled to link IGW2 -> Speaker1 for transmission.
The Policy Controller sends a BGP-FS RPD route to IGW2, the route
carries:
1. Prefix2 in the Destination Prefix component of the BGP-FS NLRI;
2. Flow Specification Traffic Action Extended Community with the
Routing Policy Distribution (R) Flag (Bit 45) set. When this bit
is set, the corresponding filtering rules will be used as Routing
Policies.
3. NO_ADVERTISE Community [RFC1997]
4. BGP Policy Attribute:
* Match Type: 1, Permit
* IPv4 Session Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer
Speaker1
* Action Type: Route-Preference
* Action Value: none
IGW2 processes the received BGP FS RPD route as follows:
1. IGW2 gets the target prefix Prefix2 from the Destination Prefix
component in the BGP-FS NLRI of the BGP FS RPD route;
2. IGW2 identifies the Routing Policy Distribution (R) Flag carrying
in the Flow Specification Traffic Action Extended Community, then
IGW2 knows that the corresponding filtering rules will be used as
Routing Policies.
3. IGW2 uses the target prefix Prefix2 to choose the matching
routes, in this case, the prefix Prefix2 has two more routes:
Prefix Next-Hop Local BGP Speaker Remote BGP Peer
Prefix2 Speaker1 IGW2 Speaker1
Prefix2 Speaker2 IGW2 Speaker2
...
4. IGW2 gets the matching criteria from the BGP Policy Attribute:
Local BGP Speaker IGW2, Remote BGP Peer Speaker1;
5. IGW2 gets the action from the BGP Policy Attribute: Route-
Preference;
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.
Authors' Addresses Authors' Addresses
Zhenbin Li Zhenbin Li
Huawei Huawei
Huawei Bld., No.156 Beiqing Rd. Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: lizhenbin@huawei.com Email: lizhenbin@huawei.com
Liang Ou Liang Ou
skipping to change at page 36, line 37 skipping to change at page 17, line 37
Sujian Lu Sujian Lu
Tencent Tencent
Tengyun Building,Tower A ,No. 397 Tianlin Road Tengyun Building,Tower A ,No. 397 Tianlin Road
Shanghai, Xuhui District 200233 Shanghai, Xuhui District 200233
China China
Email: jasonlu@tencent.com Email: jasonlu@tencent.com
Huaimo Chen Huaimo Chen
Huawei Futurewei
Boston, MA Boston, MA
USA USA
Email: Huaimo.chen@huawei.com Email: Huaimo.chen@futurewei.com
Shunwan Zhuang Shunwan Zhuang
Huawei Huawei
Huawei Bld., No.156 Beiqing Rd. Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: zhuangshunwan@huawei.com Email: zhuangshunwan@huawei.com
Haibo Wang Haibo Wang
Huawei Huawei
 End of changes. 26 change blocks. 
950 lines changed or deleted 123 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/