draft-vandevelde-idr-flowspec-path-redirect-02.txt   draft-vandevelde-idr-flowspec-path-redirect-03.txt 
IDR Working Group G. Van de Velde, Ed. IDR Working Group G. Van de Velde, Ed.
Internet-Draft W. Henderickx Internet-Draft W. Henderickx
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track Nokia
Expires: September 18, 2016 K. Patel Expires: January 9, 2017 K. Patel
A. Sreekantiah A. Sreekantiah
Cisco Systems Cisco Systems
March 17, 2016 Z. Li
S. Zhuang
N. Wu
Huawei Technologies
July 8, 2016
Flowspec Indirection-id Redirect Flowspec Indirection-id Redirect
draft-vandevelde-idr-flowspec-path-redirect-02 draft-vandevelde-idr-flowspec-path-redirect-03
Abstract Abstract
Flow-spec is an extension to BGP that allows for the dissemination of Flowspec is an extension to BGP that allows for the dissemination of
traffic flow specification rules. This has many possible traffic flow specification rules. This has many possible
applications but the primary one for many network operators is the applications but the primary one for many network operators is the
distribution of traffic filtering actions for DDoS mitigation. The distribution of traffic filtering actions for DDoS mitigation. The
flow-spec standard RFC5575 [2] defines a redirect-to-VRF action for flow-spec standard RFC5575 [2] defines a redirect-to-VRF action for
policy-based forwarding but this mechanism is not always sufficient, policy-based forwarding but this mechanism is not always sufficient,
particular if the redirected traffic needs to be steered into an particularly if the redirected traffic needs to be steered into an
engineered path or into a service plane. engineered path or into a service plane.
This document defines a new redirect-to-INDIRECTION_ID (32-bit or This document defines a new extended community known as redirect-to-
128-bit) flow-spec action to provide advanced redirection indirection-id (32-bit) flowspec action to provide advanced
capabilities. When activated, the flowspec Indirection-id is used to redirection capabilities on flowspec clients. When activated, the
identify the next-hop redirect information within a router locallized flowspec extended community is used by a flowspec client to find the
Indirection-id table. This allows a flowspec controller to signal correct next-hop entry within a localised indirection-id mapping
redirection towards a next-hop IP address, a shortest path tunnel, a table.
traffic engineered tunnel or a next-next-hop engineered tunnel
interface. The functionality present in this draft allows a network controller
to decouple flowspec functionality from the creation and maintainance
of the network's service plane itself including the setup of tunnels
and other service constructs that could be managed by other network
devices.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
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
skipping to change at page 2, line 10 skipping to change at page 2, line 20
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 http://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 September 18, 2016. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. INDIRECTION_ID and INDIRECTION_ID Table . . . . . . . . . . . 3 2. indirection-id and indirection-id table . . . . . . . . . . . 3
3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 4 3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 4
3.1. Redirection shortest Path tunnel . . . . . . . . . . . . 4 3.1. Redirection shortest Path tunnel . . . . . . . . . . . . 4
3.2. Redirection to path-engineered tunnels . . . . . . . . . 4 3.2. Redirection to path-engineered tunnels . . . . . . . . . 4
3.3. Redirection to Next-next-hop tunnels . . . . . . . . . . 5 3.3. Redirection to Next-next-hop tunnels . . . . . . . . . . 5
4. Redirect to INDIRECTION-ID Communities . . . . . . . . . . . 6 4. Redirect to indirection-id Community . . . . . . . . . . . . 6
5. Redirect using locallized INDIRECTION_ID Router Mapping . . . 7 5. Redirect using localised indirection-id mapping table . . . . 8
6. Validation Procedures . . . . . . . . . . . . . . . . . . . . 8 6. Validation Procedures . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Flow-spec RFC5575 [2] is an extension to BGP that allows for the Flowspec RFC5575 [2] is an extension to BGP that allows for the
dissemination of traffic flow specification rules. This has many dissemination of traffic flow specification rules. This has many
possible applications but the primary one for many network operators possible applications, however the primary one for many network
is the distribution of traffic filtering actions for DDoS mitigation. operators is the distribution of traffic filtering actions for DDoS
mitigation.
Every flow-spec route is effectively a rule, consisting of a matching Every flowspec policy route is effectively a rule, consisting of a
part (encoded in the NLRI field) and an action part (encoded in one matching part (encoded in the NLRI field) and an action part (encoded
or more BGP extended community). The flow-spec standard RFC5575 [2] in one or more BGP extended communities). The flow-spec standard
defines widely-used filter actions such as discard and rate limit; it RFC5575 [2] defines widely-used filter actions such as discard and
also defines a redirect-to-VRF action for policy-based forwarding. rate limit; it also defines a redirect-to-VRF action for policy-based
Using the redirect-to-VRF action for redirecting traffic towards an forwarding. Using the redirect-to-VRF action to steer traffic
alternate destination is useful for DDoS mitigation but using this towards an alternate destination is useful for DDoS mitigation but
technology can be cumbersome when there is need to redirect the using this technology can be cumbersome when there is need to steer
traffic onto an engineered traffic path. the traffic onto an engineered traffic path.
This draft proposes a new redirect-to-Indirection-id flow-spec action This draft proposes a new redirect-to-indirection-id flowspec action
facilitating an anchor point for policy-based forwarding onto an facilitating an anchor point for policy-based forwarding onto an
engineered path or into a service plane. The router consuming and engineered path or into a service plane. The flowspec client
utilizing the flowspec rule makes a local mapping between the consuming and utilizing the new flowspec indirection-id extended-
flowspec signalled redirect Indirection-id and locally available community finds the redirection information within a localised
redirection information referenced by the Indirection-id. This indirection-id mapping table. The localised mapping table is a table
locally available redirection information is derived from out-of-band construct providing at one side the table key and at the other side
programming or signalling. next-hop information. The table key consists out the combination of
indirection-id type and indirection-id 32-bit value.
The redirect-to-Indirection-id is encoded in a newly defined BGP The redirect-to-indirection-id flowspec action is encoded in a newly
extended Indirection_ID community. defined BGP extended community. In addition, the type of redirection
can be configured as an extended community indirection-id type field.
The construction of the Indirection-id redirect table and the This draft defines the indirection-id extended-community and the
technology used to create an engineered path are out-of-scope of this wellknown indirection-id types. The specific solution to construct
the localised indirection-id mapping table are out-of-scope of this
document. document.
2. INDIRECTION_ID and INDIRECTION_ID Table 2. indirection-id and indirection-id table
An INDIRECTION_ID is an abstract number (32-bit or 128-bit value) An indirection-id is an abstract number (32-bit value) used as
used as identifier for a localised redirection decision. e.g. When a identifier for a localised indirection decision. The indirection-id
BGP flowspec controller intends to redirect a flow using te redirect- will allow a flowspec client to redirect traffic into a service plane
to-INDIRECTION_ID action then it has the ability to redirect the flow or onto an engineered traffic path. e.g. When a BGP flowspec
to a destination abstracted as the INDIRECTION_ID. The device controller signals a flowspec client the indirection-id extended
receiving the BGP flowspec rule will use the INDIRECTION_ID to community, then the flowspec client uses the indirection-id to make a
identify the next-hop and the relevant tunnel encapsulations that recursive lookup to retrieve next-hop information found in a
need to be pushed by a localised recursive lookup using information localised indirection mapping table.
located within the INDIRECTION_ID table.
The INDIRECTION_ID Table is a router localised table. The table The indirection-id table is a router localised table. The
content is constructed out of INDIRECTION_IDs and corresponding indirection-id table is constructed out of table keys mapped to
redirect information which may be of rescursive or non-recursive flowspec client localised redirection information. The table key is
nature. When the redirect information is non-recursive, then the created by the combination of the indirection-id type and the
represented information MUST be sufficient to identify the local indirection-id 32-bit value. Each entry in the indirection-table key
egress interface and the corresponding required encapsulations. maps to sufficient information (parameters regarding encapsulation,
However, if the information is recursive, then the represented interface, QoS, etc...) to successfully redirect traffic.
information MUST be sufficient to identify the local egress interface
and corresponding encapsulations using additional recursions.
3. Use Case Scenarios 3. Use Case Scenarios
This section describes use-case scenarios when deploying redirect-to- This section describes use-case scenarios when deploying redirect-to-
INDIRECTION_ID. indirection-id.
3.1. Redirection shortest Path tunnel 3.1. Redirection shortest Path tunnel
A first use-case is allowing a BGP Flowspec controller send a single A first use-case is allowing a BGP Flowspec controller to send a
flowspec policy message (redirect-to-INDIRECTION_ID#1) to many BGP single flowspec policy route (i.e. flowspec_route#1) to many BGP
flowspec consuming routers. This message is instructing the Flowspec flowspec clients. This flowspec route signals the Flowspec clients
recipient routers to redirect traffic onto a tunnel to a single IP to redirect traffic onto a tunnel towards a single IP destination
destination address. address.
For this use-case scenario, each flowspec recipient router has a For this first use-case scenario, the flowspec client receives from
tunnel configured following the shortest path towards a tunnel IP the flowspec controller a flowspec route (i.e. flowspec_route#1)
destination address. Each tunnel can have its own unique including the redirect-to-indirection-id extended community. The
encapsulation associated. Each tunnel is associated with an redirect-to-indirection-id extended community contains the key
INDIRECTION_ID, and for this example it is on all recipient routers (indirection-id type + indirection-id 32-bit value) to select the
INDIRECTION_ID#1. Both manual and orchestrated tunnel provisioning corresponding next-hop information from the flowpsec client localised
is supported, however for large scale deployment automation is indirection-id table. The resulting next-hop information for this
advisable. use-case is a remote tunnel end-point IP address with accordingly
sufficient tunnel encapsulation information to forward the packet
accordingly.
When using this setup, a BGP flowspec controller can send a single For redirect to shortest path tunnel it is required that the tunnel
BGP Flowspec NLRI with redirect-to-INDIRECTION_ID#1. This BGP MUST be operational and allow packets to be exchanged between tunnel
Flowspec NLRI is received by all recipient routers. Each of the head- and tail-end.
recipient routers performs a locallised recursive lookup for
INDIRECTION_ID#1 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 tunnel, each potentially using
its own unique tunnel encapsulation.
3.2. Redirection to path-engineered tunnels 3.2. Redirection to path-engineered tunnels
A second use-case is allowing a BGP Flowspec controller send a single For a second use-case, it is expected that the flowspec client
flowspec policy message (redirect-to-INDIRECTION_ID#2) to many BGP redirect traffic matches the flowspec rule, onto a path engineered
flowspec consuming routers. This message is instructing the Flowspec tunnel. The path engineered tunnel on the flowspec client SHOULD be
recipient routers to redirect traffic onto a path engineered tunnel. created by out-of-band mechanisms. Each path engineered tunnel
deployed for flowspec redirection, has a unque key as an identifier.
For this use-case scenario, each flowspec recipient router has a path consequently, the key (=indirection-id type and indirection-id 32-bit
engineered tunnel configured. Each tunnel can have its own unique value) uniquely identifies a single path engineered tunnel on the
encapsulation and engineered path associated. Each tunnel is flowspec client. The localised indirection-id mapping table is the
associated with an INDIRECTION_ID, and for this example it is on all collection of all keys corresponding all path engineered tunnels on
recipient routers INDIRECTION_ID#2. Both manual and orchestrated the flowspec client.
tunnel provisioning is supported, however for large scale deployment
automation is advisable.
A first example using this setup, is when a BGP flowspec controller For this second use-case scenario, the flowspec controller sends a
sends a single BGP Flowspec NLRI with redirect-to-INDIRECTION_ID#2. flowspec route (i.e. flowspec_route#2) to the flowspec clients. The
This BGP Flowspec NLRI is received by all recipient routers. Each of flowspec clients, respectively receive the flowspec route. The
the recipient routers performs a locallised recursive lookup for redirect-to-indirection-id extended community contains the key
INDIRECTION_ID#2 in the INDIRECTION_ID Table and identifies the (indirection type + indirection-id 32-bit value) to select the
corresponding locallised tunnel redirect information. This corresponding next-hop information from the flowpsec client localised
locallised tunnel information is now used to redirect traffic indirection-id table. The resulting next-hop information for this
matching the Flowspec policy towards a path engineered tunnel. use-case is path engineered tunnel information and has sufficient
tunnel encapsulation information to forward the packet according the
expectations of the flowspec controller.
A second example can be found in segment routed networks where path A concrete example of this use-case can be found in segment routed
engineered tunnels can be setup by means of a controller signaling networks where path engineered tunnels can be setup by means of a
explicit paths to peering routers. In such a case, the controller signaling explicit paths to peering routers. In such a
INDIRECTION_ID references to a Segment Routing Binding SID. The case, the indirection-id references to a Segment Routing Binding SID,
Binding SID is a segment identifier value (as per segment routing while the indirection-id type references the Bindging SID semantic.
The Binding SID is a segment identifier value (as per segment routing
definitions in [I-D.draft-ietf-spring-segment-routing] [6]) used to 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 associate with an explicit path and can be setup by a controller
BGP as specified in [I-D.sreekantiah-idr-segment-routing-te] [5] or using BGP as specified in [I-D.sreekantiah-idr-segment-routing-te]
using PCE as detailed in draft-ietf-pce-segment-routing [7]. When a [5] or using PCE as detailed in draft-ietf-pce-segment-routing [7].
BGP speaker receives a flow-spec route with a 'redirect to Binding When a BGP speaker receives a flow-spec route with a 'redirect to
SID' extended community, it installs a traffic filtering rule that Binding SID' extended community, it installs a traffic filtering rule
matches the packets described by the NLRI field and redirects them to that matches the packets described by the NLRI field and redirects
the explicit path associated with the Binding SID. The explicit path them to the explicit path associated with the Binding SID. The
is specified as a set/stack of segment identifiers as detailed in the explicit path is specified as a set/stack of segment identifiers as
previous documents. The stack of segment identifiers is now imposed detailed in the previous documents. The stack of segment identifiers
on packets matching the flow-spec rule to perform redirection as per is now imposed on packets matching the flow-spec rule to perform
the explicit path setup prior. The encoding of the Binding SID value redirection as per the explicit path setup prior. The encoding of
is specified in section 4, with the indirection field now encoding the Binding SID value is specified in section 4, with the
the associated value for the binding SID. indirection-id field now encoding the associated value for the
binding SID.
3.3. Redirection to Next-next-hop tunnels 3.3. Redirection to Next-next-hop tunnels
A Third use-case is allowing a BGP Flowspec controller send a single A Third use-case is when a BGP Flowspec controller sends a single
flowspec policy message (redirect-to-INDIRECTION_ID#3) to many BGP flowspec policy route to flowpsec clients to signal redirection
flowspec consuming routers. This message is instructing the Flowspec towards next-next-hop tunnels. In this use-case The flowspec rule is
recipient routers to redirect traffic onto a shortest or engineered instructing the Flowspec client to redirect traffic using a sequence
path to a tunnel end-point and onwards to the next-hop-interface on of indirection-id extended communities. The sequence of indirection-
this end-point. This type of tunnel is used for example for Segment ids is managed using Tunnel IDs (TID). i.e. a classic example would
Routing Central Egress Path Engineering [4]. be DDoS mitigation towards Segment Routing Central Egress Path
Engineering [4]. To steer DDoS traffic towards egress peer
engineering paths, a first indirection-id will steer traffic onto a
tunnel to an egress router, while a second indirection-id is used
steer the traffic at this egress router onto a particular interface
or towards a peer. The flowspec client will for this use-case
dynamically append all segment routing segments to steer the DDoS
traffic through the EPE path.
For this use-case scenario, each flowspec recipient router constructs To achieve this type of redirection to next-next-hop tunnels,
redirect information using two tunnel components. The first multiple indirection-ids, each using a unique Tunnel ID are imposed
component is a shortest or engineered path towards a network egress upon a the flowspec policy rule. The Tunnel ID will allow the
router. The second component is the interface used on this network flowspec client to sequence the indirection-ids for correct next-
egress router to which the redirected traffic needs to be steered next-hop tunnel constructs.
upon. The combination of these two components allows steering
towards the next-hop of the egress router, allowing for example the
Central Egress Path Engineering using BGP Flowspec [4].
The redirection towards a next-next-hop tunnel can be done by using 4. Redirect to indirection-id Community
either a single INDIRECTION_ID representing the combined path to the
egress router and steering the traffic to the egress interface, or by
using individual INDIRECTION_IDs each representing a tunnel component
(One INDIRECTION_ID value to identify the path towards the egress
router and another INDIRECTION_ID value to identify the egress
interface on this egress router towards the next-next-hop). When
using individual INDIRECTION_IDs it is required to use INDIRECTION_ID
community Tunnel IDs (TID) each identifying a component of the
complete redirect path attached to the NLRI.
i.e. when using next-next-hop tunnels, a BGP flowspec controller can This document defines a new BGP extended community known as a
send a single BGP Flowspec NLRI with redirect-to-INDIRECTION_ID#3. Redirect-to-indirection-id extended community. This extended
This BGP Flowspec NLRI is received by all recipient routers. Each of community is a new transitive extended community with the Type and
the recipient routers performs a locallised recursive lookup for the Sub-Type field to be assigned by IANA. The format of this
INDIRECTION_ID#3 in the INDIRECTION_ID Table and identifies the extended community is show in Figure 1.
corresponding locallised tunnel redirect information (=path to the
egress router and the next-hop egress interface on this router).
Traffic matching the flowspec policy is redirected towards the
recursively found redirection information.
4. Redirect to INDIRECTION-ID Communities 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 | Sub-Type | Flags(1 octet)| Indirection ID|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generalized indirection_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document defines a new BGP extended community. The extended Figure 1
communities have a type indicating they are transitive and IPv4-
address-specific or IPv6-address-specific, depending on whether the
INDIRECTION_ID is 32-bit or 128-bit. The sub-type value [to be
assigned by IANA] indicates that the global administrator and local
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 The meaning of the extended community fields are as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |B|TID|C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Type: 1 octet to be assigned by IANA.
In the local administrator field the least-significant bit is defined Sub-Type: 1 octet to be assigned by IANA.
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 Flags: 1 octet field. Following Flags are defined.
used to provide the router consuming the flowspec rule an indication
how and where to use the INDIRECTION_ID when redirecting traffic.
Bit 2 is defined to be the 'B' (Binding) bit. When the 'B' bit is 0 1
set, the value encoded in the global administrator field is a Binding 0 1 2 3 4 5 6 7
Segment Identifier value the use of which is detailed in section 3.2. +-+-+-+-+-+-+-+-+
| RES | TID |C|
+-+-+-+-+-+-+-+-+
All bits other than the 'C', 'TID' and 'B' bits in the local Figure 2
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 The least-significant Flag 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.
When a BGP speaker receives a flow-spec route with a 'redirect to The 'TID' field identifies a 4 bit Table-id field. This field is
INDIRECTION_ID' extended community and this route represents the one used to provide the flowspec client an indication how and where to
and only best path, it installs a traffic filtering rule that matches sequence the received indirection-ids to redirecting traffic. TID
the packets described by the NLRI field and redirects them (C=0) or value 0 indicates that Table-id field is NOT set and SHOULD be
copies them (C=1) towards the INDIRECTION_ID local recursed Path. ignored.
The BGP speaker is expected to do a local INDIRECTION_ID Table lookup
to identify the redirection information.
The router local INDIRECTION_ID table contains a list of All bits other than the 'C' and 'TID' bits MUST be set to 0 by the
INDIRECTION_ID's each mapped to redirect information. The redirect originating BGP speaker and ignored by receiving BGP speakers.
information can be non-recursive (i.e. there is only one option
available in the INDIRECTION_ID Table) or recursive (i.e. L3 VPN, L2
VPN, a pre-programmed routing topology, etc... ).
o When the redirect information is non-recursive then the packet is Indirection ID: 1 octet value. This draft defines following
redirected based upon the information found in the Table. indirection_id Types:
o In case of a next-hop tunnel, the traffic matching the flowspec 0 - Localised ID
rule is redirected to the next-hop tunnel. This tunnel could be
instantiated through various means (i.e. manual configuration,
PCEP, RSVP-TE, WAN Controller, Segment Routing, etc...).
o In case of redirection to a local next-hop interface, the traffic 1 - Node ID
matching the flowspec rule is redirected to the local next-hop
interface.
o In case the INDIRECTION_ID Table lookup results in redirect 2 - Agency ID
information identifying an additional layer of recursion, then
this will trigger the flow to be redirected based upon an 3 - AS (Autonomous System) ID
additional routing lookup within the realm of the additional layer
of recursion. 4 - Anycast ID
5 - Multicast ID
6 - Tunnel ID (Tunnel Binding ID )
7 - VPN ID
8 - OAM ID
9 - ECMP (Equal Cost Multi-Path) ID
10 - QoS ID
11 - Bandwidth-Guarantee ID
12 - Security ID
13 - Multi-Topology ID
5. Redirect using localised indirection-id mapping table
When a BGP speaker receives a flowspec policy route with a 'redirect
to indirection-id' extended community and this route represents the
one and only best path or an equal cost multipath, 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. To construct the local recursed
path, the flowspec client does a local indirection-id mapping table
lookup using the key comprised of the indirection-id 32-bit value and
indirection-id type to retrieve the correct redirection information.
6. Validation Procedures 6. Validation Procedures
The validation check described in RFC5575 [2] and revised in [3] The validation check described in RFC5575 [2] and revised in [3]
SHOULD be applied by default to received flow-spec routes with a SHOULD be applied by default to received flow-spec routes with a
'redirect to INDIRECTION_ID' extended community. This means that a 'redirect to indirection-id' extended community. This means that a
flow-spec route with a destination prefix subcomponent SHOULD NOT be flow-spec route with a destination prefix subcomponent SHOULD NOT be
accepted from an EBGP peer unless that peer also advertised the best accepted from an EBGP peer unless that peer also advertised the best
path for the matching unicast route. path for the matching unicast route.
It is possible from a semenatics perspective to have multiple It is possible from a semenatics perspective to have multiple
redirect actions defined within a single flowspec rule. When a BGP redirect actions defined within a single flowspec rule. When a BGP
flowspec NLRI has a 'redirect to INDIRECTION_ID' extended community flowspec NLRI has a 'redirect to indirection-id' extended community
attached resulting in valid redirection then it MUST take priority attached resulting in valid redirection then it MUST take priority
above all other redirect actions emposed. However, if the 'redirect above all other redirect actions emposed. However, if the 'redirect
to INDIRECTION_ID' does not result in a valid redirection, then the to indirection-id' does not result in a valid redirection, then the
flowspec rule must be processed as if the 'redirect to flowspec rule must be processed as if the 'redirect to indirection-
INDIRECTION_ID' community was not attached to the flowspec route and id' community was not attached to the flowspec route and MUST provide
MUST provide an indication within the BGP routing table that the an indication within the BGP routing table that the respective
'redirect to INDIRECTION_ID' resulted in an invalid redirection 'redirect to indirection-id' resulted in an invalid redirection
action. action.
7. Security Considerations 7. Security Considerations
A system using 'redirect-to-INDIRECTION_ID' extended community can A system using 'redirect-to-indirection-id' extended community can
cause during the redirect mitigation of a DDoS attack result in an cause during the redirect mitigation of a DDoS attack result in
overflow of traffic being received by the mitigation infrastructure. overflow of traffic received by the mitigation infrastructure.
8. Acknowledgements 8. Acknowledgements
This document received valuable comments and input from IDR working This document received valuable comments and input from IDR working
group including Adam Simpson, Mustapha Aissaoui, Jan Mertens, Robert group including Adam Simpson, Mustapha Aissaoui, Jan Mertens, Robert
Raszuk, Jeff Haas, Susan Hares and Lucy Yong Raszuk, Jeff Haas, Susan Hares and Lucy Yong
9. IANA Considerations 9. IANA Considerations
This document requests a new sub-type from the "Transitive IPv4- This document requests a new type and sub-type for the Redirect to
Address-Specific" extended community registry. The sub-type name indirection-id Extended community from the "Transitive Extended
shall be 'Flow-spec Redirect to 32-bit Path-id'. community" registry. The Type name shall be "Redirect to
indirection-id Extended Community" and the Sub-type name shall be
'Flow-spec Redirect to 32-bit Path-id'.
This document requests a new sub-type from the "Transitive IPv6- In addition, this document requests IANA to create a new registry for
Address-Specific" extended community registry. The sub-type name Redirect to indirection-id Extended Community INDIRECTION-IDs as
shall be 'Flow-spec Redirect to 128-bit Path-id'. follows:
Under "Transitive Extended Community:"
Registry: "Redirect Extended Community indirection_id"
Reference: [RFC-To-Be]
Registration Procedure(s): First Come, First Served
Registry: "Redirect Extended Community indirection_id"
Value Code Reference
0 Localised ID [RFC-To-Be]
1 Node ID [RFC-To-Be]
2 Agency ID [RFC-To-Be]
3 AS (Autonomous System) ID [RFC-To-Be]
4 Anycast ID [RFC-To-Be]
5 Multicast ID [RFC-To-Be]
6 Tunnel ID (Tunnel Binding ID ) [RFC-To-Be]
7 VPN ID [RFC-To-Be]
8 OAM ID [RFC-To-Be]
9 ECMP (Equal Cost Multi-Path) ID [RFC-To-Be]
10 QoS ID [RFC-To-Be]
11 Bandwidth-Guarantee ID [RFC-To-Be]
12 Security ID [RFC-To-Be]
13 Multi-Topology ID [RFC-To-Be]
Figure 3
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate [1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997, Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://xml.resource.org/public/rfc/html/rfc2119.html>. <http://xml.resource.org/public/rfc/html/rfc2119.html>.
[2] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., [2] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification and D. McPherson, "Dissemination of Flow Specification
skipping to change at page 9, line 42 skipping to change at page 10, line 42
"Segment Routing Architecture", December 2015. "Segment Routing Architecture", December 2015.
[7] Sivabalan, S., Medved, M., Filsfils, C., Litkowski, S., [7] Sivabalan, S., Medved, M., Filsfils, C., Litkowski, S.,
Raszuk, R., Bashandy, A., Lopez, V., Tantsura, J., Raszuk, R., Bashandy, A., Lopez, V., Tantsura, J.,
Henderickx, W., Hardwick, J., Milojevic, I., and S. Ytti, Henderickx, W., Hardwick, J., Milojevic, I., and S. Ytti,
"PCEP Extensions for Segment Routing", December 2015. "PCEP Extensions for Segment Routing", December 2015.
Authors' Addresses Authors' Addresses
Gunter Van de Velde (editor) Gunter Van de Velde (editor)
Alcatel-Lucent Nokia
Antwerp Antwerp
BE BE
Email: gunter.van_de_velde@alcatel-lucent.com Email: gunter.van_de_velde@nokia.com
Wim Henderickx Wim Henderickx
Alcatel-Lucent Nokia
Antwerp Antwerp
BE BE
Email: wim.henderickx@alcatel-lucent.com Email: wim.henderickx@nokia.com
Keyur Patel Keyur Patel
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: keyupate@cisco.com Email: keyupate@cisco.com
Arjun Sreekantiah Arjun Sreekantiah
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: asreekan@cisco.com Email: asreekan@cisco.com
Zhenbin Li
Huawei Technologies
Huawei Bld., No. 156 Beiquing Rd
Beijing 100095
China
Email: lizhenbin@huawei.com
Shunwan Zhuang
Huawei Technologies
Huawei Bld., No. 156 Beiquing Rd
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Nan Wu
Huawei Technologies
Huawei Bld., No. 156 Beiquing Rd
Beijing 100095
China
Email: eric.wu@huawei.com
 End of changes. 58 change blocks. 
239 lines changed or deleted 275 lines changed or added

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