idnits 2.17.1 draft-jiang-idr-ts-flowspec-srv6-policy-03.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 ([I-D.ietf-idr-RFC5575bis]), 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 22, 2021) is 1131 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 275, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-tunnel-encaps' is defined on line 281, but no explicit reference was found in the text == Unused Reference: 'RFC4456' is defined on line 305, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-05 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-11 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-21 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. J 3 Internet-Draft Y. Liu 4 Intended status: Informational China Mobile 5 Expires: August 26, 2021 S. Chen 6 Huawei 7 February 22, 2021 9 Traffic Steering using BGP Flowspec with SRv6 Policy 10 draft-jiang-idr-ts-flowspec-srv6-policy-03 12 Abstract 14 BGP Flow Specification (FlowSpec) [I-D.ietf-idr-rfc5575bis] has been 15 proposed to distribute BGP FlowSpec NLRI to FlowSpec clients to 16 mitigate (distributed) denial-of-service attacks, and to provide 17 traffic filtering in the context of a BGP/MPLS VPN service. 18 Recently, traffic steering applications in the context of SRv6 using 19 FlowSpec aslo attract attention. This document introduces the usage 20 of BGP FlowSpec to steer packets into an SRv6 Policy. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 26, 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 64 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Application Example . . . . . . . . . . . . . . . . . . . . . 4 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 9.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 Segment Routing IPv6 (SRv6) is a protocol designed to forward IPv6 78 data packets on a network using the source routing model. SRv6 79 enables the ingress to add a segment routing header (SRH) [RFC8754] 80 to an IPv6 packet and push an explicit IPv6 address stack into the 81 SRH. After receiving the packet, each transit node updates the IPv6 82 destination IP address in the packet and segment list to implement 83 hop-by-hop forwarding. 85 SRv6 Policy [I-D.ietf-spring-segment-routing-policy] is a tunneling 86 technology developed based on SRv6. An SRv6 Policy is a set of 87 candidate paths consisting of one or more segment lists, that is, 88 segment ID (SID) lists. Each SID list identifies an end-to-end path 89 from the source to the destination, instructing a device to forward 90 traffic through the path rather than the shortest path computed using 91 an IGP. The header of a packet steered into an SRv6 Policy is 92 augmented with an ordered list of segments associated with that SRv6 93 Policy, so that other devices on the network can execute the 94 instructions encapsulated into the list. 96 The headend of an SRv6 Policy may learn multiple candidate paths for 97 an SRv6 Policy. Candidate paths may be learned via a number of 98 different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. 100 [I-D.ietf-idr-rfc5575bis] defines the flow specification (FlowSpec) 101 that allows to convey flow specifications and traffic Action/Rules 102 associated (rate- limiting, redirect, remark ...). BGP Flow 103 specifications are encoded within the MP_REACH_NLRI and 104 MP_UNREACH_NLRI attributes. Rules (Actions associated) are encoded 105 in Extended Community attribute. The BGP Flow Specification function 106 allows BGP Flow Specification routes that carry traffic policies to 107 be transmitted to BGP Flow Specification peers to steer traffic. 109 This document proposes BGP flow specification usage that are used to 110 steer data flow into an SRv6 Policy as well as to indicate Tailend 111 function. 113 2. Definitions and Acronyms 115 o FlowSpec: Flow Specification 117 o SR: Segment Routing 119 o SRv6: IPv6 Segment Routing 121 o SID: Segment Identifier 123 o SRH: Segment Routing Header 125 o TE: Traffic Engineering 127 3. Operations 129 An SRv6 Policy [I-D.ietf-spring-segment-routing-policy] is identified 130 through the tuple . In the context of a 131 specific headend, one may identify an SRv6 policy by the tuple. The headend is the node where the SRv6 policy is 133 instantiated/implemented. The headend is specified as an IPv4 or 134 IPv6 address and is expected to be unique in the domain. The 135 endpoint indicates the destination of the SRv6 policy. The endpoint 136 is specified as an IPv6 address and is expected to be unique in the 137 domain. The color is a 32-bit numerical value that associates the 138 SRv6 Policy, and it defines an application-level network Service 139 Level Agreement (SLA) policy. 141 Assume one or multiple SRv6 Policies are already setup in the SRv6 142 HeadEnd device. In order to steer traffic into a specific SRv6 143 policy at the Headend, one can use the SRv6 color extended community 144 and endpoint to map to a satisfying SRv6 policy, and steer traffic 145 into this specific policy. 147 [I-D.ietf-idr-flowspec-redirect-ip] defines the redirect to IPv4 and 148 IPv6 Next-hop action. The IPv6 next-hop address in the FlowSpec NLRI 149 can be used to specify the endpoint of the SRv6 Policy. When the 150 packets reach to the TailEnd device, some specific function 151 imformation identifiers can be used decide how to further process the 152 flows. Several endpoint functions are already defined, e.g., 153 End.DT6: Endpoint with decapsulation and IPv6 table lookup, and 154 End.DX6: Endpoint with decapsulation and IPv6 cross-connect. The BGP 155 Prefix-SID defined in [RFC8669] is utilized to enable SRv6 VPN 156 services [I-D.ietf-bess-srv6-services]. SRv6 Services TLVs within 157 the BGP Prefix-SID Attribute can be used to indicate the endpoint 158 functions. 160 This document proposes to carry the Color Extended Community and BGP 161 Prefix-SID Attribute in the context of a Flowspec NLRI 162 [I-D.ietf-idr-rfc5575bis] to an SRv6 Headend to steer traffic into 163 one SRv6 policy, as well as to indicate specific Tailend functions. 165 In this document, the usage of at most one Color Extended Community 166 in combination at most one BGP Prefix SID Attribute is discussed. 167 For the case that a flowspec route carries multiple Color Extend 168 Communities and/or a BGP Prefix SID Attribute, a protocol extension 169 to Flowspec is required, and is thus out of the scope of this 170 document. 172 However, the method proposed in this document still supports load 173 balancing to the tailend device. To achieve that, the headend device 174 CAN set up multiple paths in one SRv6 policy, and use a Flowspec 175 route to indicate the specific SRv6 policy. 177 4. Application Example 179 In following scenario, BGP FlowSpec Controller signals the function 180 imformation (SRv6 SID: Service_id_x) to the HeadEnd device. 182 +------------+ 183 | BGP FS | 184 | Controller | 185 +------------+ 186 | Flowspec route to HeadEnd: 187 | NLRI: Filter Rules 188 | Redirect to IPv6 Nexthop: TailEnd's Address 189 | Policy Color: C1 190 | PrefixSID: Service_id_x 191 | .-----. 192 | ( ) 193 V .--( )--. 194 +-------+ ( ) +-------+ 195 | |_( SRv6 Core Network )_| | 196 |HeadEnd| ( ================> ) |TailEnd| 197 +-------+ (SR List) +-------+ 198 '--( )--' Service SID: Service_id_x 199 ( ) (e.g.: End.DT4 or End.DT6 or others) 200 '-----' 202 Figure 1: Steering the Flow into SRv6 Policy 204 When the headend device (as a Flowspec client) receives such 205 instructions, it will steer the flows matching the criteria in the 206 Flowspec route into the SRv6 Policy matching the tuple (Endpoint: 207 TailEnd's Address, Color: C1). And the packets of such flows will be 208 encapsulated with SRH using the SR List. 209 When the packets reach to the TailEnd device, they will be further 210 procetssed per the function denoted by the Service_id_x. 212 For the cases of intra-AS and inter-AS traffic steering using this 213 method, the usages of Flowspec Color Extended Community with BGP 214 prefix SID are the same for both scenarios. The difference lie 215 between the local SRv6 policy configurations. For the inter-domain 216 case, the operator can configure an inter-domain SRv6 policy/path at 217 the Headend device. For the intra-domain case, the operator can 218 configure an intra-domain SRv6 policy/path at the Headend device. 220 5. IANA Considerations 222 No IANA actions are required for this document. 224 6. Security Considerations 226 This document does not change the security properties of SRv6 and 227 BGP. 229 7. Contributors 231 The following people made significant contributions to this document: 233 Yunan Gu 234 Huawei 235 Email: guyunan@huawei.com 237 Shunwan Zhaung 238 Huawei 239 Email: zhuangshunwan@huawei.com 241 Haibo Wang 242 Huawei 243 Email: rainsword.wang@huawei.com 245 Jie Dong 246 Huawei 247 Email: jie.dong@huawei.com 249 8. Acknowledgements 251 TBD. 253 9. References 255 9.1. Normative References 257 [I-D.ietf-bess-srv6-services] 258 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 259 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 260 Overlay services", draft-ietf-bess-srv6-services-05 (work 261 in progress), November 2020. 263 [I-D.ietf-idr-flowspec-redirect-ip] 264 Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., 265 Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to 266 IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work 267 in progress), February 2015. 269 [I-D.ietf-idr-rfc5575bis] 270 Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 271 Bacher, "Dissemination of Flow Specification Rules", 272 draft-ietf-idr-rfc5575bis-27 (work in progress), October 273 2020. 275 [I-D.ietf-idr-segment-routing-te-policy] 276 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 277 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 278 Routing Policies in BGP", draft-ietf-idr-segment-routing- 279 te-policy-11 (work in progress), November 2020. 281 [I-D.ietf-idr-tunnel-encaps] 282 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 283 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 284 encaps-21 (work in progress), January 2021. 286 [I-D.ietf-spring-segment-routing-policy] 287 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 288 P. Mattes, "Segment Routing Policy Architecture", draft- 289 ietf-spring-segment-routing-policy-09 (work in progress), 290 November 2020. 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, 294 DOI 10.17487/RFC2119, March 1997, 295 . 297 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 298 A., and H. Gredler, "Segment Routing Prefix Segment 299 Identifier Extensions for BGP", RFC 8669, 300 DOI 10.17487/RFC8669, December 2019, 301 . 303 9.2. Informative References 305 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 306 Reflection: An Alternative to Full Mesh Internal BGP 307 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 308 . 310 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 311 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 312 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 313 . 315 Authors' Addresses 317 Wenying Jiang 318 China Mobile 319 Beijing 320 China 322 Email: jiangwenying@chinamobile.com 323 Yisong Liu 324 China Mobile 325 Beijing 326 China 328 Email: liuyisong@chinamobile.com 330 Shuanglong Chen 331 Huawei 332 Beijing 333 China 335 Email: chenshuanglong@huawei.com