idnits 2.17.1 draft-jiang-idr-ts-flowspec-srv6-policy-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8955], [RFC8956]), 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 -- The document date (March 23, 2022) is 764 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-idr-segment-routing-te-policy' is defined on line 367, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-tunnel-encaps' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'RFC4456' is defined on line 407, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-16 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Jiang 3 Internet-Draft Y. Liu 4 Intended status: Informational China Mobile 5 Expires: September 24, 2022 S. Chen 6 S. Zhuang 7 Huawei 8 March 23, 2022 10 Traffic Steering using BGP Flowspec with SRv6 Policy 11 draft-jiang-idr-ts-flowspec-srv6-policy-07 13 Abstract 15 BGP Flow Specification (FlowSpec) [RFC8955] [RFC8956] has been 16 proposed to distribute BGP FlowSpec NLRI to FlowSpec clients to 17 mitigate (distributed) denial-of-service attacks, and to provide 18 traffic filtering in the context of a BGP/MPLS VPN service. 19 Recently, traffic steering applications in the context of SRv6 using 20 FlowSpec aslo attract attention. This document introduces the usage 21 of BGP FlowSpec to steer packets into an SRv6 Policy. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 24, 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 65 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Application Example . . . . . . . . . . . . . . . . . . . . . 4 67 5. Running Code . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5.1. Interop-test Status . . . . . . . . . . . . . . . . . . . 7 69 5.2. Deployment Status . . . . . . . . . . . . . . . . . . . . 7 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 10.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 Segment Routing IPv6 (SRv6) is a protocol designed to forward IPv6 82 data packets on a network using the source routing model. SRv6 83 enables the ingress to add a segment routing header (SRH) [RFC8754] 84 to an IPv6 packet and push an explicit IPv6 address stack into the 85 SRH. After receiving the packet, each transit node updates the IPv6 86 destination IP address in the packet and segment list to implement 87 hop-by-hop forwarding. 89 SRv6 Policy [I-D.ietf-spring-segment-routing-policy] is a tunneling 90 technology developed based on SRv6. An SRv6 Policy is a set of 91 candidate paths consisting of one or more segment lists, that is, 92 segment ID (SID) lists. Each SID list identifies an end-to-end path 93 from the source to the destination, instructing a device to forward 94 traffic through the path rather than the shortest path computed using 95 an IGP. The header of a packet steered into an SRv6 Policy is 96 augmented with an ordered list of segments associated with that SRv6 97 Policy, so that other devices on the network can execute the 98 instructions encapsulated into the list. 100 The headend of an SRv6 Policy may learn multiple candidate paths for 101 an SRv6 Policy. Candidate paths may be learned via a number of 102 different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. 104 [RFC8955] [RFC8956] defines the flow specification (FlowSpec) that 105 allows to convey flow specifications and traffic Action/Rules 106 associated (rate- limiting, redirect, remark ...). BGP Flow 107 specifications are encoded within the MP_REACH_NLRI and 108 MP_UNREACH_NLRI attributes. Rules (Actions associated) are encoded 109 in Extended Community attribute. The BGP Flow Specification function 110 allows BGP Flow Specification routes that carry traffic policies to 111 be transmitted to BGP Flow Specification peers to steer traffic. 113 This document proposes BGP flow specification usage that are used to 114 steer data flow into an SRv6 Policy as well as to indicate Tailend 115 function. 117 2. Definitions and Acronyms 119 o FlowSpec: Flow Specification 121 o SR: Segment Routing 123 o SRv6: IPv6 Segment Routing 125 o SID: Segment Identifier 127 o SRH: Segment Routing Header 129 o TE: Traffic Engineering 131 3. Operations 133 An SRv6 Policy [I-D.ietf-spring-segment-routing-policy] is identified 134 through the tuple . In the context of a 135 specific headend, one may identify an SRv6 policy by the tuple. The headend is the node where the SRv6 policy is 137 instantiated/implemented. The headend is specified as an IPv4 or 138 IPv6 address and is expected to be unique in the domain. The 139 endpoint indicates the destination of the SRv6 policy. The endpoint 140 is specified as an IPv6 address and is expected to be unique in the 141 domain. The color is a 32-bit numerical value that associates the 142 SRv6 Policy, and it defines an application-level network Service 143 Level Agreement (SLA) policy. 145 Assume one or multiple SRv6 Policies are already setup in the SRv6 146 HeadEnd device. In order to steer traffic into a specific SRv6 147 policy at the Headend, one can use the SRv6 color extended community 148 and endpoint to map to a satisfying SRv6 policy, and steer traffic 149 into this specific policy. 151 [I-D.ietf-idr-flowspec-redirect-ip] defines the redirect to IPv4 and 152 IPv6 Next-hop action. The IPv6 next-hop address in the Flow-spec 153 Redirect to IPv6 Extended Community can be used to specify the 154 endpoint of the SRv6 Policy. When the packets reach to the TailEnd 155 device, some specific function imformation identifiers can be used 156 decide how to further process the flows. Several endpoint functions 157 are already defined, e.g., End.DT6: Endpoint with decapsulation and 158 IPv6 table lookup, and End.DX6: Endpoint with decapsulation and IPv6 159 cross-connect. The BGP Prefix-SID defined in [RFC8669] is utilized 160 to enable SRv6 VPN services [I-D.ietf-bess-srv6-services]. SRv6 161 Services TLVs within the BGP Prefix-SID Attribute can be used to 162 indicate the endpoint functions. 164 This document proposes to carry the Color Extended Community and BGP 165 Prefix-SID Attribute in the context of a Flowspec NLRI [RFC8955] 166 [RFC8956] to an SRv6 Headend to steer traffic into one SRv6 policy, 167 as well as to indicate specific Tailend functions. 169 In this document, the usage of at most one Color Extended Community 170 in combination at most one BGP Prefix SID Attribute is discussed. 171 For the case that a flowspec route carries multiple Color Extend 172 Communities and/or a BGP Prefix SID Attribute, a protocol extension 173 to Flowspec is required, and is thus out of the scope of this 174 document. 176 However, the method proposed in this document still supports load 177 balancing to the tailend device. To achieve that, the headend device 178 CAN set up multiple paths in one SRv6 policy, and use a Flowspec 179 route to indicate the specific SRv6 policy. 181 4. Application Example 183 In following scenario, BGP FlowSpec Controller signals the filter 184 rules, the redirect action, the policy color and the function 185 imformation (SRv6 SID: Service_id_x) to the HeadEnd device. 187 +------------+ 188 | BGP FS | 189 | Controller | 190 +------------+ 191 | Flowspec route to HeadEnd: 192 | NLRI: Filter Rules 193 | Redirect to IPv6 Nexthop: TailEnd's Address 194 | Policy Color: C1 195 | PrefixSID: Service_id_x 196 | .-----. 197 | ( ) 198 V .--( )--. 199 +-------+ ( ) +-------+ 200 | |_( SRv6 Core Network )_| | 201 |HeadEnd| ( ================> ) |TailEnd| 202 +-------+ (SR List) +-------+ 203 '--( )--' Service SID: Service_id_x 204 ( ) (e.g.: End.DT4 or End.DT6 or others) 205 '-----' 207 Figure 1: Steering the Flow into SRv6 Policy (Option 1) 209 When the HeadEnd device (as a Flowspec client) receives such 210 instructions, it will steer the flows matching the criteria in the 211 Flowspec route into the SRv6 Policy matching the tuple (Endpoint: 212 TailEnd's Address, Color: C1). And the packets of such flows will be 213 encapsulated with SRH using the SR List. 214 When the packets reach to the TailEnd device, they will be further 215 procetssed per the function denoted by the Service_id_x. 217 When the HeadEnd device determines (with the help of SRv6 SID 218 Structure) that the Service SID belongs to the same SRv6 Locator as 219 the last SRv6 SID of the TailEnd device in the SRv6 Policy segment 220 list, it MAY exclude that last SRv6 SID when steering the service 221 flow. For example, the effective segment list of the SRv6 Policy 222 associated with SID list would be . 225 If the last SRv6 SID (For example, S3 we use here) of the TailEnd 226 device in the SRv6 Policy segment list is USD-flavored, an SRv6 227 Service SID (e.g., End.DT4 or End.DT6) is not required when BGP 228 FlowSpec Controller send the FlowSpec route to the HeadEnd device (as 229 a Flowspec client). 231 +------------+ 232 | BGP FS | 233 | Controller | 234 +------------+ 235 | Flowspec route to HeadEnd: 236 | NLRI: Filter Rules 237 | Redirect to IPv6 Nexthop: TailEnd's Address 238 | Policy Color: C2 239 | .-----. 240 | ( ) 241 V .--( )--. 242 +-------+ ( ) +-------+ 243 | |_( SRv6 Core Network )_| | 244 |HeadEnd| ( ================> ) |TailEnd| 245 +-------+ (SR List) +-------+ 246 '--( )--' 247 ( ) 248 '-----' 249 Note: S3 MUST be a USD-flavored SRv6 SID of the TailEnd 251 Figure 2: Steering the Flow into SRv6 Policy (Option 2) 253 When the HeadEnd device (as a Flowspec client) receives such 254 instructions, it will steer the flows matching the criteria in the 255 Flowspec route into the SRv6 Policy matching the tuple (Endpoint: 256 TailEnd's Address, Color: C2). And the packets of such flows will be 257 encapsulated with SRH using the SR List. When the 258 packets reach to the TailEnd device, they will be further procetssed 259 per the function denoted by the USD-flavored SRv6 SID S3. 261 At this point, the work discusses the matching of global routing 262 table prefixes. 264 For the cases of intra-AS and inter-AS traffic steering using this 265 method, the usages of Flowspec Color Extended Community with BGP 266 prefix SID are the same for both scenarios. The difference lie 267 between the local SRv6 policy configurations. For the inter-domain 268 case, the operator can configure an inter-domain SRv6 policy/path at 269 the Headend device. For the intra-domain case, the operator can 270 configure an intra-domain SRv6 policy/path at the Headend device. 272 . 274 5. Running Code 276 5.1. Interop-test Status 278 The Traffic Steering using BGP Flowspec with SRv6 Policy mechanism 279 has been implemented on the following hardware devices, software 280 implementations and SDN controllers. They had also successfully 281 participated in the series of joint interoperability testing events 282 hosted by China Mobile from July 2021 to October 2021. The following 283 hardware devices and software implementations had successfully passed 284 the interoperability testing (in alphabetical order). 286 Routers: 287 ----------------------------------------------------------- 288 | Vendors | Device Model | Version | 289 ----------------------------------------------------------- 290 | Huawei | NE40-X8A | NE40E V800R021C00SPC091T | 291 ----------------------------------------------------------- 292 | New H3C | CR16010H-FA | Version 7.1.075, ESS 8305 | 293 ----------------------------------------------------------- 294 | Ruijie | RG-N8010-R | N8000-R_RGOS 12.8(1)B08T1 | 295 ----------------------------------------------------------- 296 | ZTE | M6000-8S Plus | V5.00.10(5.60.5) | 297 ----------------------------------------------------------- 299 Controllers: 300 ----------------------------------------------------------- 301 | Vendors | Device Model | Version | 302 ----------------------------------------------------------- 303 | China Unitecs | I-T-E SC | V1.3.6P3 | 304 ----------------------------------------------------------- 305 | Huawei | NCE-IP | V100R021C00 | 306 ----------------------------------------------------------- 307 | Ruijie | RG-ONC-AIO-H | RG-ION-WAN-CLOUD_2.00T1 | 308 ----------------------------------------------------------- 309 | ZTE | ZENIC ONE | R22V16.21.20 | 310 ----------------------------------------------------------- 312 5.2. Deployment Status 314 TBD 316 6. IANA Considerations 318 No IANA actions are required for this document. 320 7. Security Considerations 322 This document does not change the security properties of SRv6 and 323 BGP. 325 8. Contributors 327 The following people made significant contributions to this document: 329 Yunan Gu 330 Huawei 331 Email: guyunan@huawei.com 333 Haibo Wang 334 Huawei 335 Email: rainsword.wang@huawei.com 337 Jie Dong 338 Huawei 339 Email: jie.dong@huawei.com 341 Xue Yang 342 China Mobile 343 Email: yangxuewl@chinamobile.com 345 9. Acknowledgements 347 The authors would like to acknowledge the review and inputs from 348 Jeffrey Haas, Kaliraj Vairavakkalai, Robin Li, Acee Lindem, Gunter 349 Van De Velde, John Scudder, Rainbow Wu and Gang Yang. 351 10. References 353 10.1. Normative References 355 [I-D.ietf-bess-srv6-services] 356 Dawra, G., Talaulikar, K., Raszuk, R., Decraene, B., 357 Zhuang, S., and J. Rabadan, "SRv6 BGP based Overlay 358 Services", draft-ietf-bess-srv6-services-15 (work in 359 progress), March 2022. 361 [I-D.ietf-idr-flowspec-redirect-ip] 362 Uttaro, J., Haas, J., Texier, M., Karch, A., Ray, S., 363 Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to 364 IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work 365 in progress), February 2015. 367 [I-D.ietf-idr-segment-routing-te-policy] 368 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 369 Jain, D., and S. Lin, "Advertising Segment Routing 370 Policies in BGP", draft-ietf-idr-segment-routing-te- 371 policy-16 (work in progress), March 2022. 373 [I-D.ietf-idr-tunnel-encaps] 374 Patel, K., Velde, G. V. D., Sangli, S. R., and J. Scudder, 375 "The BGP Tunnel Encapsulation Attribute", draft-ietf-idr- 376 tunnel-encaps-22 (work in progress), January 2021. 378 [I-D.ietf-spring-segment-routing-policy] 379 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 380 P. Mattes, "Segment Routing Policy Architecture", draft- 381 ietf-spring-segment-routing-policy-22 (work in progress), 382 March 2022. 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, 386 DOI 10.17487/RFC2119, March 1997, 387 . 389 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 390 A., and H. Gredler, "Segment Routing Prefix Segment 391 Identifier Extensions for BGP", RFC 8669, 392 DOI 10.17487/RFC8669, December 2019, 393 . 395 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 396 Bacher, "Dissemination of Flow Specification Rules", 397 RFC 8955, DOI 10.17487/RFC8955, December 2020, 398 . 400 [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., 401 "Dissemination of Flow Specification Rules for IPv6", 402 RFC 8956, DOI 10.17487/RFC8956, December 2020, 403 . 405 10.2. Informative References 407 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 408 Reflection: An Alternative to Full Mesh Internal BGP 409 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 410 . 412 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 413 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 414 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 415 . 417 Authors' Addresses 419 Wenying Jiang 420 China Mobile 421 Beijing 422 China 424 Email: jiangwenying@chinamobile.com 426 Yisong Liu 427 China Mobile 428 Beijing 429 China 431 Email: liuyisong@chinamobile.com 433 Shuanglong Chen 434 Huawei 435 Beijing 436 China 438 Email: chenshuanglong@huawei.com 440 Shunwan Zhuang 441 Huawei 442 Beijing 443 China 445 Email: zhuangshunwan@huawei.com