idnits 2.17.1 draft-ietf0-idr-srv6-flowspec-path-redirect-00.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 (October 22, 2018) is 2012 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 201 == Unused Reference: '3' is defined on line 215, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 222, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 226, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 230, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 234, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 239, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-idr-flowspec-path-redirect-06 ** 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: April 25, 2019 Arrcus 6 Z. Li 7 H. Chen 8 Huawei Technologies 9 October 22, 2018 11 Flowspec Indirection-id Redirect for SRv6 12 draft-ietf0-idr-srv6-flowspec-path-redirect-00 14 Abstract 16 This document defines extensions to "FlowSpec Redirect to 17 indirection-id Extended Community" for SRv6. This extended community 18 can trigger advanced redirection capabilities to flowspec clients for 19 SRv6. When activated, this flowspec extended community is used by a 20 flowspec client to retrieve the corresponding next-hop and encoding 21 information within a localised indirection-id mapping table. 23 The functionality detailed in this document allows a network 24 controller to decouple the BGP flowspec redirection instruction from 25 the operation of the available paths. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [2]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 25, 2019. 50 Copyright Notice 52 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . 5 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 Where 99 Type: 1 octet, defined in ietf-idr-flowspec-path-redirect [1]. 101 Sub-Type: 1 octet, its value (TBD) will be assigned by IANA. 103 Flags: Same as that defined in ietf-idr-flowspec-path-redirect [1]. 105 ID-Type: 1 octet value. This draft defines following Context Types: 107 0 - Localised ID (The flowspec client uses the received 108 indirection-id to lookup forwarding information within the 109 localised indirection-id table. The allocation and programming of 110 the localised indirection-id table is outside scope of the 111 document) 113 1 - Node ID with SID/index in MPLS-based Segment Routing (This 114 means the indirection-id is mapped to an MPLS label using the 115 index as a global offset in the SID/label space) 117 2 - Node ID with SID/label in MPLS-based Segment Routing (This 118 means the indirection-id is mapped to an MPLS label using the 119 indirection-id as global label) 121 3 - Binding Segment ID with SID/index in MPLS-based Segment 122 Routing (This means the indirection-id is mapped to an MPLS 123 binding label using the indirection-id as index for global offset 124 in the SID/label space). 126 4 - Binding Segment ID with SID/label in MPLS-based Segment 127 Routing (This means indirection-id is mapped to an MPLS binding 128 label using the indirection-id as global label). 130 5 - Tunnel ID (Tunnel ID is within a single administrative domain 131 a globally unique tunnel identifier. The allocation and 132 programming of the Tunnel ID within the localised indirection-id 133 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 188 Wim Henderickx 189 Nokia 190 Antwerp 191 BE 193 Email: wim.henderickx@nokia.com 195 6. IANA Considerations 197 This document requests a new sub-type value under "FlowSpec Redirect 198 to indirection-id Extended Community Sub-Type" registery. 200 Value Code Reference 201 0x01 Flowspec Redirect to 128-bit Path-id for SRv6 [RFC-To-Be] 203 7. References 205 7.1. Normative References 207 [1] Velde, G., Patel, K., and Z. Li, "Flowspec Indirection-id 208 Redirect", draft-ietf-idr-flowspec-path-redirect-06 (work 209 in progress), June 2018. 211 [2] Bradner, S., "Key words for use in RFCs to Indicate 212 Requirement Levels", BCP 14, RFC 2119, March 1997, 213 . 215 [3] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 216 and D. McPherson, "Dissemination of Flow Specification 217 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 218 . 220 7.2. Informative References 222 [4] Uttaro, J., Filsfils, C., Alcaide, J., and P. Mohapatra, 223 "Revised Validation Procedure for BGP Flow 224 Specifications", January 2014. 226 [5] Filsfils, C., Previdi, S., Aries, E., Ginsburg, D., and D. 227 Afanasiev, "Segment Routing Centralized Egress Peer 228 Engineering", October 2015. 230 [6] Sreekantiah, A., Filsfils, C., Previdi, S., Sivabalan, S., 231 Mattes, P., and S. Lin, "Segment Routing Traffic 232 Engineering Policy using BGP", October 2015. 234 [7] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 235 Shakir, R., Bashandy, A., Horneffer, M., Henderickx, W., 236 Tantsura, J., Crabbe, E., Milojevic, I., and S. Ytti, 237 "Segment Routing Architecture", December 2015. 239 [8] Sivabalan, S., Medved, M., Filsfils, C., Litkowski, S., 240 Raszuk, R., Bashandy, A., Lopez, V., Tantsura, J., 241 Henderickx, W., Hardwick, J., Milojevic, I., and S. Ytti, 242 "PCEP Extensions for Segment Routing", December 2015. 244 Authors' Addresses 246 Gunter Van de Velde 247 Nokia 248 Antwerp 249 BE 251 Email: gunter.van_de_velde@nokia.com 253 Keyur Patel 254 Arrcus 255 USA 257 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 Huawei Technologies 269 Boston, MA 270 USA 272 Email: Huaimo.chen@huawei.com