Network Working Group Z. Li Internet-Draft Huawei Intended status: Standards Track L. Ou Expires: April 25, 2019 Y. Luo China Telcom Co., Ltd. S. Lu Tencent H. Chen S. Zhuang N. Wu Huawei October 22, 2018 BGP FlowSpec Extensions for Routing Policy Distribution (RPD) draft-li-idr-flowspec-rpd-03 Abstract This document describes a mechanism to use BGP Flowspec address family as routing-policy distribution protocol. This mechanism is called BGP FlowSpec Extensions for Routing Policy Distribution (BGP- FS RPD). Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 25, 2019. Li, et al. Expires April 25, 2019 [Page 1] Internet-Draft BGP FS RPD October 2018 Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 3. Problem Statements . . . . . . . . . . . . . . . . . . . . . 4 3.1. Inbound Traffic Control . . . . . . . . . . . . . . . . . 4 3.2. Outbound Traffic Control . . . . . . . . . . . . . . . . 5 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 6 5. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6 5.1. Traffic Actions for Routing Policy Distribution . . . . . 7 5.2. Option 1: BGP Policy Attribute . . . . . . . . . . . . . 7 5.2.1. Match Fields . . . . . . . . . . . . . . . . . . . . 8 5.2.2. Action Fields . . . . . . . . . . . . . . . . . . . . 13 5.2.3. Application Examples . . . . . . . . . . . . . . . . 15 5.3. Option 2: BGP Wide Community . . . . . . . . . . . . . . 19 5.3.1. New Wide Community Atoms . . . . . . . . . . . . . . 20 5.3.2. New Wide Community Actions . . . . . . . . . . . . . 26 5.3.3. Application Examples . . . . . . . . . . . . . . . . 27 5.4. Capability Negotiation . . . . . . . . . . . . . . . . . 34 6. Consideration . . . . . . . . . . . . . . . . . . . . . . . . 34 6.1. Route-Policy . . . . . . . . . . . . . . . . . . . . . . 34 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 11.1. Normative References . . . . . . . . . . . . . . . . . . 36 11.2. Informative References . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Li, et al. Expires April 25, 2019 [Page 2] Internet-Draft BGP FS RPD October 2018 1. Introduction It is difficult to optimize traffic paths on a traditional IP network because of: o Heavy configuration and error prone. Traffic can only be adjusted device by device. All routers that the traffic traverses need to be configured. The configuration workload is heavy. The operation is not only time consuming but also prone to misconfiguration for Service Providers. o Complex. The routing policies used to control network routes are complex, posing difficulties to subsequent maintenance, high maintenance skills are required. It is desirable to have an automatic mechanism for setting up routing policies, which can simplify the routing policies configuration. This document describes extensions to BGP for Routing Policy Distribution. 2. Definitions and Acronyms BGP Flow Specification route: BGP Flow Specification routes are defined in RFC 5575. Each BGP Flow Specification route contains BGP Network Layer Reachability Information (NLRI) and Extended Community Attributes, which carry traffic filtering rules and actions to be taken on filtered traffic. BGP Flow Specification peer relationship: A BGP Flow Specification peer relationship is established between the device that generates BGP Flow Specification routes and each network ingress that will transmit the BGP Flow Specification routes. After receiving the BGP Flow Specification routes, the peer delivers preferred BGP Flow Specification routes to the forwarding plane. The routes are then converted into traffic policies that control attack traffic. o ACL:Access Control List o BGP: Border Gateway Protocol o FS: Flow Specification o PBR:Policy-Based Routing o RPD: Routing Policy Distribution o VPN: Virtual Private Network Li, et al. Expires April 25, 2019 [Page 3] Internet-Draft BGP FS RPD October 2018 3. Problem Statements It is obvious that providers have the requirements to adjust their business traffic from time to time because: o Business development or network failure introduces link congestion and overload. o Network transmission quality is decreased as the result of delay, loss and they need to adjust traffic to other paths. o To control OPEX and CPEX, prefer the transit provider with lower price. 3.1. Inbound Traffic Control In the scenario below, for the reasons above, the provider of AS100 saying P may wish the inbound traffic from AS200 enters AS100 through link L3 instead of the others. Since P doesn't have any administration over AS200, so there is no way for P to modify the route selection criteria directly. Li, et al. Expires April 25, 2019 [Page 4] Internet-Draft BGP FS RPD October 2018 Traffic from PE1 to Prefix1 -----------------------------------> +-----------------+ +-------------------------+ | +---------+ | L1 | +----+ +----------+| | |Speaker1 | +------------+ |IGW1| |policy || | +---------+ |** L2**| +----+ |controller|| | | ** ** | +----------+| | +---+ | **** | | | |PE1| | **** | | | +---+ | ** ** | | | +---------+ |** L3**| +----+ | | |Speaker2 | +------------+ |IGW2| AS100 | | +---------+ | L4 | +----+ | | | | | | AS200 | | | | | | ... | | | | | | +---------+ | | +----+ +-------+ | | |Speakern | | | |IGWn| |Prefix1| | | +---------+ | | +----+ +-------+ | +-----------------+ +-------------------------+ Prefix1 advertised from AS100 to AS200 <---------------------------------------- Inbound Traffic Control case 3.2. Outbound Traffic Control In the scenario below, the provider of AS100 saying P prefers link L3 for the traffic to the destination Prefix2 among multiple exits and links. This preference can be dynamic and changed frequently because of the reasons above. So the provider P expects an efficient and convenient solution. Li, et al. Expires April 25, 2019 [Page 5] Internet-Draft BGP FS RPD October 2018 Traffic from PE2 to Prefix2 -----------------------------------> +-------------------------+ +-----------------+ |+----------+ +----+ |L1 | +---------+ | ||policy | |IGW1| +------------+ |Speaker1 | | ||controller| +----+ |** **| +---------+ | |+----------+ |L2** ** | +-------+| | | **** | |Prefix2|| | | **** | +-------+| | |L3** ** | | | AS100 +----+ |** **| +---------+ | | |IGW2| +------------+ |Speaker2 | | | +----+ |L4 | +---------+ | | | | | |+---+ | | AS200 | ||PE2| ... | | | |+---+ | | | | +----+ | | +---------+ | | |IGWn| | | |Speakern | | | +----+ | | +---------+ | +-------------------------+ +-----------------+ Prefix2 advertised from AS200 to AS100 <---------------------------------------- Outbound Traffic Control case 4. Proposed Solution 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 introduces a mechanism that uses BGP Flowspec as a routing policy distribution protocol. It can be as powerful as the device-based routing policy while still has the efficiency and convenience of BGP Flowspec. This draft will use the term BGP-FS RPD (or BGP RPD for short) as the abbreviation of BGP Extensions for Routing Policy Distribution. 5. Protocol Extensions Li, et al. Expires April 25, 2019 [Page 6] Internet-Draft BGP FS RPD October 2018 5.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 corresponding filtering rules will be used as Routing Policy. 5.2. Option 1: 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. Li, et al. Expires April 25, 2019 [Page 7] Internet-Draft BGP FS RPD October 2018 5.2.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. Li, et al. Expires April 25, 2019 [Page 8] Internet-Draft BGP FS RPD October 2018 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: Li, et al. Expires April 25, 2019 [Page 9] Internet-Draft BGP FS RPD October 2018 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 s. Each triple 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 Li, et al. Expires April 25, 2019 [Page 10] Internet-Draft BGP FS RPD October 2018 It contains a number of triple s. Each triple 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: Li, et al. Expires April 25, 2019 [Page 11] Internet-Draft BGP FS RPD October 2018 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: Li, et al. Expires April 25, 2019 [Page 12] Internet-Draft BGP FS RPD October 2018 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. 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: Li, et al. Expires April 25, 2019 [Page 13] Internet-Draft BGP FS RPD October 2018 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: Li, et al. Expires April 25, 2019 [Page 14] Internet-Draft BGP FS RPD October 2018 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. Li, et al. Expires April 25, 2019 [Page 15] Internet-Draft BGP FS RPD October 2018 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 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; Li, et al. Expires April 25, 2019 [Page 16] Internet-Draft BGP FS RPD October 2018 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; Li, et al. Expires April 25, 2019 [Page 17] Internet-Draft BGP FS RPD October 2018 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. 5.2.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. Li, et al. Expires April 25, 2019 [Page 18] Internet-Draft BGP FS RPD October 2018 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. 5.3. Option 2: BGP Wide Community The BGP wide community is defined in [I-D.ietf-idr-wide-bgp-communities]. It can be used to facilitate the delivery of new network services, and be extended easily for distributing different kinds of routing policies. Li, et al. Expires April 25, 2019 [Page 19] Internet-Draft BGP FS RPD October 2018 This section describes an alternative extension to BGP protocol, 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 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). The format of the TLV (or sub-TLV) and 8 wide community Atoms are defined in [I-D.ietf-idr-wide-bgp-communities]. 3 new wide community 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 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Format of Wide Community Atom TLV 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: Li, et al. Expires April 25, 2019 [Page 20] Internet-Draft BGP FS RPD October 2018 +------+---------------------------------------------------------+ | 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 | +------+---------------------------------------------------------+ Existing and New Wide Community Atoms The wide community Atom BGP IPv4 Session contains the IPv4 local address and remote address of a BGP session. 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 (TBD1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Format of Atom BGP IPv4 Session The wide community Atom BGP IPv6 Session contains the IPv6 local address and remote address of a BGP session. Its format is illustrated below: Li, et al. Expires April 25, 2019 [Page 21] Internet-Draft BGP FS RPD October 2018 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 Atom BGP IPv6 Session The wide community Atom IPv4 Prefix Range 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 Atom IPv4 Prefix Range It contains a number of triple s. Each triple 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 represents prefix IPv4-Address/MaskLen. The encoding of Atom IPv4 Prefix Range may be optimized as the format below: Li, et al. Expires April 25, 2019 [Page 22] Internet-Draft BGP FS RPD October 2018 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 s. Each triple 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: Li, et al. Expires April 25, 2019 [Page 23] Internet-Draft BGP FS RPD October 2018 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: Li, et al. Expires April 25, 2019 [Page 24] Internet-Draft BGP FS RPD October 2018 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: Li, et al. Expires April 25, 2019 [Page 25] Internet-Draft BGP FS RPD October 2018 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 Li, et al. Expires April 25, 2019 [Page 26] Internet-Draft BGP FS RPD October 2018 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. Li, et al. Expires April 25, 2019 [Page 27] Internet-Draft BGP FS RPD October 2018 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 Li, et al. Expires April 25, 2019 [Page 28] Internet-Draft BGP FS RPD October 2018 5.3.3.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: Li, et al. Expires April 25, 2019 [Page 29] Internet-Draft BGP FS RPD October 2018 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: ; 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 Li, et al. Expires April 25, 2019 [Page 30] Internet-Draft BGP FS RPD October 2018 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: ; 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. 5.3.3.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: Li, et al. Expires April 25, 2019 [Page 31] Internet-Draft BGP FS RPD October 2018 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; Li, et al. Expires April 25, 2019 [Page 32] Internet-Draft BGP FS RPD October 2018 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; Li, et al. Expires April 25, 2019 [Page 33] Internet-Draft BGP FS RPD October 2018 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. 5.4. Capability Negotiation It is necessary to negotiate the capability to support BGP Extensions for Routing Policy Distribution (RPD). The BGP RPD Capability is a new BGP capability [RFC5492]. The Capability Code for this capability is to be specified by the IANA. The Capability Length field of this capability is variable. The Capability Value field consists of one or more of the following tuples: +--------------------------------------------------+ | Address Family Identifier (2 octets) | +--------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +--------------------------------------------------+ | Send/Receive (1 octet) | +--------------------------------------------------+ BGP RPD Capability The meaning and use of the fields are as follows: Address Family Identifier (AFI): This field is the same as the one used in [RFC4760]. Subsequent Address Family Identifier (SAFI): This field is the same as the one used in [RFC4760]. Send/Receive: This field indicates whether the sender is (a) willing to receive Routing Policies from its peer (value 1), (b) would like to send Routing Policies to its peer (value 2), or (c) both (value 3) for the . 6. Consideration 6.1. Route-Policy Routing policies are used to filter routes and control how routes are received and advertised. If route attributes, such as reachability, are changed, the path along which network traffic passes changes accordingly. When advertising, receiving, and importing routes, the router implements certain policies based on actual networking requirements Li, et al. Expires April 25, 2019 [Page 34] Internet-Draft BGP FS RPD October 2018 to filter routes and change the attributes of the routes. Routing policies serve the following purposes: o Control route advertising: Only routes that match the rules specified in a policy are advertised. o Control route receiving: Only the required and valid routes are received. This reduces the size of the routing table and improves network security. o Filter and control imported routes: A routing protocol may import routes discovered by other routing protocols. Only routes that satisfy certain conditions are imported to meet the requirements of the protocol. o Modify attributes of specified routes Attributes of the routes: that are filtered by a routing policy are modified to meet the requirements of the local device. o Configure fast reroute (FRR): If a backup next hop and a backup outbound interface are configured for the routes that match a routing policy, IP FRR, VPN FRR, and IP+VPN FRR can be implemented. Routing policies are implemented using the following procedures: 1. Define rules: Define features of routes to which routing policies are applied. Users define a set of matching rules based on different attributes of routes, such as the destination address and the address of the router that advertises the routes. 2. Implement the rules: Apply the matching rules to routing policies for advertising, receiving, and importing routes. 7. Contributors The following people have substantially contributed to the definition of the BGP-FS RPD and to the editing of this document: Peng Zhou Huawei Email: Jewpon.zhou@huawei.com 8. IANA Considerations TBD. Li, et al. Expires April 25, 2019 [Page 35] Internet-Draft BGP FS RPD October 2018 9. Security Considerations TBD. 10. Acknowledgements The authors would like to thank Acee Lindem, Jeff Haas, Jie Dong, Haibo Wang, Lucy Yong, Qiandeng Liang, Zhenqiang Li for their comments to this work. 11. References 11.1. Normative References [I-D.ietf-idr-wide-bgp-communities] Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S., and P. Jakma, "BGP Community Container Attribute", draft- ietf-idr-wide-bgp-communities-05 (work in progress), July 2018. [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, . [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, . Li, et al. Expires April 25, 2019 [Page 36] Internet-Draft BGP FS RPD October 2018 11.2. Informative References [I-D.ietf-idr-registered-wide-bgp-communities] Raszuk, R. and J. Haas, "Registered Wide BGP Community Values", draft-ietf-idr-registered-wide-bgp-communities-02 (work in progress), May 2016. Authors' Addresses Zhenbin Li Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Liang Ou China Telcom Co., Ltd. 109 West Zhongshan Ave,Tianhe District Guangzhou 510630 China Email: oul@gsta.com Yujia Luo China Telcom Co., Ltd. 109 West Zhongshan Ave,Tianhe District Guangzhou 510630 China Email: luoyuj@gsta.com Sujian Lu Tencent Tengyun Building,Tower A ,No. 397 Tianlin Road Shanghai, Xuhui District 200233 China Email: jasonlu@tencent.com Li, et al. Expires April 25, 2019 [Page 37] Internet-Draft BGP FS RPD October 2018 Huaimo Chen Huawei Boston, MA USA Email: Huaimo.chen@huawei.com Shunwan Zhuang Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zhuangshunwan@huawei.com Nan Wu Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: eric.wu@huawei.com Li, et al. Expires April 25, 2019 [Page 38]