idnits 2.17.1 draft-jiang-idr-ts-flowspec-srv6-policy-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 : ---------------------------------------------------------------------------- ** 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 (July 13, 2020) is 1376 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) == Unused Reference: 'I-D.ietf-idr-segment-routing-te-policy' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-tunnel-encaps' is defined on line 257, but no explicit reference was found in the text == Unused Reference: 'RFC4456' is defined on line 281, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-03 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-idr-flowspec-redirect-ip' == Outdated reference: A later version (-27) exists of draft-ietf-idr-rfc5575bis-25 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-09 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-15 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-07 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). 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: Standards Track China Mobile 5 Expires: January 14, 2021 Y. Gu 6 Huawei 7 July 13, 2020 9 Traffic Steering using BGP Flowspec with SRv6 Policy 10 draft-jiang-idr-ts-flowspec-srv6-policy-00 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 January 14, 2021. 45 Copyright Notice 47 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 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 or multiple SRv6 policies, as well as to indicate specific 164 Tailend functions. 166 4. Application Example 168 In following scenario, BGP FlowSpec Controller signals the function 169 imformation (SRv6 SID: Service_id_x) to the HeadEnd device. 171 +------------+ 172 | BGP FS | 173 | Controller | 174 +------------+ 175 | Flowspec route to HeadEnd: 176 | NLRI: Filter Rules 177 | Redirect to IPv6 Nexthop: TailEnd's Address 178 | Policy Color: C1 179 | PrefixSID: Service_id_x 180 | .-----. 181 | ( ) 182 V .--( )--. 183 +-------+ ( ) +-------+ 184 | |_( SRv6 Core Network )_| | 185 |HeadEnd| ( ================> ) |TailEnd| 186 +-------+ (SR List) +-------+ 187 '--( )--' Service SID: Service_id_x 188 ( ) (e.g.: End.DT4 or End.DT6 or others) 189 '-----' 191 Figure 1: Steering the Flow into SRv6 Policy 193 When the headend device (as a Flowspec client) receives such 194 instructions, it will steer the flows matching the criteria in the 195 Flowspec route into the SRv6 Policy matching the tuple (Endpoint: 196 TailEnd's Address, Color: C1). And the packets of such flows will be 197 encapsulated with SRH using the SR List. 198 When the packets reach to the TailEnd device, they will be further 199 processed per the function denoted by the Service_id_x. 201 5. IANA Considerations 203 TBD 205 6. Security Considerations 207 This document does not change the security properties of SRv6 and 208 BGP. 210 7. Contributors 212 The following people made significant contributions to this document: 214 Shunwan Zhaung 215 Huawei 216 Email: zhuangshunwan@huawei.com 218 Haibo Wang 219 Huawei 220 Email: rainsword.wang@huawei.com 222 Jie Dong 223 Huawei 224 Email: jie.dong@huawei.com 226 8. Acknowledgements 228 TBD 230 9. References 232 9.1. Normative References 234 [I-D.ietf-bess-srv6-services] 235 Dawra, G., Filsfils, C., Raszuk, R., Decraene, B., Zhuang, 236 S., and J. Rabadan, "SRv6 BGP based Overlay services", 237 draft-ietf-bess-srv6-services-03 (work in progress), July 238 2020. 240 [I-D.ietf-idr-flowspec-redirect-ip] 241 Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., 242 Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to 243 IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work 244 in progress), February 2015. 246 [I-D.ietf-idr-rfc5575bis] 247 Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 248 Bacher, "Dissemination of Flow Specification Rules", 249 draft-ietf-idr-rfc5575bis-25 (work in progress), May 2020. 251 [I-D.ietf-idr-segment-routing-te-policy] 252 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 253 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 254 Routing Policies in BGP", draft-ietf-idr-segment-routing- 255 te-policy-09 (work in progress), May 2020. 257 [I-D.ietf-idr-tunnel-encaps] 258 Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel 259 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15 260 (work in progress), December 2019. 262 [I-D.ietf-spring-segment-routing-policy] 263 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 264 P. Mattes, "Segment Routing Policy Architecture", draft- 265 ietf-spring-segment-routing-policy-07 (work in progress), 266 May 2020. 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, 270 DOI 10.17487/RFC2119, March 1997, 271 . 273 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 274 A., and H. Gredler, "Segment Routing Prefix Segment 275 Identifier Extensions for BGP", RFC 8669, 276 DOI 10.17487/RFC8669, December 2019, 277 . 279 9.2. Informative References 281 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 282 Reflection: An Alternative to Full Mesh Internal BGP 283 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 284 . 286 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 287 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 288 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 289 . 291 Authors' Addresses 293 Wenying Jiang 294 China Mobile 295 Beijing 296 China 298 Email: jiangwenying@chinamobile.com 300 Yisong Liu 301 China Mobile 302 Beijing 303 China 305 Email: liuyisong@chinamobile.com 306 Yunan Gu 307 Huawei 308 Beijing 309 China 311 Email: guyunan@huawei.com