--- 1/draft-vandevelde-idr-flowspec-path-redirect-01.txt 2016-03-17 14:19:46.795954309 -0700 +++ 2/draft-vandevelde-idr-flowspec-path-redirect-02.txt 2016-03-17 14:19:46.819954904 -0700 @@ -1,40 +1,41 @@ IDR Working Group G. Van de Velde, Ed. Internet-Draft W. Henderickx Intended status: Standards Track Alcatel-Lucent -Expires: July 15, 2016 K. Patel +Expires: September 18, 2016 K. Patel + A. Sreekantiah Cisco Systems - January 12, 2016 + March 17, 2016 Flowspec Indirection-id Redirect - draft-vandevelde-idr-flowspec-path-redirect-01 + draft-vandevelde-idr-flowspec-path-redirect-02 Abstract Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications but the primary one for many network operators is the distribution of traffic filtering actions for DDoS mitigation. The flow-spec standard RFC5575 [2] defines a redirect-to-VRF action for policy-based forwarding but this mechanism is not always sufficient, particular if the redirected traffic needs to be steered into an engineered path or into a service plane. This document defines a new redirect-to-INDIRECTION_ID (32-bit or 128-bit) flow-spec action to provide advanced redirection capabilities. When activated, the flowspec Indirection-id is used to identify the next-hop redirect information within a router locallized Indirection-id table. This allows a flowspec controller to signal redirection towards a next-hop IP address, a shortest path tunnel, a - traffic engineered tunnel or a next-next-hop (traffic engineered) - tunnel egress interface. + traffic engineered tunnel or a next-next-hop engineered tunnel + interface. 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 [1]. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -43,21 +44,21 @@ 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 July 15, 2016. + This Internet-Draft will expire on September 18, 2016. Copyright Notice Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -69,28 +70,28 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. INDIRECTION_ID and INDIRECTION_ID Table . . . . . . . . . . . 3 3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 4 3.1. Redirection shortest Path tunnel . . . . . . . . . . . . 4 3.2. Redirection to path-engineered tunnels . . . . . . . . . 4 3.3. Redirection to Next-next-hop tunnels . . . . . . . . . . 5 4. Redirect to INDIRECTION-ID Communities . . . . . . . . . . . 6 - 5. Redirect using locallized INDIRECTION_ID Router Mapping . . . 6 - 6. Validation Procedures . . . . . . . . . . . . . . . . . . . . 7 + 5. Redirect using locallized INDIRECTION_ID Router Mapping . . . 7 + 6. Validation Procedures . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 - 10.2. Informative References . . . . . . . . . . . . . . . . . 8 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 + 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Flow-spec RFC5575 [2] is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications but the primary one for many network operators is the distribution of traffic filtering actions for DDoS mitigation. Every flow-spec route is effectively a rule, consisting of a matching @@ -175,35 +176,55 @@ 3.2. Redirection to path-engineered tunnels A second use-case is allowing a BGP Flowspec controller send a single flowspec policy message (redirect-to-INDIRECTION_ID#2) to many BGP flowspec consuming routers. This message is instructing the Flowspec recipient routers to redirect traffic onto a path engineered tunnel. For this use-case scenario, each flowspec recipient router has a path engineered tunnel configured. Each tunnel can have its own unique - encapsulation and engineerd path associated. Each tunnel is + encapsulation and engineered path associated. Each tunnel is associated with an INDIRECTION_ID, and for this example it is on all recipient routers INDIRECTION_ID#2. Both manual and orchestrated tunnel provisioning is supported, however for large scale deployment automation is advisable. - When using this setup, a BGP flowspec controller can send a single - BGP Flowspec NLRI with redirect-to-INDIRECTION_ID#2. This BGP - Flowspec NLRI is received by all recipient routers. Each of the - recipient routers performs a locallised recursive lookup for + A first example using this setup, is when a BGP flowspec controller + sends a single BGP Flowspec NLRI with redirect-to-INDIRECTION_ID#2. + This BGP Flowspec NLRI is received by all recipient routers. Each of + the recipient routers performs a locallised recursive lookup for INDIRECTION_ID#2 in the INDIRECTION_ID Table and identifies the corresponding locallised tunnel redirect information. This locallised tunnel information is now used to redirect traffic matching the Flowspec policy towards a path engineered tunnel. + A second example can be found in segment routed networks where path + engineered tunnels can be setup by means of a controller signaling + explicit paths to peering routers. In such a case, the + INDIRECTION_ID references to a Segment Routing Binding SID. The + Binding SID is a segment identifier value (as per segment routing + definitions in [I-D.draft-ietf-spring-segment-routing] [6]) used to + associate with a explicit path and can be setup by a controller using + BGP as specified in [I-D.sreekantiah-idr-segment-routing-te] [5] or + using PCE as detailed in draft-ietf-pce-segment-routing [7]. When a + BGP speaker receives a flow-spec route with a 'redirect to Binding + SID' extended community, it installs a traffic filtering rule that + matches the packets described by the NLRI field and redirects them to + the explicit path associated with the Binding SID. The explicit path + is specified as a set/stack of segment identifiers as detailed in the + previous documents. The stack of segment identifiers is now imposed + on packets matching the flow-spec rule to perform redirection as per + the explicit path setup prior. The encoding of the Binding SID value + is specified in section 4, with the indirection field now encoding + the associated value for the binding SID. + 3.3. Redirection to Next-next-hop tunnels A Third use-case is allowing a BGP Flowspec controller send a single flowspec policy message (redirect-to-INDIRECTION_ID#3) to many BGP flowspec consuming routers. This message is instructing the Flowspec recipient routers to redirect traffic onto a shortest or engineered path to a tunnel end-point and onwards to the next-hop-interface on this end-point. This type of tunnel is used for example for Segment Routing Central Egress Path Engineering [4]. @@ -247,37 +268,41 @@ administrator fields encode a flow-spec 'redirect to INDIRECTION_ID' action. In the new extended community the 4-byte or 16-byte global administrator field encodes the 32-bit or 128-bit INDIRECTION_ID's providing the INDIRECTION_ID to allow a local to the router mapping reference to an engineered Path. The 2-byte local administrator field is formatted as shown in Figure 1. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Reserved |TID|C| + | Reserved |B|TID|C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 In the local administrator field the least-significant bit is defined as the 'C' (or copy) bit. When the 'C' bit is set the redirection applies to copies of the matching packets and not to the original traffic stream. The 'TID' field identifies a 2 bit Table-id field. This field is used to provide the router consuming the flowspec rule an indication how and where to use the INDIRECTION_ID when redirecting traffic. - All bits other than the 'C' bit in the local administrator field MUST - be set to 0 by the originating BGP speaker and ignored by receiving - BGP speakers. + Bit 2 is defined to be the 'B' (Binding) bit. When the 'B' bit is + set, the value encoded in the global administrator field is a Binding + Segment Identifier value the use of which is detailed in section 3.2. + + All bits other than the 'C', 'TID' and 'B' bits in the local + administrator field MUST be set to 0 by the originating BGP speaker + and ignored by receiving BGP speakers. 5. Redirect using locallized INDIRECTION_ID Router Mapping When a BGP speaker receives a flow-spec route with a 'redirect to INDIRECTION_ID' extended community and this route represents the one and only best path, it installs a traffic filtering rule that matches the packets described by the NLRI field and redirects them (C=0) or copies them (C=1) towards the INDIRECTION_ID local recursed Path. The BGP speaker is expected to do a local INDIRECTION_ID Table lookup to identify the redirection information. @@ -357,37 +381,50 @@ Requirement Levels", BCP 14, RFC 2119, March 1997, . [2] 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, . 10.2. Informative References - [3] Uttaro, J., Filsfils, C., Filsfils, C., Alcaide, J., and - P. Mohapatra, "Revised Validation Procedure for BGP Flow + [3] Uttaro, J., Filsfils, C., Alcaide, J., and P. Mohapatra, + "Revised Validation Procedure for BGP Flow Specifications", January 2014. [4] Filsfils, C., Previdi, S., Aries, E., Ginsburg, D., and D. Afanasiev, "Segment Routing Centralized Egress Peer Engineering", October 2015. + [5] Sreekantiah, A., Filsfils, C., Previdi, S., Sivabalan, S., + Mattes, P., and S. Lin, "Segment Routing Traffic + Engineering Policy using BGP", October 2015. + + [6] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., + Shakir, R., Bashandy, A., Horneffer, M., Henderickx, W., + Tantsura, J., Crabbe, E., Milojevic, I., and S. Ytti, + "Segment Routing Architecture", December 2015. + + [7] Sivabalan, S., Medved, M., Filsfils, C., Litkowski, S., + Raszuk, R., Bashandy, A., Lopez, V., Tantsura, J., + Henderickx, W., Hardwick, J., Milojevic, I., and S. Ytti, + "PCEP Extensions for Segment Routing", December 2015. + Authors' Addresses Gunter Van de Velde (editor) Alcatel-Lucent Antwerp BE Email: gunter.van_de_velde@alcatel-lucent.com - Wim Henderickx Alcatel-Lucent Antwerp BE Email: wim.henderickx@alcatel-lucent.com Keyur Patel Cisco Systems 170 W. Tasman Drive @@ -388,10 +425,18 @@ Email: wim.henderickx@alcatel-lucent.com Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: keyupate@cisco.com + + Arjun Sreekantiah + Cisco Systems + 170 W. Tasman Drive + San Jose, CA 95134 + USA + + Email: asreekan@cisco.com