Network Working Group J. Dong Internet-Draft Huawei Technologies Intended status: Standards Track Z. Li Expires: January 5, 2017 China Mobile L. Ou Y. Luo China Telcom Co., Ltd. July 4, 2016 BGP FlowSpec Extensions for Large Scale Prefix based Steering draft-dong-idr-flowspec-scalable-prefix-steering-00 Abstract This document describes a mechanism to use BGP FlowSpec RFC5575 as a scalable way of distributing prefix based traffic steering policies. The necessary extensions to BGP are also specified. 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 http://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 January 5, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Dong, et al. Expires January 5, 2017 [Page 1] Internet-DraftBGP-FS for Large Scale Prefix Based Steering July 2016 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Typical Scenario of Prefix based Traffic Steering . . . . . . 3 3. Proposed BGP Extensions . . . . . . . . . . . . . . . . . . . 4 3.1. New Wide Community Atom . . . . . . . . . . . . . . . . . 4 3.2. New Wide BGP Community . . . . . . . . . . . . . . . . . 5 4. Operational Procedures . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Dynamic traffic steering becomes more and more popular in operator networks. It is desirable that an automatic and scalable mechanism can be provided to dynamically deploy such policies to network devices. BGP FlowSpec [RFC5575] provides a flexible mechanism to specify the matching rules and the corresponding actions for specific traffic. Due to the flexibility of BGP FlowSpec, the number of flowspec filtering entries supported in hardware is usually limited, which is suitable for a small number of complicated traffic matching and manipulation policies. In some operator networks, there are requirements of dynamically deploying a large amount of destination prefix based traffic steering policies, thus some scalable mechanism for large scale prefix based traffic steering policy is needed. One possible option is that the controller advertises the destination prefix based steering policy as normal IP routes directly to the network devices. Although this seems straightforward, it is difficult to determine the interaction results of the steering routes and the existing routes in the devices, and may have unexpected impacts to the whole network. Dong, et al. Expires January 5, 2017 [Page 2] Internet-DraftBGP-FS for Large Scale Prefix Based Steering July 2016 Another option is that the controller advertises the destination prefix based steering policy as BGP FlowSpec routes to the network devices. Instead of installing these routes as the BGP FlowSpec filtering entries, the network devices are instructed by the controller to download the prefix based steering policies to their Forwarding Information Base (FIB), so that the number of prefix based steering policy supported is not limited by the number of BGP FlowSpec filtering entries. This document proposes to use the mechanism in the second option, and specifies the required extensions to BGP protocol. 2. Typical Scenario of Prefix based Traffic Steering In ISP networks, usually there are multiple paths to a particular destination. The path with better QoS characteristics such as latency, loss, jitter, etc., is preferred. Since these QoS characteristics change from time to time, the decision of path selection also needs to be changed accordingly. Figure 1 shows a typical scenario of prefix based traffic steering in inter-domain ISP networks. As shown in the figure, there are two transit nodes from AS-1 to the destination Prefix-1 in AS-4, saying transit node M in AS-2 and transit node N in AS-3. In normal state, traffic from AS-1 to Prefix-1 goes through transit node M. While transit node N would be preferred when performance degradation happens on transit node M. In that case, traffic should be steered to go through transit node N instead. According to the real time network performance condition, the traffic steering policy needs to be changed dynamically. Thus the operator of AS-1 expects an efficient and convenient mechanism for steering the traffic to different transit nodes. Dong, et al. Expires January 5, 2017 [Page 3] Internet-DraftBGP-FS for Large Scale Prefix Based Steering July 2016 ******************************** * +----------+ * * AS-1 | Policy | * * |Controller| * AS-2 * +----------+ * * +---+ +---+ * +-----------+ * /| B |---------| C |-----| Transit M |\ AS-4 * / +---+\ +---+\ * +-----------+ \\ * / | \\ / | \ / \ +---------+ *+---+/ | \\// | * \ / \_| | *| A | | //\ | * X _| Prefix-1| *+---+\ | // \\ | * / \ / | | * \ | / \ | / \ / +---------+ * \ +---+ +---+/ * +-----------+ // * \| D |---------| E |-----| Transit N |/ * +---+ +---+ * +-----------+ * * * ISP Network * AS-3 * * ******************************** Figure 1. Scenario of Prefix Based Traffic Steering 3. Proposed BGP Extensions This section specifies the proposed extension to BGP protocol. 3.1. New Wide Community Atom A new Wide Community Atoms TLV [I-D.ietf-idr-wide-bgp-communities] "Bit Flags List Atom" is defined. This atom is an array of units of 32 flags numbered from the most significant bit as bit zero. The Length field for this TLV is always a multiple of four bytes, regardless of the number of bits carried, and no padding is required. Unassigned bits are considered as reserved and MUST be set to zero on transmission by the originator of this TLV. Bits not contained in the TLV MUST be assumed to be set to zero. Type (TBA): Bit Flags List Atom One flag (bit 31) is defined in this document. When this flag is set to 1, recursive route lookup SHOULD be performed in the local routing table identified by the address family of the received route with this TLV. When this bit is set to 0, recursive route lookup SHOULD be performed in the global routing table. Dong, et al. Expires January 5, 2017 [Page 4] Internet-DraftBGP-FS for Large Scale Prefix Based Steering July 2016 +-------+-------+--------------------------------------------------+ | Bit | Value | Meaning | +-------+-------+--------------------------------------------------+ | 31 | 0 | recursive route lookup in global table | | | 1 | recursive route lookup in local table | | other | - | MUST be zero when sent and ignored upon receipt. | +-------+-------+--------------------------------------------------+ The assignment of other bits is managed by IANA. 3.2. New Wide BGP Community A new Registered Wide BGP Community "Download to FIB" is defined. It is used to instruct the receiving BGP speakers to download the BGP FlowSpec routes carrying this Wide Community into the FIB, instead of installing the FlowSpec routes into FlowSpec filtering entries. Download TO FIB: Type: 0x0001 S = src AS # F = 0x80 C = 0x00000000 H = 0 T = none L = 22 octets E = none R = TBA by IANA P = Type_TBD (Flags 0x00000001) An example of the Download to FIB Wide BGP community generated by the policy controller in Figure 1 is as 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 (1) |1 0 0 0 0 0 0 0| Hop Count: 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length: 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Community: Download TO FIB (IANA assigned) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source AS Number: A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context AS Number: 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Param TLV (3) | Length: 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags (TBD) | Length: 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dong, et al. Expires January 5, 2017 [Page 5] Internet-DraftBGP-FS for Large Scale Prefix Based Steering July 2016 4. Operational Procedures In order to achieve dynamic prefix based traffic steering in the scenario of Figure 1, the controller of AS-1 constructs a BGP FlowSpec route which carries the following information: o Prefix-1 as the Destination Prefix component of BGP FlowSpec NLRI. o Traffic-Action Extended Community, with the Route Policy Distribution (RPD) [I-D.li-idr-flowspec-rpd] Flag set. This is to indicate that the corresponding FlowSpec filtering rules are used as routing policies. o NO_ADVERTISE Community [RFC1997]. This indicates that the receiving BGP speaker MUST NOT advertise this BGP FlowSpec route to other BGP peers. o "Redirect to IP" Extended Communities [I-D.ietf-idr-flowspec-redirect-ip], with the global administrator field set to the address of transit node N. o "Download to FIB" Wide BGP Community to indicate that the receiving BGP speaker SHOULD download this BGP FlowSpec filtering rule to its FIB. The controller of AS-1 sends this BGP FlowSpec route to the ASBRs of AS-1, i.e. router C and E. On receipt of this BGP FlowSpec route from the controller, the routers processes the received BGP FlowSpec route as follows: o Extracts the target prefix Prefix-1 from the Destination Prefix component in the BGP FlowSpec NLRI. o Identifies that the RPD Flag in the Traffic-Action Extended Community is set, so the corresponding filtering rules will be used as Routing Policies. o Parses the "Download to FIB" Wide BGP Community, and knows that this FlowSpec route SHOULD be downloaded into FIB entry, instead of being installed as FlowSpec filtering entry. And according to the Flag Bit 31 in the Wide Community Parameters TLV, knows that the recursive route lookup should be performed in the global routing table. o Extracts the redirect IP address from the "Redirect to IP" Extended Communities, which will be used for the recursive route lookup. Dong, et al. Expires January 5, 2017 [Page 6] Internet-DraftBGP-FS for Large Scale Prefix Based Steering July 2016 After performing the recursive lookup in the designated routing table, the connected next hop is identified and this route is downloaded as a FIB entry into the forwarding plane. 5. IANA Considerations IANA is requested to assign a new code point for the "Bit Flags List Atom" TLV from the "Wide BGP Communities Atom Types" registry. IANA is requested to assign a new code point for the "Download to FIB" Wide BGP Community from the "Registered Wide BGP Communities" registry. 6. Security Considerations TBD 7. Contributing Authors The following individuals gave significant contributions to this document: Peng Zhang China Telecom 15335170018@189.cn Zhongchao Li China Telecom 15301588336@189.cn Dong Shu China Telecom 15301586130@189.cn 8. Acknowledgements The authors would like to thank Shunwan Zhuang, Nan Wu and Haibo Wang for the valuable discussion on this work. 9. Normative References [I-D.ietf-idr-flowspec-redirect-ip] Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work in progress), February 2015. Dong, et al. Expires January 5, 2017 [Page 7] Internet-DraftBGP-FS for Large Scale Prefix Based Steering July 2016 [I-D.ietf-idr-wide-bgp-communities] Raszuk, R., Haas, J., Lange, A., Amante, S., Decraene, B., Jakma, P., and R. Steenbergen, "Wide BGP Communities Attribute", draft-ietf-idr-wide-bgp-communities-02 (work in progress), May 2016. [I-D.li-idr-flowspec-rpd] Li, Z., Ou, L., Luo, Y., Lu, S., Zhuang, S., and N. Wu, "BGP FlowSpec Extensions for Routing Policy Distribution (RPD)", draft-li-idr-flowspec-rpd-02 (work in progress), June 2016. [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, . [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, . Authors' Addresses Jie Dong Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: jie.dong@huawei.com Zhenqiang Li China Mobile No.32 Xuanwumenxi Ave., Xicheng District Beijing 100032 China Email: li_zhenqiang@hotmail.com Dong, et al. Expires January 5, 2017 [Page 8] Internet-DraftBGP-FS for Large Scale Prefix Based Steering July 2016 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 Dong, et al. Expires January 5, 2017 [Page 9]