idnits 2.17.1 draft-ietf0-idr-srv6-flowspec-path-redirect-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 11, 2021) is 1018 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC-To-Be' on line 202 == Unused Reference: '3' is defined on line 216, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 223, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 227, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 231, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 235, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 240, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-idr-flowspec-path-redirect-11 ** Obsolete normative reference: RFC 5575 (ref. '3') (Obsoleted by RFC 8955) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group G. Van de Velde 3 Internet-Draft Nokia 4 Intended status: Standards Track K. Patel 5 Expires: January 12, 2022 Arrcus 6 Z. Li 7 Huawei Technologies 8 H. Chen 9 Futurewei 10 July 11, 2021 12 Flowspec Indirection-id Redirect for SRv6 13 draft-ietf0-idr-srv6-flowspec-path-redirect-06 15 Abstract 17 This document defines extensions to "FlowSpec Redirect to 18 indirection-id Extended Community" for SRv6. This extended community 19 can trigger advanced redirection capabilities to flowspec clients for 20 SRv6. When activated, this flowspec extended community is used by a 21 flowspec client to retrieve the corresponding next-hop and encoding 22 information within a localised indirection-id mapping table. 24 The functionality detailed in this document allows a network 25 controller to decouple the BGP flowspec redirection instruction from 26 the operation of the available paths. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [2]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 12, 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Redirect to indirection-id Community . . . . . . . . . . . . 2 69 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 70 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 71 5. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 4 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 75 7.2. Informative References . . . . . . . . . . . . . . . . . 6 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 78 1. Introduction 80 "FlowSpec Redirect to indirection-id Extended Community" for IPv4 is 81 defined in ietf-idr-flowspec-path-redirect [1]. This draft specifies 82 extensions to this community for SRv6. 84 2. Redirect to indirection-id Community 86 This document defines a new sub-type value for SRv6 in "FlowSpec 87 Redirect to indirection-id Extended Community". The format of this 88 extended community with the new sub-type value is show below: 90 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 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 | Type |Sub-Type (TBD) | Flags(1 octet)| ID-Type | 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | Generalized indirection_id (16 octets) | 95 ~ ~ 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 Where 100 Type: 1 octet, defined in ietf-idr-flowspec-path-redirect [1]. 102 Sub-Type: 1 octet, its value (TBD) will be assigned by IANA. 104 Flags: Same as that defined in ietf-idr-flowspec-path-redirect [1]. 106 ID-Type: 1 octet value. This draft defines following Context Types: 108 0 - Localised ID (The flowspec client uses the received 109 indirection-id to lookup forwarding information within the 110 localised indirection-id table. The allocation and programming of 111 the localised indirection-id table is outside scope of the 112 document) 114 1 - Node ID with SID/index in MPLS-based Segment Routing (This 115 means the indirection-id is mapped to an MPLS label using the 116 index as a global offset in the SID/label space) 118 2 - Node ID with SID/label in MPLS-based Segment Routing (This 119 means the indirection-id is mapped to an MPLS label using the 120 indirection-id as global label) 122 3 - Binding Segment ID with SID/index in MPLS-based Segment 123 Routing (This means the indirection-id is mapped to an MPLS 124 binding label using the indirection-id as index for global offset 125 in the SID/label space). 127 4 - Binding Segment ID with SID/label in MPLS-based Segment 128 Routing (This means indirection-id is mapped to an MPLS binding 129 label using the indirection-id as global label). 131 5 - Tunnel ID (Tunnel ID is within a single administrative domain 132 a globally unique tunnel identifier. The allocation and 133 programming of the Tunnel ID within the localised indirection-id 134 table is outside scope of the document) 135 6 - Node ID with SID/index in SRv6 (This means the indirection-id 136 is mapped to an SRv6 SID using the indirection-id as global SRv6 137 SID or index) 139 7 - Binding Segment ID with SID/index in SRv6 (This means the 140 indirection-id is mapped to an SRv6 binding SID using the 141 indirection-id as index for global offset in the SID space). 143 8 - Binding Segment ID with SID/index in SRv6 (This means 144 indirection-id is mapped to an SRv6 binding SID using the 145 indirection-id as global SRv6 SID). 147 Generalized indirection_id: 128-bit identifier used as indirection_id 149 3. Security Considerations 151 A system using "Redirect to indirection-id" extended community can 152 cause during the redirect mitigation of a DDoS attack overflow of 153 traffic received by the mitigation infrastructure. 155 4. Acknowledgements 157 This document received valuable comments and input from IDR working 158 group including Adam Simpson, Mustapha Aissaoui, Jan Mertens, Robert 159 Raszuk, Jeff Haas, Susan Hares and Lucy Yong. 161 5. Contributor Addresses 163 Below is a list of other contributing authors in alphabetical order: 165 Arjun Sreekantiah 166 Cisco Systems 167 170 W. Tasman Drive 168 San Jose, CA 95134 169 USA 171 Email: asreekan@cisco.com 173 Nan Wu 174 Huawei Technologies 175 Huawei Bld., No. 156 Beiquing Rd 176 Beijing 100095 177 China 179 Email: eric.wu@huawei.com 181 Shunwan Zhuang 182 Huawei Technologies 183 Huawei Bld., No. 156 Beiquing Rd 184 Beijing 100095 185 China 187 Email: zhuangshunwan@huawei.com 189 Wim Henderickx 190 Nokia 191 Antwerp 192 BE 194 Email: wim.henderickx@nokia.com 196 6. IANA Considerations 198 This document requests a new sub-type value under "FlowSpec Redirect 199 to indirection-id Extended Community Sub-Type" registery. 201 Value Code Reference 202 0x01 Flowspec Redirect to 128-bit Path-id for SRv6 [RFC-To-Be] 204 7. References 206 7.1. Normative References 208 [1] Velde, G. V. D., Patel, K., and Z. Li, "Flowspec 209 Indirection-id Redirect", draft-ietf-idr-flowspec-path- 210 redirect-11 (work in progress), May 2020. 212 [2] Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", BCP 14, RFC 2119, March 1997, 214 . 216 [3] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 217 and D. McPherson, "Dissemination of Flow Specification 218 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 219 . 221 7.2. Informative References 223 [4] Uttaro, J., Filsfils, C., Alcaide, J., and P. Mohapatra, 224 "Revised Validation Procedure for BGP Flow 225 Specifications", January 2014. 227 [5] Filsfils, C., Previdi, S., Aries, E., Ginsburg, D., and D. 228 Afanasiev, "Segment Routing Centralized Egress Peer 229 Engineering", October 2015. 231 [6] Sreekantiah, A., Filsfils, C., Previdi, S., Sivabalan, S., 232 Mattes, P., and S. Lin, "Segment Routing Traffic 233 Engineering Policy using BGP", October 2015. 235 [7] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 236 Shakir, R., Bashandy, A., Horneffer, M., Henderickx, W., 237 Tantsura, J., Crabbe, E., Milojevic, I., and S. Ytti, 238 "Segment Routing Architecture", December 2015. 240 [8] Sivabalan, S., Medved, M., Filsfils, C., Litkowski, S., 241 Raszuk, R., Bashandy, A., Lopez, V., Tantsura, J., 242 Henderickx, W., Hardwick, J., Milojevic, I., and S. Ytti, 243 "PCEP Extensions for Segment Routing", December 2015. 245 Authors' Addresses 247 Gunter Van de Velde 248 Nokia 249 Antwerp 250 BE 252 Email: gunter.van_de_velde@nokia.com 254 Keyur Patel 255 Arrcus 256 USA 258 Email: keyur@arrcus.com 259 Zhenbin Li 260 Huawei Technologies 261 Huawei Bld., No. 156 Beiquing Rd 262 Beijing 100095 263 China 265 Email: lizhenbin@huawei.com 267 Huaimo Chen 268 Futurewei 269 Boston, MA 270 USA 272 Email: Huaimo.chen@futurewei.com