]> Nokia

Antwerp BE gunter.van_de_velde@nokia.com

Arrcus

USA keyur@arrcus.com

Huawei Technologies

Huawei Bld., No. 156 Beiquing Rd Beijing 100095 China lizhenbin@huawei.com

Futurewei

Boston, MA USA Huaimo.chen@futurewei.com

Routing IDR Working Group This document defines extensions to "FlowSpec Redirect to indirection-id Extended Community" for SRv6. This extended community can trigger advanced redirection capabilities to flowspec clients for SRv6. When activated, this flowspec extended community is used by a flowspec client to retrieve the corresponding next-hop and encoding information within a localised indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the operation of the available paths. 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.

"FlowSpec Redirect to indirection-id Extended Community" for IPv4 is defined in ietf-idr-flowspec-path-redirect. This draft specifies extensions to this community for SRv6.

This document defines a new sub-type value for SRv6 in "FlowSpec Redirect to indirection-id Extended Community". The format of this extended community with the new sub-type value is show below:

Where Type: 1 octet, defined in ietf-idr-flowspec-path-redirect. Sub-Type: 1 octet, its value (TBD) will be assigned by IANA. Flags: Same as that defined in ietf-idr-flowspec-path-redirect. ID-Type: 1 octet value. This draft defines following Context Types: 0 - Localised ID (The flowspec client uses the received indirection-id to lookup forwarding information within the localised indirection-id table. The allocation and programming of the localised indirection-id table is outside scope of the document) 1 - Node ID with SID/index in MPLS-based Segment Routing (This means the indirection-id is mapped to an MPLS label using the index as a global offset in the SID/label space) 2 - Node ID with SID/label in MPLS-based Segment Routing (This means the indirection-id is mapped to an MPLS label using the indirection-id as global label) 3 - Binding Segment ID with SID/index in MPLS-based Segment Routing (This means the indirection-id is mapped to an MPLS binding label using the indirection-id as index for global offset in the SID/label space). 4 - Binding Segment ID with SID/label in MPLS-based Segment Routing (This means indirection-id is mapped to an MPLS binding label using the indirection-id as global label). 5 - Tunnel ID (Tunnel ID is within a single administrative domain a globally unique tunnel identifier. The allocation and programming of the Tunnel ID within the localised indirection-id table is outside scope of the document) 6 - Node ID with SID/index in SRv6 (This means the indirection-id is mapped to an SRv6 SID using the indirection-id as global SRv6 SID or index) 7 - Binding Segment ID with SID/index in SRv6 (This means the indirection-id is mapped to an SRv6 binding SID using the indirection-id as index for global offset in the SID space). 8 - Binding Segment ID with SID/index in SRv6 (This means indirection-id is mapped to an SRv6 binding SID using the indirection-id as global SRv6 SID). Generalized indirection_id: 128-bit identifier used as indirection_id

A system using "Redirect to indirection-id" extended community can cause during the redirect mitigation of a DDoS attack overflow of traffic received by the mitigation infrastructure.

This document received valuable comments and input from IDR working group including Adam Simpson, Mustapha Aissaoui, Jan Mertens, Robert Raszuk, Jeff Haas, Susan Hares and Lucy Yong.

Below is a list of other contributing authors in alphabetical order:

This document requests a new sub-type value under "FlowSpec Redirect to indirection-id Extended Community Sub-Type" registery.

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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. Note that the force of these words is modified by the requirement level of the document in which they are used. &RFC8955;