draft-vandevelde-idr-flowspec-path-redirect-01.txt   draft-vandevelde-idr-flowspec-path-redirect-02.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 Alcatel-Lucent
Expires: July 15, 2016 K. Patel Expires: September 18, 2016 K. Patel
A. Sreekantiah
Cisco Systems Cisco Systems
January 12, 2016 March 17, 2016
Flowspec Indirection-id Redirect Flowspec Indirection-id Redirect
draft-vandevelde-idr-flowspec-path-redirect-01 draft-vandevelde-idr-flowspec-path-redirect-02
Abstract Abstract
Flow-spec is an extension to BGP that allows for the dissemination of Flow-spec 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 particular 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 redirect-to-INDIRECTION_ID (32-bit or
128-bit) flow-spec action to provide advanced redirection 128-bit) flow-spec action to provide advanced redirection
capabilities. When activated, the flowspec Indirection-id is used to capabilities. When activated, the flowspec Indirection-id is used to
identify the next-hop redirect information within a router locallized identify the next-hop redirect information within a router locallized
Indirection-id table. This allows a flowspec controller to signal Indirection-id table. This allows a flowspec controller to signal
redirection towards a next-hop IP address, a shortest path tunnel, a redirection towards a next-hop IP address, a shortest path tunnel, a
traffic engineered tunnel or a next-next-hop (traffic engineered) traffic engineered tunnel or a next-next-hop engineered tunnel
tunnel egress interface. interface.
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 10
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 July 15, 2016. This Internet-Draft will expire on September 18, 2016.
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
skipping to change at page 2, line 36 skipping to change at page 2, line 36
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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 Communities . . . . . . . . . . . 6
5. Redirect using locallized INDIRECTION_ID Router Mapping . . . 6 5. Redirect using locallized INDIRECTION_ID Router Mapping . . . 7
6. Validation Procedures . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Flow-spec RFC5575 [2] is an extension to BGP that allows for the Flow-spec 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 but the primary one for many network operators
is the distribution of traffic filtering actions for DDoS mitigation. is the distribution of traffic filtering actions for DDoS mitigation.
Every flow-spec route is effectively a rule, consisting of a matching Every flow-spec route is effectively a rule, consisting of a matching
skipping to change at page 4, line 46 skipping to change at page 4, line 46
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 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 policy message (redirect-to-INDIRECTION_ID#2) to many BGP
flowspec consuming routers. This message is instructing the Flowspec flowspec consuming routers. This message is instructing the Flowspec
recipient routers to redirect traffic onto a path engineered tunnel. recipient routers to redirect traffic onto a path engineered tunnel.
For this use-case scenario, each flowspec recipient router has a path For this use-case scenario, each flowspec recipient router has a path
engineered tunnel configured. Each tunnel can have its own unique 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 associated with an INDIRECTION_ID, and for this example it is on all
recipient routers INDIRECTION_ID#2. Both manual and orchestrated recipient routers INDIRECTION_ID#2. Both manual and orchestrated
tunnel provisioning is supported, however for large scale deployment tunnel provisioning is supported, however for large scale deployment
automation is advisable. automation is advisable.
When using this setup, a BGP flowspec controller can send a single A first example using this setup, is when a BGP flowspec controller
BGP Flowspec NLRI with redirect-to-INDIRECTION_ID#2. This BGP sends a single BGP Flowspec NLRI with redirect-to-INDIRECTION_ID#2.
Flowspec NLRI is received by all recipient routers. Each of the This BGP Flowspec NLRI is received by all recipient routers. Each of
recipient routers performs a locallised recursive lookup for the recipient routers performs a locallised recursive lookup for
INDIRECTION_ID#2 in the INDIRECTION_ID Table and identifies the INDIRECTION_ID#2 in the INDIRECTION_ID Table and identifies the
corresponding locallised tunnel redirect information. This corresponding locallised tunnel redirect information. This
locallised tunnel information is now used to redirect traffic locallised tunnel information is now used to redirect traffic
matching the Flowspec policy towards a path engineered tunnel. 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 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 allowing a BGP Flowspec controller send a single
flowspec policy message (redirect-to-INDIRECTION_ID#3) to many BGP flowspec policy message (redirect-to-INDIRECTION_ID#3) to many BGP
flowspec consuming routers. This message is instructing the Flowspec flowspec consuming routers. This message is instructing the Flowspec
recipient routers to redirect traffic onto a shortest or engineered recipient routers to redirect traffic onto a shortest or engineered
path to a tunnel end-point and onwards to the next-hop-interface on 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 this end-point. This type of tunnel is used for example for Segment
Routing Central Egress Path Engineering [4]. Routing Central Egress Path Engineering [4].
skipping to change at page 6, line 22 skipping to change at page 6, line 43
administrator fields encode a flow-spec 'redirect to INDIRECTION_ID' administrator fields encode a flow-spec 'redirect to INDIRECTION_ID'
action. In the new extended community the 4-byte or 16-byte global 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 administrator field encodes the 32-bit or 128-bit INDIRECTION_ID's
providing the INDIRECTION_ID to allow a local to the router mapping providing the INDIRECTION_ID to allow a local to the router mapping
reference to an engineered Path. The 2-byte local administrator reference to an engineered Path. The 2-byte local administrator
field is formatted as shown in Figure 1. field is formatted as shown in Figure 1.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 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 Figure 1
In the local administrator field the least-significant bit is defined 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 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 applies to copies of the matching packets and not to the original
traffic stream. traffic stream.
The 'TID' field identifies a 2 bit Table-id field. This field is The 'TID' field identifies a 2 bit Table-id field. This field is
used to provide the router consuming the flowspec rule an indication used to provide the router consuming the flowspec rule an indication
how and where to use the INDIRECTION_ID when redirecting traffic. how and where to use the INDIRECTION_ID when redirecting traffic.
All bits other than the 'C' bit in the local administrator field MUST Bit 2 is defined to be the 'B' (Binding) bit. When the 'B' bit is
be set to 0 by the originating BGP speaker and ignored by receiving set, the value encoded in the global administrator field is a Binding
BGP speakers. 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 5. Redirect using locallized INDIRECTION_ID Router Mapping
When a BGP speaker receives a flow-spec route with a 'redirect to When a BGP speaker receives a flow-spec route with a 'redirect to
INDIRECTION_ID' extended community and this route represents the one INDIRECTION_ID' extended community and this route represents the one
and only best path, it installs a traffic filtering rule that matches 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 the packets described by the NLRI field and redirects them (C=0) or
copies them (C=1) towards the INDIRECTION_ID local recursed Path. copies them (C=1) towards the INDIRECTION_ID local recursed Path.
The BGP speaker is expected to do a local INDIRECTION_ID Table lookup The BGP speaker is expected to do a local INDIRECTION_ID Table lookup
to identify the redirection information. to identify the redirection information.
skipping to change at page 8, line 42 skipping to change at page 9, line 17
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
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<http://www.rfc-editor.org/info/rfc5575>. <http://www.rfc-editor.org/info/rfc5575>.
10.2. Informative References 10.2. Informative References
[3] Uttaro, J., Filsfils, C., Filsfils, C., Alcaide, J., and [3] Uttaro, J., Filsfils, C., Alcaide, J., and P. Mohapatra,
P. Mohapatra, "Revised Validation Procedure for BGP Flow "Revised Validation Procedure for BGP Flow
Specifications", January 2014. Specifications", January 2014.
[4] Filsfils, C., Previdi, S., Aries, E., Ginsburg, D., and D. [4] Filsfils, C., Previdi, S., Aries, E., Ginsburg, D., and D.
Afanasiev, "Segment Routing Centralized Egress Peer Afanasiev, "Segment Routing Centralized Egress Peer
Engineering", October 2015. 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 Authors' Addresses
Gunter Van de Velde (editor) Gunter Van de Velde (editor)
Alcatel-Lucent Alcatel-Lucent
Antwerp Antwerp
BE BE
Email: gunter.van_de_velde@alcatel-lucent.com Email: gunter.van_de_velde@alcatel-lucent.com
Wim Henderickx Wim Henderickx
Alcatel-Lucent Alcatel-Lucent
Antwerp Antwerp
BE BE
Email: wim.henderickx@alcatel-lucent.com Email: wim.henderickx@alcatel-lucent.com
Keyur Patel Keyur Patel
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
skipping to change at line 398 skipping to change at page 10, line 18
Email: wim.henderickx@alcatel-lucent.com Email: wim.henderickx@alcatel-lucent.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
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: asreekan@cisco.com
 End of changes. 16 change blocks. 
22 lines changed or deleted 60 lines changed or added

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