draft-ietf-idr-flowspec-path-redirect-00.txt   draft-ietf-idr-flowspec-path-redirect-01.txt 
IDR Working Group G. Van de Velde, Ed. IDR Working Group G. Van de Velde, Ed.
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Standards Track K. Patel Intended status: Standards Track K. Patel
Expires: March 3, 2017 Cisco Systems Expires: September 3, 2017 Arrcus
Z. Li Z. Li
Huawei Technologies Huawei Technologies
August 30, 2016 March 2, 2017
Flowspec Indirection-id Redirect Flowspec Indirection-id Redirect
draft-ietf-idr-flowspec-path-redirect-00 draft-ietf-idr-flowspec-path-redirect-01
Abstract Abstract
Flowspec 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,
particularly if the redirected traffic needs to be steered into an particularly if the redirected traffic needs to be steered into an
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 March 3, 2017. This Internet-Draft will expire on September 3, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . 5 3.2. Redirection to path-engineered tunnels . . . . . . . . . 5
3.3. Redirection to Next-next-hop tunnels . . . . . . . . . . 6 3.3. Redirection to complex dynamically constructed tunnels . 6
4. Redirect to indirection-id Community . . . . . . . . . . . . 7 4. Redirect to indirection-id Community . . . . . . . . . . . . 7
5. Redirect using localised indirection-id mapping table . . . . 9 5. Redirect using localised indirection-id mapping table . . . . 8
6. Validation Procedures . . . . . . . . . . . . . . . . . . . . 9 6. Validation Procedures . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 10 9. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Additional indirection_id types waiting for use-case
description . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Flowspec 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, however the primary one for many network possible applications, however the primary one for many network
operators is the distribution of traffic filtering actions for DDoS operators is the distribution of traffic filtering actions for DDoS
mitigation. mitigation.
skipping to change at page 3, line 27 skipping to change at page 3, line 27
rate limit; it also defines a redirect-to-VRF action for policy-based rate limit; it also defines a redirect-to-VRF action for policy-based
forwarding. Using the redirect-to-VRF action to steer traffic forwarding. Using the redirect-to-VRF action to steer traffic
towards an alternate destination is useful for DDoS mitigation but towards an alternate destination is useful for DDoS mitigation but
using this technology can be cumbersome when there is need to steer using this technology can be cumbersome when there is need to steer
the traffic onto an engineered traffic path. the traffic onto an engineered traffic path.
This draft proposes a new redirect-to-indirection-id flowspec 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 flowspec client engineered path or into a service plane. The flowspec client
consuming and utilizing the new flowspec indirection-id extended- consuming and utilizing the new flowspec indirection-id extended-
community finds the redirection information within a localised community constructs the redirection information based upon
indirection-id mapping table. The localised mapping table is a table information found within a localised indirection-id mapping table.
construct providing at one side the table key and at the other side The localised mapping table is a table construct, sequenced by a
next-hop information. The table key consists out the combination of table key, providing next-hop information.
indirection-id type and indirection-id 32-bit value.
The redirect-to-indirection-id flowspec action is encoded in a newly The redirect-to-indirection-id flowspec action is encoded in a newly
defined BGP extended community. In addition, the type of redirection defined BGP extended community. The type of redirection is
can be configured as an extended community indirection-id type field. identified as an extended community indirection-id type field.
This draft defines the indirection-id extended-community and the This draft defines the indirection-id extended-community and a few
wellknown indirection-id types. The specific solution to construct wellknown indirection-id types. The specific mechanics to construct
the localised indirection-id mapping table are out-of-scope of this a 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 value) used as An indirection-id is an abstract number (32-bit value) used as
identifier for a localised indirection decision. The indirection-id identifier for a localised indirection decision. The indirection-id
will allow a flowspec client to redirect traffic into a service plane will allow a flowspec client to redirect traffic into a service plane
or onto an engineered traffic path. For example, when a BGP flowspec or consequently onto an engineered traffic path. For example, when a
controller signals a flowspec client the indirection-id extended BGP flowspec controller signals a flowspec client the indirection-id
community, then the flowspec client uses the indirection-id to make a extended community, then the flowspec client uses the indirection-id
recursive lookup to retrieve next-hop information found in a to make a recursive lookup to find the next-hop information. The
localised indirection mapping table. indirection-id is used to find the corresponding next-hop information
within the localised indirection mapping table.
The indirection-id table is a router localised table. The The indirection-id table is localised on the router. The
indirection-id table is constructed out of table keys mapped to indirection-id table is constructed out of table keys, each mapped to
flowspec client localised redirection information. The table key is localised redirection information. Each table key is composed by the
created by the combination of the indirection-id type and the combining indirection-id type and an indirection-id 32-bit value.
indirection-id 32-bit value. Each entry in the indirection-table key Each entry in the indirection-table key maps to sufficient
maps to sufficient information (parameters regarding encapsulation, information (parameters regarding encapsulation, egress-interface,
interface, QoS, etc...) to successfully redirect traffic. QoS, etc...) to successfully redirect traffic according flowspec
controller expectations.
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
Possible Indirection-ID type examples: Example: Indirection-ID community types to be used:
o When deploying on flowspec client a localised Indirection-id o 0 (localised ID): When the intent is to use a localised
table: 0 (localised ID) Indirection-id table on the flowspec client
o When deploying on flowspec client a Segment Routing based o 1 (Node ID): When the intent is to use a Segment Routing based
Indirection-id table: 1 (Node ID) Indirection-id table on the flowspec client
Description: Description:
A first use-case is allowing a BGP Flowspec controller to send a The first use-case describes an example where a single flowspec route
single flowspec policy route (i.e. flowspec_route#1) to many BGP (i.e. flowspec_route#1) is sent by a flowspec controller to many BGP
flowspec clients. This flowspec route signals the Flowspec clients flowspec clients. This single flowspec route will instruct all
to redirect traffic onto a tunnel towards a single IP destination Flowspec clients to redirect matching dataflows onto a shortest-path
address. tunnel pointing towards a single IP destination address.
For this first use-case scenario, the flowspec client receives from For this first use-case scenario, each flowspec client receives a
the flowspec controller a flowspec route (i.e. flowspec_route#1) flowspec route (flowspec_route#1) which has the redirect-to-
including the redirect-to-indirection-id extended community. The indirection-id extended community attached. The extended redirect-
redirect-to-indirection-id extended community contains the key to-indirection-id community contains the table key consisting out of
(indirection-id type + indirection-id 32-bit value) to select the the indirection-id type and indirection-id 32-bit value. The table
corresponding next-hop information from the flowpsec client localised key is used on the flowspec client to map to the corresponding next-
indirection-id table. The resulting next-hop information for this hop information within the local indirection-id table. The finite
use-case is a remote tunnel end-point IP address with accordingly result of this operation is a remote tunnel end-point IP address
sufficient tunnel encapsulation information to forward the packet together with accordingly sufficient tunnel encapsulation information
accordingly. to forward and encapsulate the data-packet accordingly.
Requirements: Requirements:
For redirect to shortest path tunnel it is required that the tunnel For redirect to shortest path tunnel it is required that the tunnel
MUST be operational and allow packets to be exchanged between tunnel MUST be operational and allow packets to be exchanged between tunnel
head- and tail-end. head- and tail-end.
3.2. Redirection to path-engineered tunnels 3.2. Redirection to path-engineered tunnels
Possible Indirection-ID type examples: Example: Indirection-ID community types to be used:
o When deploying on flowspec client a localised Indirection-id o 0 (localised ID): When the intent is to use a localised
table: 0 (localised ID) Indirection-id table on the flowspec client
o When deploying on flowspec client a Segment Routing based o 6 (Binding Segment ID): When the intent is to use a Segment
Indirection-id table: 6 (Binding Segment ID) Routing based Indirection-id table on the flowspec client
Description: Description:
For a second use-case, it is expected that the flowspec client The second use-case describes an example where a flowspec controler
redirect traffic matches the flowspec rule, onto a path engineered injects a single flowspec route which gets distributed to many BGP
tunnel. The path engineered tunnel on the flowspec client SHOULD be flowspec clients. This single flowspec route intends to instruct all
created by out-of-band mechanisms. Each path engineered tunnel Flowspec clients to redirect corresponding dataflows onto a path
deployed for flowspec redirection, has a unque key as an identifier. engineered tunnel. It is expected that each of the path engineered
consequently, the key (=indirection-id type and indirection-id 32-bit tunnels is instantiated by out-of-band mechanisms. Each used path
value) uniquely identifies a single path engineered tunnel on the engineered tunnel has a unque table key identifier. consequently, the
flowspec client. The localised indirection-id mapping table is the table key uniquely identifies exactly -one- path engineered tunnel.
collection of all keys corresponding all path engineered tunnels on
the flowspec client.
For this second use-case scenario, the flowspec controller sends a In this use-case example, the flowspec controller sends a flowspec
flowspec route (i.e. flowspec_route#2) to some flowspec clients. The route to each of the flowspec clients and this flowspec route has a
flowspec clients, respectively receive the flowspec route. The redirect-to-indirection-id extended community attached. The
redirect-to-indirection-id extended community contains sufficient redirect-to-indirection-id extended community embeds table key
information for the flowspec clients to select the corresponding information and hence provides sufficient information to select the
path-engineered tunnel and consequently provides sufficient tunnel corresponding path-engineered tunnel to redirect the packet according
encapsulation information to redirect the packet according the the flowspec controller expectations.
flowspec controller expectations.
Segment Routing Example: Segment Routing Example:
A concrete Segment Routing use-case example of this use-case can be A concrete embodiment of a Segment Routing use-case example is found
found in segment routed networks where path engineered tunnels can be in networks where path engineered tunnels are created by a Segment
setup by means of a controller signaling explicit paths to peering Routing MPLS label stack. In such a deployment, the indirection-id
routers. In such a case, the indirection-id references to a Segment provides an anchorpoint reference to a Segment Routing Binding SID.
Routing Binding SID, while the indirection-id type references the However, the indirection-id type provides a pointer to the Binding
Bindging SID semantic. The Binding SID is a segment identifier value SID semantics to be used. The Binding SID is a segment identifier
(as per segment routing definitions in [I-D.draft-ietf-spring- value (as per segment routing definitions in [I-D.draft-ietf-spring-
segment-routing] [6]) used to associate with an explicit path and can segment-routing] [6]) used to associate an explicit path. The
Binding SID and corresponding path engineered tunnel can for example
be setup by a controller using BGP as specified in [I-D.sreekantiah- 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- idr-segment-routing-te] [5] or by using PCEP as detailed in draft-
pce-segment-routing [7]. When a BGP speaker receives a flow-spec ietf-pce-segment-routing [7]. To conclude, when a BGP speaker at
route with a 'redirect to Binding SID' extended community, it some point in time receives a flow-spec route with an extended
installs a traffic filtering rule that matches the packets described 'redirect-to-indirection-id' community, it installs a traffic
by the NLRI field and redirects them to the explicit path associated filtering rule that matches particular packets and redirects them
with the Binding SID. The explicit path is specified as a set/stack onto an explicit path associated with the corresponding Binding SID.
of segment identifiers as detailed in the previous documents. The
stack of segment identifiers is now imposed on packets matching the The encoding of the Binding SID within the redirect-to-indirection-id
flow-spec rule to perform redirection as per the explicit path setup extended community is specified in section 4.
prior. The encoding of the Binding SID value is specified in section
4, with the indirection-id field now encoding the associated value
for the binding SID.
Requirements: Requirements:
For redirect to path engineered tunnels it is required that the For redirect to path engineered tunnels it is required that the
engineered tunnel MUST be operational and allow packets to be engineered tunnel MUST be active and allow packets to be exchanged
exchanged between tunnel head- and tail-end. between tunnel head- and tail-end.
3.3. Redirection to Next-next-hop tunnels 3.3. Redirection to complex dynamically constructed tunnels
Possible Indirection-ID type examples: Example: Indirection-ID community types to be used:
o When deploying on flowspec client using a localised Indirection-id o 0 (localised ID) with TID: When the intent is to use a localised
table the TID (Table ID) is used: one indirection-id community of Indirection-id table, then TID (Table-ID) field could be used to
type 0 (localised ID) with TID=0 and second indirection-id sequence multiple redirect-to-indirection-id actions together to
community of type 0 with TID=1 construct a more complex path engineered tunnel. The order of
sequencing the redirection information may be identified by using
the TID field.
Description: Description:
A Third use-case is when a BGP Flowspec controller sends a single A third use-case describes the application and redirection towards
flowspec policy route to flowspec clients to signal redirection complex dynamically constructed tunnels. For this use-case a BGP
towards next-next-hop tunnels. In this use-case The flowspec rule is flowspec controller injects a flowspec route with multiple 'redirect-
instructing the Flowspec client to redirect traffic using a sequence to-indirection-id' communities attached. A recipient flowspec client
of indirection-id extended communities. The sequence of indirection- may use the Table-ID (TID) field embedded within each 'redirect-to-
ids is managed using Tunnel IDs (TID). indirection-id' community to sequence the redirect information. The
complex dynamically constructed tunnel is the product of
concatenating the available redirect information (i.e. MPLS Segment
Routing Labels).
Segment Routing Example: Segment Routing Example:
i.e. a classic Segment Routing example would be DDoS mitigation i.e. a classic Segment Routing example using complex tunnels is found
towards a Segment Routing Central Egress Path Engineered tunnel [4]. in DDoS mitigation and traffic offload. Suspicious traffic (e.g.
To steer DDoS traffic towards egress peer engineering paths, a first dirty traffic flows) may be steered into a Segment Routing Central
indirection-id (i.e. TID=0) will steer traffic onto a tunnel to an Egress Path Engineered tunnel [4]. For this particular complex
egress router, while the second indirection-id (TID=1) is used steer dynamic redirect tunnel embodiment, a first redirect-to-indirection-
the egress router arrived traffic onto a pre-identified interface/ id (i.e. TID=0) is used to redirect traffic into a tunnel towards a
peer. The flowspec client will for this use-case in the simpliest particlar egress router, while a second redirect-to-indirection-id
implementation dynamically append 2 MPLS labels. A first MPLS label (i.e. TID=1) is used to steer traffic beyond the particular egress
(the outer label) is used to steer the original packet to the egress router towards a pre-identified interface/peer.
node, while the next MPLS label (the inner label, corresponding with
the indirection-id identified with TID=1) instructs the egress router For this DDoS use-case, in its simplest embodiment, the flowspec
to steer the original packet to a pre-defined interface/peer client must dynamically append 2 MPLS labels. A first MPLS label
corresponding principles documented by [4]. (the outer label) to steer the original packet to the egress node
(and hence using a shortest path tunnel), while a second MPLS label
(matching redirect-to-indirection-id with TID=1), the inner label, to
steer on the egress router the original packet to a pre-defined
interface/peer. The basic data-plane principles are documented by
[4].
Requirements: Requirements:
To achieve this type of redirection to next-next-hop tunnels, for To achieve redirection towards complex dynamically constructed
each flowspec route, multiple indirection-ids, each using a unique tunnels, for each flowspec route, multiple indirection-ids, each
Tunnel ID are imposed upon a the flowspec policy rule. It is using a unique Tunnel ID may imposed upon a given flowspec policy
required that there is synchronisation between the labels used by the rule. It is required that there is synchronisation established
Egress Peer Engineering egress router and the flowspec client between the data- and control-plane of all relevant devices involved.
originally imposing the sequens of EPE Segment Routing segments. It Each complex dynamically constructed tunnel MUST be operational and
is required that the the engineered next-next-hop tunnel MUST be allow packets to be exchanged between tunnel head- and tail-end
operational and allow packets to be exchanged between tunnel head- before it should be used to redirect traffic.
and tail-end.
4. Redirect to indirection-id Community 4. Redirect to indirection-id Community
This document defines a new BGP extended community known as a This document defines a new BGP extended community known as a
Redirect-to-indirection-id extended community. This extended Redirect-to-indirection-id extended community. This extended
community is a new transitive extended community with the Type and community is a new transitive extended community with the Type and
the Sub-Type field to be assigned by IANA. The format of this the Sub-Type field to be assigned by IANA. The format of this
extended community is show in Figure 1. extended community is show in Figure 1.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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
skipping to change at page 8, line 36 skipping to change at page 8, line 36
Indirection ID: 1 octet value. This draft defines following Indirection ID: 1 octet value. This draft defines following
indirection_id Types: indirection_id Types:
0 - Localised ID (The flowspec client uses the received 0 - Localised ID (The flowspec client uses the received
indirection-id to lookup the redirection information in the indirection-id to lookup the redirection information in the
localised indirection-id table.) localised indirection-id table.)
1 - Node ID (The flowspec client uses the received indirection-id 1 - Node ID (The flowspec client uses the received indirection-id
as a Segment Routing Node ID to redirect traffic towards) as a Segment Routing Node ID to redirect traffic towards)
2 - Agency ID (The flowspec client uses the received indirection-
id as a Segment Routing Agency ID to redirect traffic towards)
3 - AS (Autonomous System) ID (The flowspec client uses the
received indirection-id as a Segment Routing Autonomous System ID
to redirect traffic towards)
4 - Anycast ID (The flowspec client uses the received indirection-
id as a Segment Routing Anycast ID to redirect traffic towards)
5 - Multicast ID (The flowspec client uses the received
indirection-id as a Segment Routing Multicast ID to redirect
traffic towards)
6 - Binding Segment ID (The flowspec client uses the received 6 - Binding Segment ID (The flowspec client uses the received
indirection-id as a Segment Routing Binding Segment ID to redirect indirection-id as a Segment Routing Binding Segment ID to redirect
traffic towards) [I-D.draft-ietf-spring-segment-routing] [6] traffic towards) [I-D.draft-ietf-spring-segment-routing] [6]
7 - VPN ID (The flowspec client uses the received indirection-id
as a Segment Routing VPN ID to redirect traffic towards)
8 - OAM ID (The flowspec client uses the received indirection-id
as a Segment Routing OAM ID to redirect traffic towards)
9 - ECMP (Equal Cost Multi-Path) ID (The flowspec client uses the
received indirection-id as a Segment Routing PeerSet ID to
redirect traffic towards)
10 - QoS ID (The flowspec client uses the received indirection-id
as a Segment Routing QoS ID to redirect traffic towards)
11 - Bandwidth-Guarantee ID (The flowspec client uses the received
indirection-id as a Segment Routing Bandwidth-Guarantee ID to
redirect traffic towards)
12 - Security ID (The flowspec client uses the received
indirection-id as a Segment Routing Security ID to redirect
traffic towards)
13 - Multi-Topology ID (The flowspec client uses the received
indirection-id as a Segment Routing Multi-Topology ID to redirect
traffic towards)
5. Redirect using localised indirection-id mapping table 5. Redirect using localised indirection-id mapping table
When a BGP speaker receives a flowspec policy route with a 'redirect When a BGP flowspec client receives a flowspec policy route with a
to indirection-id' extended community and this route represents the 'redirect to indirection-id' extended community attached and the
one and only best path or an equal cost multipath, it installs a route represents the best BGP path, it will install a flowspec
traffic filtering rule that matches the packets described by the NLRI traffic filtering rule matching the IP tupples described by the
field and redirects them (C=0) or copies them (C=1) towards the flowpsec NLRI field and consequently redirects the flow (C=0) or
indirection-id local recursed path. To construct the local recursed copies the flow (C=1) using the information identified by the
path, the flowspec client does a local indirection-id mapping table 'redirect-to-indirection-id' community.
lookup (i.e. indirection-id type = 0) using the key comprised of the
indirection-id 32-bit value and indirection-id type (=0) 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.
skipping to change at page 13, line 29 skipping to change at page 12, line 29
[6] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., [6] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
Shakir, R., Bashandy, A., Horneffer, M., Henderickx, W., Shakir, R., Bashandy, A., Horneffer, M., Henderickx, W.,
Tantsura, J., Crabbe, E., Milojevic, I., and S. Ytti, Tantsura, J., Crabbe, E., Milojevic, I., and S. Ytti,
"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.
Appendix A. Additional indirection_id types waiting for use-case
description
This section is a placeholder and collection of potential additional
indirection_id types. The current use-cases do not require these
particular indirection types, however at later stage when use-cases
are identified they may be added to the body of teh draft.
2 - Agency ID (The flowspec client uses the received indirection-id
as a Segment Routing Agency ID to redirect traffic towards)
3 - AS (Autonomous System) ID (The flowspec client uses the received
indirection-id as a Segment Routing Autonomous System ID to redirect
traffic towards)
4 - Anycast ID (The flowspec client uses the received indirection-id
as a Segment Routing Anycast ID to redirect traffic towards)
5 - Multicast ID (The flowspec client uses the received indirection-
id as a Segment Routing Multicast ID to redirect traffic towards)
7 - VPN ID (The flowspec client uses the received indirection-id as a
Segment Routing VPN ID to redirect traffic towards)
8 - OAM ID (The flowspec client uses the received indirection-id as a
Segment Routing OAM ID to redirect traffic towards)
9 - ECMP (Equal Cost Multi-Path) ID (The flowspec client uses the
received indirection-id as a Segment Routing PeerSet ID to redirect
traffic towards)
10 - QoS ID (The flowspec client uses the received indirection-id as
a Segment Routing QoS ID to redirect traffic towards)
11 - Bandwidth-Guarantee ID (The flowspec client uses the received
indirection-id as a Segment Routing Bandwidth-Guarantee ID to
redirect traffic towards)
12 - Security ID (The flowspec client uses the received indirection-
id as a Segment Routing Security ID to redirect traffic towards)
13 - Multi-Topology ID (The flowspec client uses the received
indirection-id as a Segment Routing Multi-Topology ID to redirect
traffic towards)
Authors' Addresses Authors' Addresses
Gunter Van de Velde (editor) Gunter Van de Velde (editor)
Nokia Nokia
Antwerp Antwerp
BE BE
Email: gunter.van_de_velde@nokia.com Email: gunter.van_de_velde@nokia.com
Keyur Patel Keyur Patel
Cisco Systems Arrcus
170 W. Tasman Drive
San Jose, CA 95134
USA USA
Email: keyupate@cisco.com Email: keyur@arrcus.com
Zhenbin Li Zhenbin Li
Huawei Technologies Huawei Technologies
Huawei Bld., No. 156 Beiquing Rd Huawei Bld., No. 156 Beiquing Rd
Beijing 100095 Beijing 100095
China China
Email: lizhenbin@huawei.com Email: lizhenbin@huawei.com
 End of changes. 38 change blocks. 
187 lines changed or deleted 196 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/