idnits 2.17.1 draft-ietf0-idr-srv6-flowspec-path-redirect-07.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 (10 January 2022) is 838 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 200 == 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: 14 July 2022 Arrcus 6 Z. Li 7 Huawei Technologies 8 H. Chen 9 Futurewei 10 10 January 2022 12 Flowspec Indirection-id Redirect for SRv6 13 draft-ietf0-idr-srv6-flowspec-path-redirect-07 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 14 July 2022. 50 Copyright Notice 52 Copyright (c) 2022 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 (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Redirect to indirection-id Community . . . . . . . . . . . . 2 68 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 69 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 70 5. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 4 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 74 7.2. Informative References . . . . . . . . . . . . . . . . . 5 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 77 1. Introduction 79 "FlowSpec Redirect to indirection-id Extended Community" for IPv4 is 80 defined in ietf-idr-flowspec-path-redirect [1]. This draft specifies 81 extensions to this community for SRv6. 83 2. Redirect to indirection-id Community 85 This document defines a new sub-type value for SRv6 in "FlowSpec 86 Redirect to indirection-id Extended Community". The format of this 87 extended community with the new sub-type value is show below: 89 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 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 | Type |Sub-Type (TBD) | Flags(1 octet)| ID-Type | 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 | Generalized indirection_id (16 octets) | 94 ~ ~ 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 Where 98 Type: 1 octet, defined in ietf-idr-flowspec-path-redirect [1]. 100 Sub-Type: 1 octet, its value (TBD) will be assigned by IANA. 102 Flags: Same as that defined in ietf-idr-flowspec-path-redirect [1]. 104 ID-Type: 1 octet value. This draft defines following Context Types: 106 * 0 - Localised ID (The flowspec client uses the received 107 indirection-id to lookup forwarding information within the 108 localised indirection-id table. The allocation and programming of 109 the localised indirection-id table is outside scope of the 110 document) 112 * 1 - Node ID with SID/index in MPLS-based Segment Routing (This 113 means the indirection-id is mapped to an MPLS label using the 114 index as a global offset in the SID/label space) 116 * 2 - Node ID with SID/label in MPLS-based Segment Routing (This 117 means the indirection-id is mapped to an MPLS label using the 118 indirection-id as global label) 120 * 3 - Binding Segment ID with SID/index in MPLS-based Segment 121 Routing (This means the indirection-id is mapped to an MPLS 122 binding label using the indirection-id as index for global offset 123 in the SID/label space). 125 * 4 - Binding Segment ID with SID/label in MPLS-based Segment 126 Routing (This means indirection-id is mapped to an MPLS binding 127 label using the indirection-id as global label). 129 * 5 - Tunnel ID (Tunnel ID is within a single administrative domain 130 a globally unique tunnel identifier. The allocation and 131 programming of the Tunnel ID within the localised indirection-id 132 table is outside scope of the document) 134 * 6 - Node ID with SID/index in SRv6 (This means the indirection-id 135 is mapped to an SRv6 SID using the indirection-id as global SRv6 136 SID or index) 138 * 7 - Binding Segment ID with SID/index in SRv6 (This means the 139 indirection-id is mapped to an SRv6 binding SID using the 140 indirection-id as index for global offset in the SID space). 142 * 8 - Binding Segment ID with SID/index in SRv6 (This means 143 indirection-id is mapped to an SRv6 binding SID using the 144 indirection-id as global SRv6 SID). 146 Generalized indirection_id: 128-bit identifier used as indirection_id 148 3. Security Considerations 150 A system using "Redirect to indirection-id" extended community can 151 cause during the redirect mitigation of a DDoS attack overflow of 152 traffic received by the mitigation infrastructure. 154 4. Acknowledgements 156 This document received valuable comments and input from IDR working 157 group including Adam Simpson, Mustapha Aissaoui, Jan Mertens, Robert 158 Raszuk, Jeff Haas, Susan Hares and Lucy Yong. 160 5. Contributor Addresses 162 Below is a list of other contributing authors in alphabetical order: 164 Arjun Sreekantiah 165 Cisco Systems 166 170 W. Tasman Drive 167 San Jose, CA 95134 168 USA 170 Email: asreekan@cisco.com 172 Nan Wu 173 Huawei Technologies 174 Huawei Bld., No. 156 Beiquing Rd 175 Beijing 100095 176 China 178 Email: eric.wu@huawei.com 180 Shunwan Zhuang 181 Huawei Technologies 182 Huawei Bld., No. 156 Beiquing Rd 183 Beijing 100095 184 China 186 Email: zhuangshunwan@huawei.com 187 Wim Henderickx 188 Nokia 189 Antwerp 190 BE 192 Email: wim.henderickx@nokia.com 194 6. IANA Considerations 196 This document requests a new sub-type value under "FlowSpec Redirect 197 to indirection-id Extended Community Sub-Type" registery. 199 Value Code Reference 200 0x01 Flowspec Redirect to 128-bit Path-id for SRv6 [RFC-To-Be] 202 7. References 204 7.1. Normative References 206 [1] Velde, G. V. D., Patel, K., and Z. Li, "Flowspec 207 Indirection-id Redirect", Work in Progress, Internet- 208 Draft, draft-ietf-idr-flowspec-path-redirect-11, 26 May 209 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 Belgium 252 Email: gunter.van_de_velde@nokia.com 254 Keyur Patel 255 Arrcus 256 United States of America 258 Email: keyur@arrcus.com 260 Zhenbin Li 261 Huawei Technologies 262 Huawei Bld., No. 156 Beiquing Rd 263 Beijing 264 100095 265 China 267 Email: lizhenbin@huawei.com 269 Huaimo Chen 270 Futurewei 271 Boston, MA, 272 United States of America 274 Email: Huaimo.chen@futurewei.com