idnits 2.17.1 draft-ietf-idr-flowspec-path-redirect-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: While it MUST NOT happen, and is seen as invallid combination, it is possible from a semenatics perspective to have multiple clashing redirect actions defined within a single flowspec rule. For best and consistant RFC5575 flowspec redirect behavior the redirect as documented by RFC5575 MUST not be broken, and hence when a clash occurs, then RFC5575 based redirect SHOULD take priority. Additionally, if the 'redirect to indirection-id' does not result in a valid redirection, then the flowspec rule must be processed as if the 'redirect to indirection-id' community was not attached to the flowspec route and MUST provide an indication within the BGP routing table that the respective 'redirect to indirection-id' resulted in an invalid redirection action. -- The document date (March 2, 2017) is 2606 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: 'I-D.draft-ietf-spring-segment-routing' on line 364 -- Looks like a reference, but probably isn't: 'RFC-To-Be' on line 484 ** Obsolete normative reference: RFC 5575 (ref. '2') (Obsoleted by RFC 8955) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group G. Van de Velde, Ed. 3 Internet-Draft Nokia 4 Intended status: Standards Track K. Patel 5 Expires: September 3, 2017 Arrcus 6 Z. Li 7 Huawei Technologies 8 March 2, 2017 10 Flowspec Indirection-id Redirect 11 draft-ietf-idr-flowspec-path-redirect-01 13 Abstract 15 Flowspec is an extension to BGP that allows for the dissemination of 16 traffic flow specification rules. This has many possible 17 applications but the primary one for many network operators is the 18 distribution of traffic filtering actions for DDoS mitigation. The 19 flow-spec standard RFC5575 [2] defines a redirect-to-VRF action for 20 policy-based forwarding but this mechanism is not always sufficient, 21 particularly if the redirected traffic needs to be steered into an 22 engineered path or into a service plane. 24 This document defines a new extended community known as redirect-to- 25 indirection-id (32-bit) flowspec action to provide advanced 26 redirection capabilities on flowspec clients. When activated, the 27 flowspec extended community is used by a flowspec client to find the 28 correct next-hop entry within a localised indirection-id mapping 29 table. 31 The functionality present in this draft allows a network controller 32 to decouple flowspec functionality from the creation and maintainance 33 of the network's service plane itself including the setup of tunnels 34 and other service constructs that could be managed by other network 35 devices. 37 Requirements Language 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in RFC 2119 [1]. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on September 3, 2017. 60 Copyright Notice 62 Copyright (c) 2017 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. indirection-id and indirection-id table . . . . . . . . . . . 3 79 3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 4 80 3.1. Redirection shortest Path tunnel . . . . . . . . . . . . 4 81 3.2. Redirection to path-engineered tunnels . . . . . . . . . 5 82 3.3. Redirection to complex dynamically constructed tunnels . 6 83 4. Redirect to indirection-id Community . . . . . . . . . . . . 7 84 5. Redirect using localised indirection-id mapping table . . . . 8 85 6. Validation Procedures . . . . . . . . . . . . . . . . . . . . 9 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 88 9. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 9 89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 92 11.2. Informative References . . . . . . . . . . . . . . . . . 12 93 Appendix A. Additional indirection_id types waiting for use-case 94 description . . . . . . . . . . . . . . . . . . . . 12 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 97 1. Introduction 99 Flowspec RFC5575 [2] is an extension to BGP that allows for the 100 dissemination of traffic flow specification rules. This has many 101 possible applications, however the primary one for many network 102 operators is the distribution of traffic filtering actions for DDoS 103 mitigation. 105 Every flowspec policy route is effectively a rule, consisting of a 106 matching part (encoded in the NLRI field) and an action part (encoded 107 in one or more BGP extended communities). The flow-spec standard 108 RFC5575 [2] defines widely-used filter actions such as discard and 109 rate limit; it also defines a redirect-to-VRF action for policy-based 110 forwarding. Using the redirect-to-VRF action to steer traffic 111 towards an alternate destination is useful for DDoS mitigation but 112 using this technology can be cumbersome when there is need to steer 113 the traffic onto an engineered traffic path. 115 This draft proposes a new redirect-to-indirection-id flowspec action 116 facilitating an anchor point for policy-based forwarding onto an 117 engineered path or into a service plane. The flowspec client 118 consuming and utilizing the new flowspec indirection-id extended- 119 community constructs the redirection information based upon 120 information found within a localised indirection-id mapping table. 121 The localised mapping table is a table construct, sequenced by a 122 table key, providing next-hop information. 124 The redirect-to-indirection-id flowspec action is encoded in a newly 125 defined BGP extended community. The type of redirection is 126 identified as an extended community indirection-id type field. 128 This draft defines the indirection-id extended-community and a few 129 wellknown indirection-id types. The specific mechanics to construct 130 a localised indirection-id mapping table are out-of-scope of this 131 document. 133 2. indirection-id and indirection-id table 135 An indirection-id is an abstract number (32-bit value) used as 136 identifier for a localised indirection decision. The indirection-id 137 will allow a flowspec client to redirect traffic into a service plane 138 or consequently onto an engineered traffic path. For example, when a 139 BGP flowspec controller signals a flowspec client the indirection-id 140 extended community, then the flowspec client uses the indirection-id 141 to make a recursive lookup to find the next-hop information. The 142 indirection-id is used to find the corresponding next-hop information 143 within the localised indirection mapping table. 145 The indirection-id table is localised on the router. The 146 indirection-id table is constructed out of table keys, each mapped to 147 localised redirection information. Each table key is composed by the 148 combining indirection-id type and an indirection-id 32-bit value. 149 Each entry in the indirection-table key maps to sufficient 150 information (parameters regarding encapsulation, egress-interface, 151 QoS, etc...) to successfully redirect traffic according flowspec 152 controller expectations. 154 3. Use Case Scenarios 156 This section describes use-case scenarios when deploying redirect-to- 157 indirection-id. 159 3.1. Redirection shortest Path tunnel 161 Example: Indirection-ID community types to be used: 163 o 0 (localised ID): When the intent is to use a localised 164 Indirection-id table on the flowspec client 166 o 1 (Node ID): When the intent is to use a Segment Routing based 167 Indirection-id table on the flowspec client 169 Description: 171 The first use-case describes an example where a single flowspec route 172 (i.e. flowspec_route#1) is sent by a flowspec controller to many BGP 173 flowspec clients. This single flowspec route will instruct all 174 Flowspec clients to redirect matching dataflows onto a shortest-path 175 tunnel pointing towards a single IP destination address. 177 For this first use-case scenario, each flowspec client receives a 178 flowspec route (flowspec_route#1) which has the redirect-to- 179 indirection-id extended community attached. The extended redirect- 180 to-indirection-id community contains the table key consisting out of 181 the indirection-id type and indirection-id 32-bit value. The table 182 key is used on the flowspec client to map to the corresponding next- 183 hop information within the local indirection-id table. The finite 184 result of this operation is a remote tunnel end-point IP address 185 together with accordingly sufficient tunnel encapsulation information 186 to forward and encapsulate the data-packet accordingly. 188 Requirements: 190 For redirect to shortest path tunnel it is required that the tunnel 191 MUST be operational and allow packets to be exchanged between tunnel 192 head- and tail-end. 194 3.2. Redirection to path-engineered tunnels 196 Example: Indirection-ID community types to be used: 198 o 0 (localised ID): When the intent is to use a localised 199 Indirection-id table on the flowspec client 201 o 6 (Binding Segment ID): When the intent is to use a Segment 202 Routing based Indirection-id table on the flowspec client 204 Description: 206 The second use-case describes an example where a flowspec controler 207 injects a single flowspec route which gets distributed to many BGP 208 flowspec clients. This single flowspec route intends to instruct all 209 Flowspec clients to redirect corresponding dataflows onto a path 210 engineered tunnel. It is expected that each of the path engineered 211 tunnels is instantiated by out-of-band mechanisms. Each used path 212 engineered tunnel has a unque table key identifier. consequently, the 213 table key uniquely identifies exactly -one- path engineered tunnel. 215 In this use-case example, the flowspec controller sends a flowspec 216 route to each of the flowspec clients and this flowspec route has a 217 redirect-to-indirection-id extended community attached. The 218 redirect-to-indirection-id extended community embeds table key 219 information and hence provides sufficient information to select the 220 corresponding path-engineered tunnel to redirect the packet according 221 the flowspec controller expectations. 223 Segment Routing Example: 225 A concrete embodiment of a Segment Routing use-case example is found 226 in networks where path engineered tunnels are created by a Segment 227 Routing MPLS label stack. In such a deployment, the indirection-id 228 provides an anchorpoint reference to a Segment Routing Binding SID. 229 However, the indirection-id type provides a pointer to the Binding 230 SID semantics to be used. The Binding SID is a segment identifier 231 value (as per segment routing definitions in [I-D.draft-ietf-spring- 232 segment-routing] [6]) used to associate an explicit path. The 233 Binding SID and corresponding path engineered tunnel can for example 234 be setup by a controller using BGP as specified in [I-D.sreekantiah- 235 idr-segment-routing-te] [5] or by using PCEP as detailed in draft- 236 ietf-pce-segment-routing [7]. To conclude, when a BGP speaker at 237 some point in time receives a flow-spec route with an extended 238 'redirect-to-indirection-id' community, it installs a traffic 239 filtering rule that matches particular packets and redirects them 240 onto an explicit path associated with the corresponding Binding SID. 242 The encoding of the Binding SID within the redirect-to-indirection-id 243 extended community is specified in section 4. 245 Requirements: 247 For redirect to path engineered tunnels it is required that the 248 engineered tunnel MUST be active and allow packets to be exchanged 249 between tunnel head- and tail-end. 251 3.3. Redirection to complex dynamically constructed tunnels 253 Example: Indirection-ID community types to be used: 255 o 0 (localised ID) with TID: When the intent is to use a localised 256 Indirection-id table, then TID (Table-ID) field could be used to 257 sequence multiple redirect-to-indirection-id actions together to 258 construct a more complex path engineered tunnel. The order of 259 sequencing the redirection information may be identified by using 260 the TID field. 262 Description: 264 A third use-case describes the application and redirection towards 265 complex dynamically constructed tunnels. For this use-case a BGP 266 flowspec controller injects a flowspec route with multiple 'redirect- 267 to-indirection-id' communities attached. A recipient flowspec client 268 may use the Table-ID (TID) field embedded within each 'redirect-to- 269 indirection-id' community to sequence the redirect information. The 270 complex dynamically constructed tunnel is the product of 271 concatenating the available redirect information (i.e. MPLS Segment 272 Routing Labels). 274 Segment Routing Example: 276 i.e. a classic Segment Routing example using complex tunnels is found 277 in DDoS mitigation and traffic offload. Suspicious traffic (e.g. 278 dirty traffic flows) may be steered into a Segment Routing Central 279 Egress Path Engineered tunnel [4]. For this particular complex 280 dynamic redirect tunnel embodiment, a first redirect-to-indirection- 281 id (i.e. TID=0) is used to redirect traffic into a tunnel towards a 282 particlar egress router, while a second redirect-to-indirection-id 283 (i.e. TID=1) is used to steer traffic beyond the particular egress 284 router towards a pre-identified interface/peer. 286 For this DDoS use-case, in its simplest embodiment, the flowspec 287 client must dynamically append 2 MPLS labels. A first MPLS label 288 (the outer label) to steer the original packet to the egress node 289 (and hence using a shortest path tunnel), while a second MPLS label 290 (matching redirect-to-indirection-id with TID=1), the inner label, to 291 steer on the egress router the original packet to a pre-defined 292 interface/peer. The basic data-plane principles are documented by 293 [4]. 295 Requirements: 297 To achieve redirection towards complex dynamically constructed 298 tunnels, for each flowspec route, multiple indirection-ids, each 299 using a unique Tunnel ID may imposed upon a given flowspec policy 300 rule. It is required that there is synchronisation established 301 between the data- and control-plane of all relevant devices involved. 302 Each complex dynamically constructed tunnel MUST be operational and 303 allow packets to be exchanged between tunnel head- and tail-end 304 before it should be used to redirect traffic. 306 4. Redirect to indirection-id Community 308 This document defines a new BGP extended community known as a 309 Redirect-to-indirection-id extended community. This extended 310 community is a new transitive extended community with the Type and 311 the Sub-Type field to be assigned by IANA. The format of this 312 extended community is show in Figure 1. 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Type | Sub-Type | Flags(1 octet)| Indirection ID| 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Generalized indirection_id | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 1 323 The meaning of the extended community fields are as follows: 325 Type: 1 octet to be assigned by IANA. 327 Sub-Type: 1 octet to be assigned by IANA. 329 Flags: 1 octet field. Following Flags are defined. 331 0 1 332 0 1 2 3 4 5 6 7 333 +-+-+-+-+-+-+-+-+ 334 | RES | TID |C| 335 +-+-+-+-+-+-+-+-+ 337 Figure 2 339 The least-significant Flag bit is defined as the 'C' (or copy) bit. 340 When the 'C' bit is set the redirection applies to copies of the 341 matching packets and not to the original traffic stream. 343 The 'TID' field identifies a 4 bit Table-id field. This field is 344 used to provide the flowspec client an indication how and where to 345 sequence the received indirection-ids to redirecting traffic. TID 346 value 0 indicates that Table-id field is NOT set and SHOULD be 347 ignored. 349 All bits other than the 'C' and 'TID' bits MUST be set to 0 by the 350 originating BGP speaker and ignored by receiving BGP speakers. 352 Indirection ID: 1 octet value. This draft defines following 353 indirection_id Types: 355 0 - Localised ID (The flowspec client uses the received 356 indirection-id to lookup the redirection information in the 357 localised indirection-id table.) 359 1 - Node ID (The flowspec client uses the received indirection-id 360 as a Segment Routing Node ID to redirect traffic towards) 362 6 - Binding Segment ID (The flowspec client uses the received 363 indirection-id as a Segment Routing Binding Segment ID to redirect 364 traffic towards) [I-D.draft-ietf-spring-segment-routing] [6] 366 5. Redirect using localised indirection-id mapping table 368 When a BGP flowspec client receives a flowspec policy route with a 369 'redirect to indirection-id' extended community attached and the 370 route represents the best BGP path, it will install a flowspec 371 traffic filtering rule matching the IP tupples described by the 372 flowpsec NLRI field and consequently redirects the flow (C=0) or 373 copies the flow (C=1) using the information identified by the 374 'redirect-to-indirection-id' community. 376 6. Validation Procedures 378 The validation check described in RFC5575 [2] and revised in [3] 379 SHOULD be applied by default to received flow-spec routes with a 380 'redirect to indirection-id' extended community. This means that a 381 flow-spec route with a destination prefix subcomponent SHOULD NOT be 382 accepted from an EBGP peer unless that peer also advertised the best 383 path for the matching unicast route. 385 While it MUST NOT happen, and is seen as invallid combination, it is 386 possible from a semenatics perspective to have multiple clashing 387 redirect actions defined within a single flowspec rule. For best and 388 consistant RFC5575 flowspec redirect behavior the redirect as 389 documented by RFC5575 MUST not be broken, and hence when a clash 390 occurs, then RFC5575 based redirect SHOULD take priority. 391 Additionally, if the 'redirect to indirection-id' does not result in 392 a valid redirection, then the flowspec rule must be processed as if 393 the 'redirect to indirection-id' community was not attached to the 394 flowspec route and MUST provide an indication within the BGP routing 395 table that the respective 'redirect to indirection-id' resulted in an 396 invalid redirection action. 398 7. Security Considerations 400 A system using 'redirect-to-indirection-id' extended community can 401 cause during the redirect mitigation of a DDoS attack result in 402 overflow of traffic received by the mitigation infrastructure. 404 8. Acknowledgements 406 This document received valuable comments and input from IDR working 407 group including Adam Simpson, Mustapha Aissaoui, Jan Mertens, Robert 408 Raszuk, Jeff Haas, Susan Hares and Lucy Yong. 410 9. Contributor Addresses 412 Below is a list of other contributing authors in alphabetical order: 414 Arjun Sreekantiah 415 Cisco Systems 416 170 W. Tasman Drive 417 San Jose, CA 95134 418 USA 420 Email: asreekan@cisco.com 422 Nan Wu 423 Huawei Technologies 424 Huawei Bld., No. 156 Beiquing Rd 425 Beijing 100095 426 China 428 Email: eric.wu@huawei.com 430 Shunwan Zhuang 431 Huawei Technologies 432 Huawei Bld., No. 156 Beiquing Rd 433 Beijing 100095 434 China 436 Email: zhuangshunwan@huawei.com 438 Wim Henderickx 439 Nokia 440 Antwerp 441 BE 443 Email: wim.henderickx@nokia.com 445 Figure 3 447 10. IANA Considerations 449 This document requests a new type and sub-type for the Redirect to 450 indirection-id Extended community from the "Transitive Extended 451 community" registry. The Type name shall be "Redirect to 452 indirection-id Extended Community" and the Sub-type name shall be 453 'Flow-spec Redirect to 32-bit Path-id'. 455 In addition, this document requests IANA to create a new registry for 456 Redirect to indirection-id Extended Community INDIRECTION-IDs as 457 follows: 459 Under "Transitive Extended Community:" 461 Registry: "Redirect Extended Community indirection_id" 463 Reference: [RFC-To-Be] 465 Registration Procedure(s): First Come, First Served 467 Registry: "Redirect Extended Community indirection_id" 469 Value Code Reference 471 0 Localised ID [RFC-To-Be] 472 1 Node ID [RFC-To-Be] 473 2 Agency ID [RFC-To-Be] 474 3 AS (Autonomous System) ID [RFC-To-Be] 475 4 Anycast ID [RFC-To-Be] 476 5 Multicast ID [RFC-To-Be] 477 6 Tunnel ID (Tunnel Binding ID ) [RFC-To-Be] 478 7 VPN ID [RFC-To-Be] 479 8 OAM ID [RFC-To-Be] 480 9 ECMP (Equal Cost Multi-Path) ID [RFC-To-Be] 481 10 QoS ID [RFC-To-Be] 482 11 Bandwidth-Guarantee ID [RFC-To-Be] 483 12 Security ID [RFC-To-Be] 484 13 Multi-Topology ID [RFC-To-Be] 486 Figure 4 488 11. References 490 11.1. Normative References 492 [1] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", BCP 14, RFC 2119, March 1997, 494 . 496 [2] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 497 and D. McPherson, "Dissemination of Flow Specification 498 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 499 . 501 11.2. Informative References 503 [3] Uttaro, J., Filsfils, C., Alcaide, J., and P. Mohapatra, 504 "Revised Validation Procedure for BGP Flow 505 Specifications", January 2014. 507 [4] Filsfils, C., Previdi, S., Aries, E., Ginsburg, D., and D. 508 Afanasiev, "Segment Routing Centralized Egress Peer 509 Engineering", October 2015. 511 [5] Sreekantiah, A., Filsfils, C., Previdi, S., Sivabalan, S., 512 Mattes, P., and S. Lin, "Segment Routing Traffic 513 Engineering Policy using BGP", October 2015. 515 [6] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 516 Shakir, R., Bashandy, A., Horneffer, M., Henderickx, W., 517 Tantsura, J., Crabbe, E., Milojevic, I., and S. Ytti, 518 "Segment Routing Architecture", December 2015. 520 [7] Sivabalan, S., Medved, M., Filsfils, C., Litkowski, S., 521 Raszuk, R., Bashandy, A., Lopez, V., Tantsura, J., 522 Henderickx, W., Hardwick, J., Milojevic, I., and S. Ytti, 523 "PCEP Extensions for Segment Routing", December 2015. 525 Appendix A. Additional indirection_id types waiting for use-case 526 description 528 This section is a placeholder and collection of potential additional 529 indirection_id types. The current use-cases do not require these 530 particular indirection types, however at later stage when use-cases 531 are identified they may be added to the body of teh draft. 533 2 - Agency ID (The flowspec client uses the received indirection-id 534 as a Segment Routing Agency ID to redirect traffic towards) 536 3 - AS (Autonomous System) ID (The flowspec client uses the received 537 indirection-id as a Segment Routing Autonomous System ID to redirect 538 traffic towards) 540 4 - Anycast ID (The flowspec client uses the received indirection-id 541 as a Segment Routing Anycast ID to redirect traffic towards) 543 5 - Multicast ID (The flowspec client uses the received indirection- 544 id as a Segment Routing Multicast ID to redirect traffic towards) 546 7 - VPN ID (The flowspec client uses the received indirection-id as a 547 Segment Routing VPN ID to redirect traffic towards) 548 8 - OAM ID (The flowspec client uses the received indirection-id as a 549 Segment Routing OAM ID to redirect traffic towards) 551 9 - ECMP (Equal Cost Multi-Path) ID (The flowspec client uses the 552 received indirection-id as a Segment Routing PeerSet ID to redirect 553 traffic towards) 555 10 - QoS ID (The flowspec client uses the received indirection-id as 556 a Segment Routing QoS ID to redirect traffic towards) 558 11 - Bandwidth-Guarantee ID (The flowspec client uses the received 559 indirection-id as a Segment Routing Bandwidth-Guarantee ID to 560 redirect traffic towards) 562 12 - Security ID (The flowspec client uses the received indirection- 563 id as a Segment Routing Security ID to redirect traffic towards) 565 13 - Multi-Topology ID (The flowspec client uses the received 566 indirection-id as a Segment Routing Multi-Topology ID to redirect 567 traffic towards) 569 Authors' Addresses 571 Gunter Van de Velde (editor) 572 Nokia 573 Antwerp 574 BE 576 Email: gunter.van_de_velde@nokia.com 578 Keyur Patel 579 Arrcus 580 USA 582 Email: keyur@arrcus.com 584 Zhenbin Li 585 Huawei Technologies 586 Huawei Bld., No. 156 Beiquing Rd 587 Beijing 100095 588 China 590 Email: lizhenbin@huawei.com