draft-li-idr-flowspec-rpd-02.txt   draft-li-idr-flowspec-rpd-03.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: December 19, 2016 Y. Luo Expires: April 25, 2019 Y. Luo
China Telcom Co., Ltd. China Telcom Co., Ltd.
S. Lu S. Lu
Tencent Tencent
H. Chen
S. Zhuang S. Zhuang
N. Wu N. Wu
Huawei Huawei
June 17, 2016 October 22, 2018
BGP FlowSpec Extensions for Routing Policy Distribution (RPD) BGP FlowSpec Extensions for Routing Policy Distribution (RPD)
draft-li-idr-flowspec-rpd-02 draft-li-idr-flowspec-rpd-03
Abstract Abstract
This document describes a mechanism to use BGP Flowspec address This document describes a mechanism to use BGP Flowspec address
family as routing-policy distribution protocol. This mechanism is family as routing-policy distribution protocol. This mechanism is
called BGP FlowSpec Extensions for Routing Policy Distribution (BGP- called BGP FlowSpec Extensions for Routing Policy Distribution (BGP-
FS RPD). FS RPD).
Requirements Language Requirements Language
skipping to change at page 1, line 39 skipping to change at page 1, line 40
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 December 19, 2016. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3
3. Problem Statements . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statements . . . . . . . . . . . . . . . . . . . . . 4
3.1. Inbound Traffic Control . . . . . . . . . . . . . . . . . 4 3.1. Inbound Traffic Control . . . . . . . . . . . . . . . . . 4
3.2. Outbound Traffic Control . . . . . . . . . . . . . . . . 5 3.2. Outbound Traffic Control . . . . . . . . . . . . . . . . 5
4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 6
5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6 5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6
5.1. FlowSpec Traffic Actions for Routing Policy Distribution 6 5.1. Traffic Actions for Routing Policy Distribution . . . . . 7
5.2. Option 1: BGP Policy Attribute . . . . . . . . . . . . . 6 5.2. Option 1: BGP Policy Attribute . . . . . . . . . . . . . 7
5.2.1. Match Fields Format . . . . . . . . . . . . . . . . . 7 5.2.1. Match Fields . . . . . . . . . . . . . . . . . . . . 8
5.2.2. Action Fields Format . . . . . . . . . . . . . . . . 8 5.2.2. Action Fields . . . . . . . . . . . . . . . . . . . . 13
5.2.3. Operation Examples . . . . . . . . . . . . . . . . . 9 5.2.3. Application Examples . . . . . . . . . . . . . . . . 15
5.3. Option 2: BGP Wide Community . . . . . . . . . . . . . . 12 5.3. Option 2: BGP Wide Community . . . . . . . . . . . . . . 19
5.3.1. New Wide Community Atoms . . . . . . . . . . . . . . 12 5.3.1. New Wide Community Atoms . . . . . . . . . . . . . . 20
5.3.2. Operation examples . . . . . . . . . . . . . . . . . 13 5.3.2. New Wide Community Actions . . . . . . . . . . . . . 26
5.4. Capability Negotiation . . . . . . . . . . . . . . . . . 19 5.3.3. Application Examples . . . . . . . . . . . . . . . . 27
6. Consideration . . . . . . . . . . . . . . . . . . . . . . . . 19 5.4. Capability Negotiation . . . . . . . . . . . . . . . . . 34
6.1. Route-Policy . . . . . . . . . . . . . . . . . . . . . . 19 6. Consideration . . . . . . . . . . . . . . . . . . . . . . . . 34
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Route-Policy . . . . . . . . . . . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
11.1. Normative References . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
Some difficulties exist when optimize traffic paths on a traditional It is difficult to optimize traffic paths on a traditional IP network
IP network: because of:
o Traffic can only be adjusted device by device. All routers that o Heavy configuration and error prone. Traffic can only be adjusted
the traffic traverses need to be configured. The configuration device by device. All routers that the traffic traverses need to
workload is heavy. The operation is not only time consuming but be configured. The configuration workload is heavy. The
also prone to misconfiguration for Service Providers. operation is not only time consuming but also prone to
misconfiguration for Service Providers.
o The routing policies used to control network routes are complex, o Complex. The routing policies used to control network routes are
posing difficulties to subsequent maintenance, high maintenance complex, posing difficulties to subsequent maintenance, high
skills are required. maintenance skills are required.
Hence, an automatic mechanism for setting up routing policies is It is desirable to have an automatic mechanism for setting up routing
desirable which can simplify the complexity of routing policies policies, which can simplify the routing policies configuration.
configuration. This document describes a mechanism to use BGP This document describes extensions to BGP for Routing Policy
Flowspec address family [RFC5575] as route-policy distribution Distribution.
protocol. This mechanism is called BGP FlowSpec Extensions for
Routing Policy Distribution (BGP-FS RPD).
2. Definitions and Acronyms 2. Definitions and Acronyms
BGP Flow Specification route: BGP Flow Specification routes are BGP Flow Specification route: BGP Flow Specification routes are
defined in RFC 5575. Each BGP Flow Specification route contains BGP defined in RFC 5575. Each BGP Flow Specification route contains BGP
Network Layer Reachability Information (NLRI) and Extended Community Network Layer Reachability Information (NLRI) and Extended Community
Attributes, which carry traffic filtering rules and actions to be Attributes, which carry traffic filtering rules and actions to be
taken on filtered traffic. taken on filtered traffic.
BGP Flow Specification peer relationship: A BGP Flow Specification BGP Flow Specification peer relationship: A BGP Flow Specification
skipping to change at page 4, line 13 skipping to change at page 4, line 13
o VPN: Virtual Private Network o VPN: Virtual Private Network
3. Problem Statements 3. Problem Statements
It is obvious that providers have the requirements to adjust their It is obvious that providers have the requirements to adjust their
business traffic from time to time because: business traffic from time to time because:
o Business development or network failure introduces link congestion o Business development or network failure introduces link congestion
and overload. and overload.
o Network transmission quality decreased as the result of delay, o Network transmission quality is decreased as the result of delay,
loss and need to adjust traffic to other paths. loss and they need to adjust traffic to other paths.
o To control OPEX and CPEX, prefer the transit provider with lower o To control OPEX and CPEX, prefer the transit provider with lower
price. price.
3.1. Inbound Traffic Control 3.1. Inbound Traffic Control
In the scenario below, for reasons above, the provider of AS100 In the scenario below, for the reasons above, the provider of AS100
saying P may wish the inbound traffic from AS200 enters AS100 through saying P may wish the inbound traffic from AS200 enters AS100 through
link L3 instead of others. Since P doesn't have administration over link L3 instead of the others. Since P doesn't have any
AS200, so there is no way for P to modify the route selection administration over AS200, so there is no way for P to modify the
criteria directly. route selection criteria directly.
Traffic from PE1 to Prefix1 Traffic from PE1 to Prefix1
-----------------------------------> ----------------------------------->
+-----------------+ +-------------------------+ +-----------------+ +-------------------------+
| +---------+ | L1 | +----+ +----------+| | +---------+ | L1 | +----+ +----------+|
| |Speaker1 | +------------+ |IGW1| |policy || | |Speaker1 | +------------+ |IGW1| |policy ||
| +---------+ |** L2**| +----+ |controller|| | +---------+ |** L2**| +----+ |controller||
| | ** ** | +----------+| | | ** ** | +----------+|
| +---+ | **** | | | +---+ | **** | |
skipping to change at page 4, line 50 skipping to change at page 5, line 28
| +---------+ | L4 | +----+ | | +---------+ | L4 | +----+ |
| | | | | | | |
| AS200 | | | | AS200 | | |
| | | ... | | | | ... |
| | | | | | | |
| +---------+ | | +----+ +-------+ | | +---------+ | | +----+ +-------+ |
| |Speakern | | | |IGWn| |Prefix1| | | |Speakern | | | |IGWn| |Prefix1| |
| +---------+ | | +----+ +-------+ | | +---------+ | | +----+ +-------+ |
+-----------------+ +-------------------------+ +-----------------+ +-------------------------+
Prefix1 advertise from AS100 to AS200 Prefix1 advertised from AS100 to AS200
<---------------------------------------- <----------------------------------------
Figure 1: Inbound Traffic Control case
Inbound Traffic Control case
3.2. Outbound Traffic Control 3.2. Outbound Traffic Control
In this scenario, the provider of AS100 saying P wishes to prefer In the scenario below, the provider of AS100 saying P prefers link L3
link L3 for the traffic to the destination Prefix2 among multiple for the traffic to the destination Prefix2 among multiple exits and
exits and links. This preference can be dynamic and change links. This preference can be dynamic and changed frequently because
frequently because of the reasons above. So the provider P expects of the reasons above. So the provider P expects an efficient and
an efficient and convenient solution. convenient solution.
Traffic from PE2 to Prefix2 Traffic from PE2 to Prefix2
-----------------------------------> ----------------------------------->
+-------------------------+ +-----------------+ +-------------------------+ +-----------------+
|+----------+ +----+ |L1 | +---------+ | |+----------+ +----+ |L1 | +---------+ |
||policy | |IGW1| +------------+ |Speaker1 | | ||policy | |IGW1| +------------+ |Speaker1 | |
||controller| +----+ |** **| +---------+ | ||controller| +----+ |** **| +---------+ |
|+----------+ |L2** ** | +-------+| |+----------+ |L2** ** | +-------+|
| | **** | |Prefix2|| | | **** | |Prefix2||
| | **** | +-------+| | | **** | +-------+|
skipping to change at page 5, line 35 skipping to change at page 6, line 27
| +----+ |L4 | +---------+ | | +----+ |L4 | +---------+ |
| | | | | | | |
|+---+ | | AS200 | |+---+ | | AS200 |
||PE2| ... | | | ||PE2| ... | | |
|+---+ | | | |+---+ | | |
| +----+ | | +---------+ | | +----+ | | +---------+ |
| |IGWn| | | |Speakern | | | |IGWn| | | |Speakern | |
| +----+ | | +---------+ | | +----+ | | +---------+ |
+-------------------------+ +-----------------+ +-------------------------+ +-----------------+
Prefix2 advertise from AS200 to AS100 Prefix2 advertised from AS200 to AS100
<---------------------------------------- <----------------------------------------
Figure 2: Outbound Traffic Control case
Outbound Traffic Control case
4. Proposed Solution 4. Proposed Solution
BGP FlowSpec [RFC5575] leverages the BGP control plane to simplify BGP FlowSpec [RFC5575] leverages the BGP control plane to simplify
the distribution of filter rules. New filter rules can be injected the distribution of filter rules. New filter rules can be injected
to all BGP peers simultaneously without changing router to all BGP peers simultaneously without changing router
configuration. Though the typical application of it is for DDOS configuration. Its typical application is for DDOS mitigation.
mitigation, it doesn't mean BGP Flowspec only takes effect on the
forwarding plane.
This document introduces a mechanism that uses BGP Flowspec as a This document introduces a mechanism that uses BGP Flowspec as a
route-policy distribution protocol. It can be the same powerful as routing policy distribution protocol. It can be as powerful as the
the device-based route-policy while still has the efficiency and device-based routing policy while still has the efficiency and
convenience of BGP Flowspec. convenience of BGP Flowspec.
This draft will use the term BGP-FS RPD as the abbreviation of This draft will use the term BGP-FS RPD (or BGP RPD for short) as the
FlowSpec Extensions for Routing Policy Distribution. abbreviation of BGP Extensions for Routing Policy Distribution.
5. Protocol Extensions 5. Protocol Extensions
5.1. Traffic Actions for Routing Policy Distribution
5.1. FlowSpec Traffic Actions for Routing Policy Distribution
The traffic-action extended community consists of 6 bytes of which The traffic-action extended community consists of 6 bytes of which
only the 2 least significant bits of the 6th byte (from left to only the 2 least significant bits of the 6th byte (from left to
right) are currently defined in [RFC5575]. Terminal Action (bit 47) right) are currently defined in [RFC5575]: Terminal Action (bit 47)
and Sample (bit 46) defines in [RFC5575], this document defines Route and Sample (bit 46). This document defines Routing Policy
Policy Distribution Flag(Bit 45). Distribution (RPD, or R for short) Flag (Bit 45). The 6th byte with
this newly defined flag is illustrated below:
The Flow Specification Traffic Actions for Routing Policy
Distribution:
40 41 42 43 44 45 46 47 40 41 42 43 44 45 46 47
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| reserved | R | S | T | | reserved | R | S | T |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Figure 3: FlowSpec Traffic-action
Route Policy Distribution Flag(Bit 45): When this bit is set, the Traffic-action with RPD (R) flag
corresponding filtering rules will be used as Route Policy.
RPD (R) Flag (Bit 45): When this bit is set, the corresponding
filtering rules will be used as Routing Policy.
5.2. Option 1: BGP Policy Attribute 5.2. Option 1: BGP Policy Attribute
This document defines and uses a new BGP attribute called the "BGP This document defines and uses a new BGP attribute called the "BGP
Policy attribute". This is an optional BGP attribute. The format of Policy attribute". This is an optional BGP attribute. The format of
this attribute is defined as follows: 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
| Match fields (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Attr Flag |Attr Type(TBD) | Attr Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Action fields (Variable) | ~ Match fields (Variable) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: BGP Policy Attribute | |
~ Action fields (Variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format of BGP Policy Attribute
Match fields: Match Fields define the matching criteria for the BGP Match fields: Match Fields define the matching criteria for the BGP
Policy Attribute. Policy Attribute.
Action fields: Action fields define the action being applied to the Action fields: Action fields define the action being applied to the
target route. target route.
5.2.1. Match Fields Format 5.2.1. Match Fields
Match Fields define the matching criteria for the BGP Policy Match Fields define the matching criteria for the BGP Policy
Attribute. Attribute. It has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3
| Match Type (2 octets) | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Sub-TLVs (2 octets) | | Match Type (2 octets) | Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | ~ Sub-TLVs (Variable) ~
| Sub-TLVs (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Match Fields Format
Figure 5: Match Fields Format
Match Type: Match Type:
0: Permit, specifies the permit mode of a match rule. If a route 1: Permit, specifies the permit mode of a match rule. If a route
matches the matching criteria of the BGP Policy Attribute, the matches the matching criteria of the BGP Policy Attribute, the
actions defined by the Action fields of the BGP Policy Attribute are actions defined by the Action fields of the BGP Policy Attribute are
performed. If a route does not match the matching criteria for the performed. If a route does not match the matching criteria for the
BGP Policy Attribute, then nothing needs to do with this route. BGP Policy Attribute, then nothing needs to be done with this route.
1: Deny, specifies the deny mode of a match rule. In the deny mode, 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 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, the actions defined by the Action fields of the BGP Policy
Attribute are performed. If a route matches the matching criteria of Attribute are performed. If a route matches the matching criteria of
the BGP Policy Attribute, then nothing needs to do with this route. the BGP Policy Attribute, then nothing needs to be done with this
route.
Number of Sub-TLVs: The number of Sub-TLVs contain in Match fields. Length: The total length of the Sub-TLVs in the Match fields.
The contents of Match fields are encoded as Sub-TLVs, where each TLV The contents of Match fields are encoded as Sub-TLVs, where each Sub-
has the following format: TLV has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3
| Type (2 octets) | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (2 octets) | | Type (2 octets) | Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | ~ Values (Variable) ~
| Values (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-TLV Format
Figure 6: Sub-TLVs Format
Type: The Type field contains a value of 1-65534. The values 0 and Type: The Type field contains a value of 1-65534. The values 0 and
65535 are reserved for future use. 65535 are reserved for future use.
Length: The Length field represents the total length of a given TLV's Length: The Length field represents the total length of a given TLV's
value field in octets. value field in octets.
Values: The Value field contains the TLV value. Values: The Value field contains the TLV value.
Supported format of the TLVs can be: The following TLVs are defined:
Type 1: IPv4 Neighbor 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:
Type 2: IPv6 Neighbor 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 3: ASN List 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:
To be added in later versions. 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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.2. Action Fields Format 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
5.2.2. Action Fields
Action fields define the action being applied to the targeted route. Action fields define the action being applied to the targeted route.
It has the following format.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3
| Action Type (2 octets) | 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 Length (2 octets) | | Action Type (2 octets) | Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | ~ Action Values (Variable) ~
| Action Values (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Action Fields Format
Figure 7: Action Fields Format
Action Type: The Action Type field contains a value of 1-65534. The Action Type: The Action Type field contains a value of 1-65534. The
values 0 and 65535 are reserved for future use. values 0 and 65535 are reserved for future use.
Action Length: The Action Length field represents the total length of Action Length: The Action Length field represents the total length of
the Action Values in octets. the Action Values in octets.
Action Values: The Action Values field contain parameters of the Action Values: The Action Values field contain parameters of the
action. action.
Supported format of the TLVs can be: Supported format of the TLVs can be:
Type 1: Route-Preference 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:
Type 2: Route-Prepend-AS 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
To be added in later versions. 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.
5.2.3. Operation Examples Type TBD8: Change Med, which indicates to change the Med according to
OP. Its TLV (or Sub-TLV) format is illustrated below:
5.2.3.1. Inbound Traffic Control 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
5.2.3. Application Examples
5.2.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
5.2.3.2. Inbound Traffic Control
The traffic destined for Prefix1 needs to be scheduled to link The traffic destined for Prefix1 needs to be scheduled to link
Speaker1 -> IGW2 for transmission. Speaker1 -> IGW2 for transmission.
The Policy Controller constructs a BGP-FS RPD route and pushes it to The Policy Controller constructs a BGP-FS RPD route and pushes it to
all the IGW routers, the route carries: all the IGW routers, the route carries:
1. Prefix1 in the Destination Prefix component of the BGP-FS NLRI; 1. Prefix1 in the Destination Prefix component of the BGP-FS NLRI;
2. Flow Specification Traffic Action Extended Community with the 2. Flow Specification Traffic Action Extended Community with the
Route Policy Distribution Flag(Bit 45) set. When this bit is Routing Policy Distribution (R) Flag (Bit 45) set. When this bit
set, the corresponding filtering rules will be used as Routing is set, the corresponding filtering rules will be used as Routing
Policies. Policies.
3. NO_ADVERTISE Community [RFC1997] 3. NO_ADVERTISE Community [RFC1997]
4. BGP Policy Attribute: 4. BGP Policy Attribute:
* Match Type: 2, Deny * Match Type: 2, Deny
* IPv4 Neighbor Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer * IPv4 Session Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer
Speaker1 Speaker1
* Action Type: Route-Prepend-AS * Action Type: Route-Prepend-AS
* Action Value: Prepend-AS times is 5 * Action Value: Prepend-AS times is 5
IGW1 processes the received BGP-FS RPD route as follows: IGW1 processes the received BGP-FS RPD route as follows:
1. IGW1 gets the target prefix Prefix1 from the Destination Prefix 1. IGW1 gets the target prefix Prefix1 from the Destination Prefix
component in the BGP FS NLRI of the BGP FS RPD route; component in the BGP FS NLRI of the BGP FS RPD route;
2. IGW1 identifies the Route Policy Distribution Flag carrying in 2. IGW1 identifies the Routing Policy Distribution (R) Flag carrying
the Flow Specification Traffic Action Extended Community, then in the Flow Specification Traffic Action Extended Community, then
IGW1 knows that the corresponding filtering rules will be used as IGW1 knows that the corresponding filtering rules will be used as
Routing Policies. Routing Policies.
3. IGW1 uses the target prefix Prefix1 to choose the matching 3. IGW1 uses the target prefix Prefix1 to choose the matching
routes, in this case, IGW1 will choose the current best route of routes, in this case, IGW1 will choose the current best route of
Prefix1; Prefix1;
4. IGW1 gets the matching criteria from the BGP Policy Attribute: 4. IGW1 gets the matching criteria from the BGP Policy Attribute:
Local BGP Speaker IGW2, Remote BGP Speaker1; Local BGP Speaker IGW2, Remote BGP Speaker1;
skipping to change at page 10, line 19 skipping to change at page 18, line 5
matching criteria: Local BGP Speaker IGW2, Remote BGP Speaker1, at matching criteria: Local BGP Speaker IGW2, Remote BGP Speaker1, at
the same time the Match Type is "Deny" mode, so IGW1 sends the best 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 route of Prefix1 to Speaker1 and Speaker2 with performing the Action
instructions from the BGP-FS RPD route: Prepend Local AS 5 times. instructions from the BGP-FS RPD route: Prepend Local AS 5 times.
IGW2 processes the received BGP FS RPD route as follows: IGW2 processes the received BGP FS RPD route as follows:
1. IGW2 gets the target prefix Prefix1 from the Destination Prefix 1. IGW2 gets the target prefix Prefix1 from the Destination Prefix
component in the BGP-FS NLRI of the BGP FS RPD route; component in the BGP-FS NLRI of the BGP FS RPD route;
2. IGW2 identifies the Route Policy Distribution Flag carrying in 2. IGW2 identifies the Routing Policy Distribution (R) Flag carrying
the Flow Specification Traffic Action Extended Community, then in the Flow Specification Traffic Action Extended Community, then
IGW2 knows that the corresponding filtering rules will be used as IGW2 knows that the corresponding filtering rules will be used as
Routing Policies. Routing Policies.
3. IGW2 uses the target prefix Prefix1 to choose the matching 3. IGW2 uses the target prefix Prefix1 to choose the matching
routes, in this case, IGW2 will choose the current best route of routes, in this case, IGW2 will choose the current best route of
Prefix1; Prefix1;
4. IGW2 gets the matching criteria from the BGP Policy Attribute: 4. IGW2 gets the matching criteria from the BGP Policy Attribute:
Local BGP Speaker IGW2, Remote BGP Speaker1; Local BGP Speaker IGW2, Remote BGP Speaker1;
skipping to change at page 10, line 46 skipping to change at page 18, line 32
Peer Speaker1, but the Match Type is "Deny" mode, so IGW2 sends the Peer Speaker1, but the Match Type is "Deny" mode, so IGW2 sends the
best route of Prefix1 to Speaker1, without performing the Action best route of Prefix1 to Speaker1, without performing the Action
instructions from the BGP-FS RPD route. At the same time, IGW2 sends instructions from the BGP-FS RPD route. At the same time, IGW2 sends
the best route of Prefix1 to Speaker2 with performing the Action the best route of Prefix1 to Speaker2 with performing the Action
instructions from the BGP-FS RPD route: Prepend Local AS 5 times. instructions from the BGP-FS RPD route: Prepend Local AS 5 times.
In the similar manner, other IGWs will perform the same Action In the similar manner, other IGWs will perform the same Action
instructions as IGW1. Then the traffic destined for Prefix1 has been instructions as IGW1. Then the traffic destined for Prefix1 has been
be scheduled to link L3 for transmission. be scheduled to link L3 for transmission.
5.2.3.2. Outbound Traffic Control 5.2.3.3. Outbound Traffic Control
In this scenario, if the bandwidth usage of a link exceeds the In this scenario, if the bandwidth usage of a link exceeds the
specified threshold, the Policy Controller automatically identifies specified threshold, the Policy Controller automatically identifies
which traffic needs to be scheduled and the Policy Controller which traffic needs to be scheduled and the Policy Controller
automatically calculates traffic control paths based on network automatically calculates traffic control paths based on network
topology and traffic information. topology and traffic information.
For example, the outbound traffic destined for Prefix2 needs to be For example, the outbound traffic destined for Prefix2 needs to be
scheduled to link IGW2 -> Speaker1 for transmission. scheduled to link IGW2 -> Speaker1 for transmission.
The Policy Controller sends a BGP-FS RPD route to IGW2, the route The Policy Controller sends a BGP-FS RPD route to IGW2, the route
carries: carries:
1. Prefix2 in the Destination Prefix component of the BGP-FS NLRI; 1. Prefix2 in the Destination Prefix component of the BGP-FS NLRI;
2. Flow Specification Traffic Action Extended Community with the 2. Flow Specification Traffic Action Extended Community with the
Route Policy Distribution Flag(Bit 45) set. When this bit is Routing Policy Distribution (R) Flag (Bit 45) set. When this bit
set, the corresponding filtering rules will be used as Routing is set, the corresponding filtering rules will be used as Routing
Policies. Policies.
3. NO_ADVERTISE Community [RFC1997] 3. NO_ADVERTISE Community [RFC1997]
4. BGP Policy Attribute: 4. BGP Policy Attribute:
* Match Type: 1, Permit * Match Type: 1, Permit
* IPv4 Neighbor Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer * IPv4 Session Sub-TLV: Local BGP Speaker IGW2, Remote BGP Peer
Speaker1 Speaker1
* Action Type: Route-Preference * Action Type: Route-Preference
* Action Value: none * Action Value: none
IGW2 processes the received BGP FS RPD route as follows: IGW2 processes the received BGP FS RPD route as follows:
1. IGW2 gets the target prefix Prefix2 from the Destination Prefix 1. IGW2 gets the target prefix Prefix2 from the Destination Prefix
component in the BGP-FS NLRI of the BGP FS RPD route; component in the BGP-FS NLRI of the BGP FS RPD route;
2. IGW2 identifies the Route Policy Distribution Flag carrying in 2. IGW2 identifies the Routing Policy Distribution (R) Flag carrying
the Flow Specification Traffic Action Extended Community, then in the Flow Specification Traffic Action Extended Community, then
IGW2 knows that the corresponding filtering rules will be used as IGW2 knows that the corresponding filtering rules will be used as
Routing Policies. Routing Policies.
3. IGW2 uses the target prefix Prefix2 to choose the matching 3. IGW2 uses the target prefix Prefix2 to choose the matching
routes, in this case, the prefix Prefix2 has two more routes: routes, in this case, the prefix Prefix2 has two more routes:
Prefix Next-Hop Local BGP Speaker Remote BGP Peer Prefix Next-Hop Local BGP Speaker Remote BGP Peer
Prefix2 Speaker1 IGW2 Speaker1 Prefix2 Speaker1 IGW2 Speaker1
Prefix2 Speaker2 IGW2 Speaker2 Prefix2 Speaker2 IGW2 Speaker2
... ...
skipping to change at page 12, line 14 skipping to change at page 19, line 48
5. IGW2 gets the action from the BGP Policy Attribute: Route- 5. IGW2 gets the action from the BGP Policy Attribute: Route-
Preference; Preference;
So IGW2 chooses the BGP route received from Speaker1 instead of So IGW2 chooses the BGP route received from Speaker1 instead of
Speaker2 as the best route and the outbound traffic destined for Speaker2 as the best route and the outbound traffic destined for
Prefix2 can be scheduled to link L3 for transmission. Prefix2 can be scheduled to link L3 for transmission.
5.3. Option 2: BGP Wide Community 5.3. Option 2: BGP Wide Community
This section describes the option 2 for protocol extensions, which is The BGP wide community is defined in
completely different from section 5.2 by reusing BGP Wide Community [I-D.ietf-idr-wide-bgp-communities]. It can be used to facilitate
introduced in [I-D.ietf-idr-wide-bgp-communities]. the delivery of new network services, and be extended easily for
distributing different kinds of routing policies.
BGP Wide Community Attribute is a very useful tool that it can be This section describes an alternative extension to BGP protocol,
used to convey different kinds of routing policies. which extends the BGP wide community for distributing routing
policies. A few of new wide community atoms and new actions are
defined below.
5.3.1. New Wide Community Atoms 5.3.1. New Wide Community Atoms
Wide Community Atoms define in [I-D.ietf-idr-wide-bgp-communities] , A wide community Atom is a TLV (or sub-TLV), which may be included in
in that draft it defines Type 1 to Type 8. a BGP wide community container (or BGP wide community for short).
The format of the TLV (or sub-TLV) and 8 wide community Atoms are
New wide community atoms have to be introduced since the entrance and defined in [I-D.ietf-idr-wide-bgp-communities]. 3 new wide community
exit of traffic need to be designated precisely. Atoms will be defined in this document. For your reference, the
format of the TLV is illustrated below:
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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type | | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable) | | Value (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Wide Community Atoms
Supported format of the TLVs can be: Format of Wide Community Atom TLV
o Type 1: Autonomous System number list Some of the existing 8 wide community Atoms (from Type 1 to 8) and 9
new wide community Atoms (from TBD1 to TBD9) are listed as follows:
o Type 2: IPv4 prefix (1 octet prefix length + prefix) list +------+---------------------------------------------------------+
| Type | Description |
+------+---------------------------------------------------------+
| 1 | Autonomous System Number List |
| 2 | IPv4 Prefix (1 octet prefix length + prefix) List |
| . | . |
| : | : |
| 8 | UTF-8 String |
| TBD1 | BGP IPv4 Session (local address and remote address) |
| TBD2 | BGP IPv6 Session (local address and remote address) |
| TBD3 | IPv4 Prefix Range |
| TBD4 | IPv6 Prefix Range |
| TBD5 | AS Path |
| TBD6 | Communities |
| TBD7 | Add AS-Path |
| TBD8 | Change MED |
| TBD9 | Deny |
+------+---------------------------------------------------------+
o Type 3: IPv6 prefix (1 octet prefix length + prefix) list Existing and New Wide Community Atoms
o Type 4: Integer list The wide community Atom BGP IPv4 Session contains the IPv4 local
address and remote address of a BGP session. Its format is
illustrated below:
o Type 5: IEEE Floating Point Number list 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type 6: Neighbor Class list Format of Atom BGP IPv4 Session
o Type 7: User-defined Class list7
o Type 8: UTF-8 String The wide community Atom BGP IPv6 Session contains the IPv6 local
address and remote address of a BGP session. Its format is
illustrated below:
o Type TBD: BGP IPv4 neighbor --- Newly introduced in this draft, 0 1 2 3
which contains the BGP session IPv4 local address and the BGP 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
session IPv4 peer address. +-+-+-+-+-+-+-+-+
| Type (TBD2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Local IPv6 Address (16 bytes) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Remote IPv6 Address (16 bytes) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type TBD: BGP IPv6 neighbor --- Newly introduced in this draft, Format of Atom BGP IPv6 Session
which contains the BGP session IPv6 local address and the BGP
session IPv6 peer address.
5.3.2. Operation examples The wide community Atom IPv4 Prefix Range represents a range of IPv4
prefixes. Its format is illustrated below:
5.3.2.1. Inbound Traffic Control 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 Atom IPv4 Prefix Range
It 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. Note that MaskLen must be less than or equal to
LeMaskLen except for LeMaskLen = 0, in this case, triple
<IPv4-Address, MaskLen, 0> represents prefix IPv4-Address/MaskLen.
The encoding of Atom IPv4 Prefix Range may be optimized as the format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaskLen | LeMaskLen | IPv4 Prefix ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaskLen | LeMaskLen | IPv4 Prefix ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Compact Format of Atom IPv4 Prefix Range
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, the wide community Atom 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 Atom IPv6 Prefix Range
The encoding of Atom IPv6 Prefix Range may be optimized as the format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaskLen | LeMaskLen | IPv6 Prefix ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaskLen | LeMaskLen | IPv6 Prefix ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Compact Format of Atom IPv6 Prefix Range
The wide community Atom AS Path 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 Atom AS Path
For example, AS Path "123456, 6553603, 6553603, 6553603" is
represented by AS1 = 123456, Count1 = 1, AS2 = 6553603, and Count2 =
3.
The wide community Atom Communities 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 Atom Communities
The wide community Atom Add AS Path indicates to add the sequence of
AS numbers represented in the Atom to AS Path. 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 (TBD7) | Length (Variable) | OP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count1 |
+-+-+-+-+-+-+-+-+
~ . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Countn |
+-+-+-+-+-+-+-+-+
Format of Atom Add AS Path
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.
The wide community Atom Change Med indicates to change the Med
according to OP. 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 (TBD8) | Length (5) | OP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format of Atom Change Med
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.
The wide community Atom Deny indicates Deny action. 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 (TBD9) | Length (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format of Atom Deny
5.3.2. New Wide Community Actions
A Registered Wide BGP Community Value may indicate an action. For
example, value 17 indicates "PREPEND N TIMES BY AS" as defined in
draft [I-D.ietf-idr-registered-wide-bgp-communities]. 2 new values
for actions are defined in this document. Some of the existing
values (from 1 to 24) and the two new values are listed below:
+-------+-------------------------------------------------------+
| Value | Description |
+-------+-------------------------------------------------------+
| 1 | BLACKHOLE |
| 2 | SOURCE FILTER |
| . | . |
| : | : |
| 24 | FREE POOL |
| TBD11 | change attributes |
| TBD12 | no advertise |
+-------+-------------------------------------------------------+
Existing and New Wide Communities Values
When action "change attributes" is used, multiple attributes can be
changed. The parameters and operations for the action are
represented by the Atoms related to the operations. These Atoms are
included in a BGP Wide Community Parameter(s) TLV. The Atoms may be
"Add AS-Path" and "Change MED".
5.3.3. Application Examples
5.3.3.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
5.3.3.2. Inbound Traffic Control
As required in the case, traffic from PE1 to Prefix1 need to enter 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 through L3, so IGWs except IGW2 should prepend ASN list to Prefix1
when populating to AS100. As shown in figure below, community when populating to AS100. As shown in figure below, community
"PREPEND N TIMES BY AS" and "Exclude Target(s) TLV" are be used. "PREPEND N TIMES BY AS" and "Exclude Target(s) TLV" are be used.
The encoding example using BGP Wide Community: The encoding example using BGP Wide Community:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Container Type 1 (1) | | Container Type: 1 |Flags |0|1| Reserved(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+
| Hop Count: 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length: 36 | | Length: 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Community: PREPEND N TIMES BY AS 17 | | Community: PREPEND N TIMES BY AS 17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Own ASN 100 | | Source AS 100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context ASN# 100 | | Context AS 100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ExcTargetTLV(2)| Length: 11 | |ExcTargetTLV: 2| Length: 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4Neig(TBD)| Length: 8 | |IPv4Sess: TBD1 | Length: 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Speaker #IGW2 | | Local Address/Speaker #IGW2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Speaker #Speaker1 | | Remote Address/Speaker #Speaker1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Param TLV (3) | Length: 7 | | Param TLV: 3 | Length: 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer (4) | Length: 4 | | Integer: 4 | Length: 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prepend # 5 | | Prepend # 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Example encoding for Inbound Traffic Control case
Example encoding for Inbound Traffic Control case
"PREPEND N TIMES BY AS" Wide Community has been defined in "PREPEND N TIMES BY AS" Wide Community has been defined in
[I-D.ietf-idr-registered-wide-bgp-communities]. [I-D.ietf-idr-registered-wide-bgp-communities].
The traffic destined for Prefix1 needs to be scheduled to link The traffic destined for Prefix1 needs to be scheduled to link
Speaker1 -> IGW2 for transmission. Speaker1 -> IGW2 for transmission.
The Policy Controller constructs a BGP-FS RPD route and pushes it to The Policy Controller constructs a BGP RPD route and pushes it to all
all the IGW routers, the route carries: the IGW routers, the route carries:
1. Prefix1 in the Destination Prefix component of the BGP-FS NLRI; 1. Prefix1 in the Destination Prefix component of the BGP-FS NLRI;
2. Flow Specification Traffic Action Extended Community with the 2. Flow Specification Traffic Action Extended Community with the
Route Policy Distribution Flag(Bit 45) set. When this bit is Routing Policy Distribution (R) Flag (Bit 45) set. When this bit
set, the corresponding filtering rules will be used as Routing is set, the corresponding filtering rules will be used as Routing
Policies. Policies.
3. NO_ADVERTISE Community [RFC1997] 3. NO_ADVERTISE Community [RFC1997]
4. Wide BGP Community Attribute: 4. Wide BGP Community Attribute:
PREPEND N TIMES BY AS: PREPEND N TIMES BY AS:
Type: 0x0001 S = src AS # Type: 0x0001 S = src AS #
F = 0x80 C = 0x00000000 F = 0x80 C = 0x00000000
H = 0 T = none H = 0 T = none
L = 36 octets E = Type_TBD (BGP IPv4 neighbor) L = 36 octets E = Type_TBD (BGP IPv4 session)
R = 17 P = Type_4 (0x05) R = 17 P = Type_4 (0x05)
Where "BGP IPv4 neighbor" Atom TLV contains: Where "BGP IPv4 session" Atom TLV contains:
The BGP session IPv4 local address: Local BGP Speaker IGW2 The BGP session IPv4 local address: Local BGP Speaker IGW2
The BGP session IPv4 peer address: Remote BGP Peer Speaker1 The BGP session IPv4 peer address: Remote BGP Peer Speaker1
IGW1 processes the received BGP-FS RPD route as follows: IGW1 processes the received BGP-FS RPD route as follows:
1. IGW1 gets the target prefix Prefix1 from the Destination Prefix 1. IGW1 gets the target prefix Prefix1 from the Destination Prefix
component in the BGP FS NLRI of the BGP FS RPD route; component in the BGP FS NLRI of the BGP FS RPD route;
2. IGW1 identifies the Route Policy Distribution Flag carrying in 2. IGW1 identifies the Routing Policy Distribution (R) Flag carrying
the Flow Specification Traffic Action Extended Community, then in the Flow Specification Traffic Action Extended Community, then
IGW1 knows that the corresponding filtering rules will be used as IGW1 knows that the corresponding filtering rules will be used as
Routing Policies. Routing Policies.
3. IGW1 uses the target prefix Prefix1 to choose the matching 3. IGW1 uses the target prefix Prefix1 to choose the matching
routes, in this case, IGW1 will choose the current best route of routes, in this case, IGW1 will choose the current best route of
Prefix1; Prefix1;
4. IGW1 gets the action type from the Wide BGP Community Attribute: 4. IGW1 gets the action type from the Wide BGP Community Attribute:
PREPEND N TIMES BY AS; PREPEND N TIMES BY AS;
5. IGW1 gets the matching criteria from the Wide BGP Community 5. IGW1 gets the matching criteria from the Wide BGP Community
Attribute: Exclude the BGP IPv4 neighbor: <Local BGP Speaker Attribute: Exclude the BGP IPv4 session: <Local BGP Speaker IGW2,
IGW2, Remote BGP Speaker1>; Remote BGP Speaker1>;
6. IGW1 gets the parameter for "PREPEND N TIMES BY AS" from the Wide 6. IGW1 gets the parameter for "PREPEND N TIMES BY AS" from the Wide
BGP Community Attribute: 5 times; BGP Community Attribute: 5 times;
IGW1 checks the matching criteria and finds that it doesn't hits the IGW1 checks the matching criteria and finds that it doesn't hits the
exclude matching criteria: Local BGP Speaker IGW2, Remote BGP exclude matching criteria: Local BGP Speaker IGW2, Remote BGP
Speaker1, so IGW1 sends the best route of Prefix1 to Speaker1 and Speaker1, so IGW1 sends the best route of Prefix1 to Speaker1 and
Speaker2 with performing the Action instructions from the BGP-FS RPD Speaker2 with performing the Action instructions from the BGP-FS RPD
route: Prepend Local AS 5 times. route: Prepend Local AS 5 times.
IGW2 processes the received BGP FS RPD route as follows: IGW2 processes the received BGP FS RPD route as follows:
1. IGW2 gets the target prefix Prefix1 from the Destination Prefix 1. IGW2 gets the target prefix Prefix1 from the Destination Prefix
component in the BGP-FS NLRI of the BGP FS RPD route; component in the BGP-FS NLRI of the BGP FS RPD route;
2. IGW2 identifies the Route Policy Distribution Flag carrying in 2. IGW2 identifies the Routing Policy Distribution (R) Flag carrying
the Flow Specification Traffic Action Extended Community, then in the Flow Specification Traffic Action Extended Community, then
IGW2 knows that the corresponding filtering rules will be used as IGW2 knows that the corresponding filtering rules will be used as
Routing Policies. Routing Policies.
3. IGW2 uses the target prefix Prefix1 to choose the matching 3. IGW2 uses the target prefix Prefix1 to choose the matching
routes, in this case, IGW2 will choose the current best route of routes, in this case, IGW2 will choose the current best route of
Prefix1; Prefix1;
4. IGW2 gets the action type from the Wide BGP Community Attribute: 4. IGW2 gets the action type from the Wide BGP Community Attribute:
PREPEND N TIMES BY AS; PREPEND N TIMES BY AS;
5. IGW2 gets the matching criteria from the BGP Policy Attribute: 5. IGW2 gets the matching criteria from the BGP Policy Attribute:
Exclude the BGP IPv4 neighbor: <Local BGP Speaker IGW2, Remote Exclude the BGP IPv4 session: <Local BGP Speaker IGW2, Remote BGP
BGP Speaker1>; Speaker1>;
6. IGW2 gets the parameter for "PREPEND N TIMES BY AS" from the Wide 6. IGW2 gets the parameter for "PREPEND N TIMES BY AS" from the Wide
BGP Community Attribute: 5 times; BGP Community Attribute: 5 times;
IGW2 checks the matching criteria and finds that there is a speaker IGW2 checks the matching criteria and finds that there is a speaker
which hits the exclude matching criteria: Local BGP Speaker IGW2, which hits the exclude matching criteria: Local BGP Speaker IGW2,
Remote BGP Peer Speaker1, so IGW2 sends the best route of Prefix1 to Remote BGP Peer Speaker1, so IGW2 sends the best route of Prefix1 to
Speaker1 without performing the Action instructions from the BGP-FS Speaker1 without performing the Action instructions from the BGP-FS
RPD route, at the same time, IGW2 sends the best route of Prefix1 to 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 Speaker2 with performing the Action instructions from the BGP-FS RPD
route: Prepend Local AS 5 times. route: Prepend Local AS 5 times.
In the similar manner, other IGWs will perform the same Action In the similar manner, other IGWs will perform the same Action
instructions as IGW1. Then the traffic destined for Prefix1 has been instructions as IGW1. Then the traffic destined for Prefix1 has been
be scheduled to link L3 for transmission. be scheduled to link L3 for transmission.
5.3.2.2. Outbound Traffic Control 5.3.3.3. Outbound Traffic Control
As required in the case, traffic from PE2 to Prefix2 need to exit 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. through L3, so IGWs should prefer the route from IGW2 to Speaker1.
As shown in figure below, community "LOCAL PREFERENCE" and "Target(s) As shown in figure below, community "LOCAL PREFERENCE" and "Target(s)
TLV" are be used. TLV" are be used.
The encoding example using BGP Wide Community: The encoding example using BGP Wide Community:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Container Type 1 (1) | | Container Type: 1 |Flags |0|1| Reserved(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+
| Hop Count: 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length: 36 | | Length: 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Community: LOCAL PREFERENCE 20 | | Community: LOCAL PREFERENCE 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Own ASN 100 | | Source AS 100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context ASN# 100 | | Context AS 100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TargetTLV(1) | Length: 11 | | TargetTLV: 1 | Length: 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4Neig(TBD)| Length: 8 | | IPv4Sess:TBD1| Length: 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Speaker #IGW2 | | Local Address/Speaker #IGW2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Speaker #Speaker1 | | Remote Address/Speaker #Speaker1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Param TLV (3) | Length: 7 | | Param TLV: 3 | Length: 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer (4) | Length: 4 | | Integer: 4 | Length: 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Increment # 100 | | Increment # 100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Example encoding for Outbound Traffic Control case
Example encoding for Outbound Traffic Control case
"LOCAL PREFERENCE" Wide Community has been defined in "LOCAL PREFERENCE" Wide Community has been defined in
[I-D.ietf-idr-registered-wide-bgp-communities] [I-D.ietf-idr-registered-wide-bgp-communities].
In this scenario, if the bandwidth usage of a link exceeds the In this scenario, if the bandwidth usage of a link exceeds the
specified threshold, the Policy Controller automatically identifies specified threshold, the Policy Controller automatically identifies
which traffic needs to be scheduled and the Policy Controller which traffic needs to be scheduled and the Policy Controller
automatically calculates traffic control paths based on network automatically calculates traffic control paths based on network
topology and traffic information. topology and traffic information.
For example, the outbound traffic destined for Prefix2 needs to be For example, the outbound traffic destined for Prefix2 needs to be
scheduled to link IGW2 -> Speaker1 for transmission. scheduled to link IGW2 -> Speaker1 for transmission.
The Policy Controller sends a BGP-FS RPD route to IGW2, the route The Policy Controller sends a BGP-FS RPD route to IGW2, the route
carries: carries:
1. Prefix2 in the Destination Prefix component of the BGP-FS NLRI; 1. Prefix2 in the Destination Prefix component of the BGP-FS NLRI;
2. Flow Specification Traffic Action Extended Community with the RPD
2. Flow Specification Traffic Action Extended Community with the (R) Flag (Bit 45) set. When this bit is set, the corresponding
Route Policy Distribution Flag(Bit 45) set. When this bit is filtering rules will be used as Routing Policies.
set, the corresponding filtering rules will be used as Routing
Policies.
3. NO_ADVERTISE Community [RFC1997] 3. NO_ADVERTISE Community [RFC1997]
4. Wide BGP Community Attribute: 4. Wide BGP Community Attribute:
LOCAL PREFERENCE: LOCAL PREFERENCE:
Type: 0x0001 S = src AS # Type: 0x0001 S = src AS #
F = 0x80 C = 0x00000000 F = 0x80 C = 0x00000000
H = 0 T = Type_TBD (BGP IPv4 neighbor) H = 0 T = Type_TBD (BGP IPv4 session)
L = 36 octets E = none L = 36 octets E = none
R = 20 P = Type_4 (0x64) R = 20 P = Type_4 (0x64)
Where "BGP IPv4 neighbor" Atom TLV contains: Where "BGP IPv4 session" Atom TLV contains:
The BGP session IPv4 local address: Local BGP Speaker IGW2 The BGP session IPv4 local address: Local BGP Speaker IGW2
The BGP session IPv4 peer address: Remote BGP Peer Speaker1 The BGP session IPv4 peer address: Remote BGP Peer Speaker1
IGW2 processes the received BGP FS RPD route as follows: IGW2 processes the received BGP FS RPD route as follows:
1. IGW2 gets the target prefix Prefix2 from the Destination Prefix 1. IGW2 gets the target prefix Prefix2 from the Destination Prefix
component in the BGP-FS NLRI of the BGP FS RPD route; component in the BGP-FS NLRI of the BGP FS RPD route;
2. IGW2 identifies the Route Policy Distribution Flag carrying in 2. IGW2 identifies the Routing Policy Distribution (R) Flag carrying
the Flow Specification Traffic Action Extended Community, then in the Flow Specification Traffic Action Extended Community, then
IGW2 knows that the corresponding filtering rules will be used as IGW2 knows that the corresponding filtering rules will be used as
Routing Policies. Routing Policies.
3. IGW2 uses the target prefix Prefix2 to choose the matching 3. IGW2 uses the target prefix Prefix2 to choose the matching
routes, in this case, the prefix Prefix2 has two more routes: routes, in this case, the prefix Prefix2 has two more routes:
Prefix Next-Hop Local BGP Speaker Remote BGP Peer Prefix Next-Hop Local BGP Speaker Remote BGP Peer
-------------------------------------------------------- --------------------------------------------------------
Prefix2 Speaker1 IGW2 Speaker1 Prefix2 Speaker1 IGW2 Speaker1
Prefix2 Speaker2 IGW2 Speaker2 Prefix2 Speaker2 IGW2 Speaker2
skipping to change at page 19, line 14 skipping to change at page 34, line 11
6. IGW2 gets the parameter for "LOCAL PREFERENCE" from the Wide BGP 6. IGW2 gets the parameter for "LOCAL PREFERENCE" from the Wide BGP
Community Attribute: increment 100; Community Attribute: increment 100;
So IGW2 chooses the BGP route received from Speaker1 instead of So IGW2 chooses the BGP route received from Speaker1 instead of
Speaker2 as the best route and the outbound traffic destined for Speaker2 as the best route and the outbound traffic destined for
Prefix2 can be scheduled to link L3 for transmission. Prefix2 can be scheduled to link L3 for transmission.
5.4. Capability Negotiation 5.4. Capability Negotiation
It is necessary to negotiate the capability to support BGP FlowSpec It is necessary to negotiate the capability to support BGP Extensions
Extensions for Route Policy Distribution (RPD). The BGP FS RPD for Routing Policy Distribution (RPD). The BGP RPD Capability is a
Capability is a new BGP capability [RFC5492]. The Capability Code new BGP capability [RFC5492]. The Capability Code for this
for this capability is to be specified by the IANA. The Capability capability is to be specified by the IANA. The Capability Length
Length field of this capability is variable. The Capability Value field of this capability is variable. The Capability Value field
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) |
+--------------------------------------------------+ +--------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) | | Subsequent Address Family Identifier (1 octet) |
+--------------------------------------------------+ +--------------------------------------------------+
| Send/Receive (1 octet) | | Send/Receive (1 octet) |
+--------------------------------------------------+ +--------------------------------------------------+
Figure 11: BGP FS RPD Capability
BGP RPD Capability
The meaning and use of the fields are as follows: The meaning and use of the fields are as follows:
Address Family Identifier (AFI): This field is the same as the one Address Family Identifier (AFI): This field is the same as the one
used in [RFC4760]. used in [RFC4760].
Subsequent Address Family Identifier (SAFI): This field is the same Subsequent Address Family Identifier (SAFI): This field is the same
as the one used in [RFC4760]. as the one used in [RFC4760].
Send/Receive: This field indicates whether the sender is (a) willing Send/Receive: This field indicates whether the sender is (a) willing
to receive Route Policies via BGP FLowSpec from its peer (value 1), to receive Routing Policies from its peer (value 1), (b) would like
(b) would like to send Route Policies via BGP FLowSpec to its peer to send Routing Policies to its peer (value 2), or (c) both (value 3)
(value 2), or (c) both (value 3) for the <AFI, SAFI>. for the <AFI, SAFI>.
6. Consideration 6. Consideration
6.1. Route-Policy 6.1. Route-Policy
Routing policies are used to filter routes and control how routes are Routing policies are used to filter routes and control how routes are
received and advertised. If route attributes, such as reachability, received and advertised. If route attributes, such as reachability,
are changed, the path along which network traffic passes changes are changed, the path along which network traffic passes changes
accordingly. accordingly.
skipping to change at page 21, line 24 skipping to change at page 36, line 20
The authors would like to thank Acee Lindem, Jeff Haas, Jie Dong, The authors would like to thank Acee Lindem, Jeff Haas, Jie Dong,
Haibo Wang, Lucy Yong, Qiandeng Liang, Zhenqiang Li for their Haibo Wang, Lucy Yong, Qiandeng Liang, Zhenqiang Li for their
comments to this work. comments to this work.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-idr-wide-bgp-communities] [I-D.ietf-idr-wide-bgp-communities]
Raszuk, R., Haas, J., Lange, A., Amante, S., Decraene, B., Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S.,
Jakma, P., and R. Steenbergen, "Wide BGP Communities and P. Jakma, "BGP Community Container Attribute", draft-
Attribute", draft-ietf-idr-wide-bgp-communities-02 (work ietf-idr-wide-bgp-communities-05 (work in progress), July
in progress), May 2016. 2018.
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<http://www.rfc-editor.org/info/rfc1997>. <https://www.rfc-editor.org/info/rfc1997>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007, DOI 10.17487/RFC4760, January 2007,
<http://www.rfc-editor.org/info/rfc4760>. <https://www.rfc-editor.org/info/rfc4760>.
[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, <http://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,
<http://www.rfc-editor.org/info/rfc5575>. <https://www.rfc-editor.org/info/rfc5575>.
11.2. Informative References 11.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.
Authors' Addresses Authors' Addresses
skipping to change at page 23, line 4 skipping to change at page 38, line 4
Email: luoyuj@gsta.com Email: luoyuj@gsta.com
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
Huawei
Boston, MA
USA
Email: Huaimo.chen@huawei.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
Nan Wu Nan Wu
Huawei Huawei
 End of changes. 126 change blocks. 
257 lines changed or deleted 871 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/