idnits 2.17.1 draft-li-idr-flowspec-srv6-05.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 29, 2021) is 1122 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: '0' on line 121 -- Looks like a reference, but probably isn't: '1' on line 123 == Outdated reference: A later version (-23) exists of draft-ietf-idr-flowspec-l2vpn-16 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft L. Li 4 Intended status: Standards Track Huawei 5 Expires: September 30, 2021 H. Chen 6 Futurewei 7 C. Loibl 8 Next Layer Communications 9 G. Mishra 10 Verizon Inc. 11 Y. Fan 12 Casa Systems 13 Y. Zhu 14 China Telecom 15 L. Liu 16 Fujitsu 17 X. Liu 18 Volta Networks 19 March 29, 2021 21 BGP Flow Specification for SRv6 22 draft-li-idr-flowspec-srv6-05 24 Abstract 26 This document proposes extensions to BGP Flow Specification for SRv6 27 for filtering SRv6 packets that match a sequence of conditions. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on September 30, 2021. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 70 3. The Flow Specification Encoding for SRv6 . . . . . . . . . . 4 71 3.1. Type TBD1 - Whole SID . . . . . . . . . . . . . . . . . . 4 72 3.2. Type TBD2 - Some bits of SID . . . . . . . . . . . . . . 5 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 75 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 78 7.2. Informative References . . . . . . . . . . . . . . . . . 7 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 81 1. Introduction 83 [RFC8955] describes in details about a new BGP NLRI to distribute a 84 flow specification, which is an n-tuple comprising a sequence of 85 matching criteria that can be applied to IP traffic. [RFC8956] 86 extends [RFC8955] to make it also usable and applicable to IPv6 data 87 packets. [I-D.ietf-idr-flowspec-l2vpn] extends the flow-spec rules 88 for layer 2 Ethernet packets. 90 Segment Routing (SR) for unicast traffic has been proposed to cope 91 with the usecases in traffic engineering, fast re-reroute, service 92 chain, etc. SR architecture can be implemented over an IPv6 data 93 plane using a new type of Segment Routing Header (SRH) 94 [I-D.ietf-6man-segment-routing-header]. SRv6 Network Programming 95 [RFC8986] defines the SRv6 network programming concept and its most 96 basic functions. An SRv6 SID may have the form of LOC:FUNCT:ARGS::. 98 LOC: Each operator is free to use the locator length it chooses. 99 Most often the LOC part of the SID is routable and leads to the node 100 which instantiates that SID. 102 FUNCT: The FUNCT part of the SID is an opaque identification of a 103 local function bound to the SID. (e.g. End: Endpoint, End.X, End.T, 104 End.DX2 etc.). 106 ARGS: A function may require additional arguments that would be 107 placed immediately after the FUNCT. 109 This document specifies two new BGP Flow Specification (FS) component 110 types to support Segment Routing over IPv6 data plane (SRv6) 111 filtering. The match field is destination address of IPv6 header, 112 but it's a SID copy from SRH rather than a traditional IPv6 address 113 (refer to Figure 1). 115 +-----------------------------+ 116 IPv6 Header| SA | DA |<--Match field of this document 117 +--------------------^--------+ 118 | 119 +--------------------|--------+ 120 | +-------------+ | +-------------------+ 121 | | Segment[0] +-------> Loc | Func | Args | 122 | +-------------+ | +-------------------+ 123 | | Segment[1] | | 124 | +-------------+ | 125 | | ... | | 126 SR Header| +-------------+ | 127 | | Segment[n] | | 128 | +-------------+ | 129 | +-------------+ | 130 | ~ Option TLV ~ | 131 | +-------------+ | 132 +-----------------------------+ 134 Figure 1: Match Field 136 2. Definitions and Acronyms 138 o FS: Flow Specification 140 o BGP-FS: Border Gateway Protocol (BGP) Flow Specification (FS) 142 o SR: Segment Routing 144 o SRH: SR Header. 146 o SRv6: IPv6 Segment Routing, SRv6 is a method of forwarding IPv6 147 packets on the network based on the concept of source routing. 149 o SID: Segment Identifier 151 o BSID: Binding SID 153 3. The Flow Specification Encoding for SRv6 155 The Flow Specification NLRI-type consists of several optional 156 components, each of which begins with a type field (1 octet) followed 157 by a variable length parameter. 13 component types are defined in 158 [RFC8955] and [RFC8956] for IPv4 and IPv6. This document defines two 159 new component types for SRv6. 161 3.1. Type TBD1 - Whole SID 163 Encoding: 165 Contains a list of {operator, value} pairs that are used to match the 166 SID/binding SID or a range of whole SID. 168 The operator byte is encoded as: 170 0 1 2 3 4 5 6 7 171 +---+---+---+---+---+---+---+---+ 172 | e | a | 0 | 0 | 0 |lt |gt |eq | 173 +---+---+---+---+---+---+---+---+ 175 Where: 177 e - end-of-list bit. Set in the last {op, value} pair in the 178 sequence. 180 a - AND bit. If unset, the previous term is logically ORed with the 181 current one. If set, the operation is a logical AND. It should be 182 unset in the first operator byte of a sequence. The AND operator has 183 higher priority than OR for the purposes of evaluating logical 184 expressions. 186 0 - SHOULD be set to 0 on NLRI encoding, and MUST be ignored during 187 decoding. 189 lt - less than comparison between data and value. 191 gt - greater than comparison between data and value. 193 eq - equality between data and value. 195 The bits lt, gt, and eq can be combined to match the SID or a range 196 of SID (e.g. less than SID1 and greater than SID2). 198 The value field is encoded as: 200 0 1 2 3 201 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 202 +---------------------------------------------------------------+ 203 ~ SID(128bits) ~ 204 +---------------------------------------------------------------+ 206 The format of SID is described in 207 [I-D.ietf-6man-segment-routing-header] and [RFC8986] 209 3.2. Type TBD2 - Some bits of SID 211 For some scenarios route policy with the whole 128 bits SID matching 212 is too long and not necessary. [RFC8986] defines the format of SID 213 is LOC:FUNCT:ARGS::. In some scenarios, traffic packets can just 214 match Locator, Function ID, Argument or some combinations of these 215 different fields rather than whole 128 bits SID. In order to match 216 the Function ID (FUNCT), the Locator (LOC) needs to be examined and 217 matched first. The new component type TBD2 defined below is for 218 matching some bits of SID. 220 Encoding: 222 Contains a list of {operator, value} pairs that are used to match 223 some bits of SID. 225 The operator byte is encoded as: 227 0 1 2 3 4 5 6 7 228 +---+---+---+---+---+---+---+---+ 229 | e | a | field type|lt |gt |eq | 230 +---+---+---+---+---+---+---+---+ 232 Where: 234 e and a are the same as defined in Section "Type TBD1 - Whole SID". 236 field type: 238 000 : SID's LOC bits 240 001 : SID's FUNCT bits 242 010 : SID's LOC:FUNCT bits 243 011 : SID's FUNCT:ARGS bits 245 lt - less than comparison between data' and value'. 247 gt - greater than comparison between data' and value'. 249 eq - equality between data' and value'. 251 The data' and value' used in lt, gt and eq are indicated by the field 252 type in a operator and its corresponding length in the value field 253 following the operator. 255 The value field is encoded below as the lengths in bits of LOC, FUNCT 256 and ARGS followed by the SID rounding up to bytes: 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | LOC Length | FUNCT Length | ARGS Length | SID | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 ~ SID(continue) ~ 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Where: 268 LOC Length : 1-octet field indicating the length in bits of LOC in 269 SID. 271 FUNCT Length : 1-octet field indicating the length in bits of FUNCT 272 in SID. 274 ARGS Length : 1-octet field indicating the length in bits of ARGS in 275 SID. 277 SID : the SID containing LOC, FUNCT and ARGS, and rounding up to 278 bytes. 280 4. Security Considerations 282 No new security issues are introduced to the BGP protocol by this 283 specification over the security considerations in [RFC8955] and 284 [RFC8956]. 286 5. IANA Considerations 288 This section complies with [RFC7153]. 290 Under "Flow Spec IPv6 Component Types" registry, IANA is requested to 291 assign the following values: 293 +-----------+-------------------+----------------+ 294 | Value | Name | Reference | 295 +-----------+-------------------+----------------+ 296 | TBD1 (14) | Whole SID | This Document | 297 +-----------+-------------------+----------------+ 298 | TBD2 (15) | Some bits of SID | This Document | 299 +-----------+-------------------+----------------+ 301 6. Acknowledgments 303 The authors would like to thank Joel Halpern, Shunwan Zhuang and 304 Rainsword Wang for their valuable suggestions and comments on this 305 draft. 307 7. References 309 7.1. Normative References 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, 313 DOI 10.17487/RFC2119, March 1997, 314 . 316 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 317 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 318 March 2014, . 320 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 321 Bacher, "Dissemination of Flow Specification Rules", 322 RFC 8955, DOI 10.17487/RFC8955, December 2020, 323 . 325 [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., 326 "Dissemination of Flow Specification Rules for IPv6", 327 RFC 8956, DOI 10.17487/RFC8956, December 2020, 328 . 330 7.2. Informative References 332 [I-D.ietf-6man-segment-routing-header] 333 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 334 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 335 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 336 progress), October 2019. 338 [I-D.ietf-idr-flowspec-l2vpn] 339 Weiguo, H., Eastlake, D., Litkowski, S., and S. Zhuang, 340 "BGP Dissemination of L2 Flow Specification Rules", draft- 341 ietf-idr-flowspec-l2vpn-16 (work in progress), November 342 2020. 344 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 345 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 346 (SRv6) Network Programming", RFC 8986, 347 DOI 10.17487/RFC8986, February 2021, 348 . 350 Authors' Addresses 352 Zhenbin Li 353 Huawei 354 156 Beiqing Road 355 Beijing, 100095 356 P.R. China 358 Email: lizhenbin@huawei.com 360 Lei Li 361 Huawei 362 156 Beiqing Road 363 Beijing 100095 364 P.R. China 366 Email: lily.lilei@huawei.com 368 Huaimo Chen 369 Futurewei 370 Boston, MA 371 USA 373 Email: Huaimo.chen@futurewei.com 375 Christoph Loibl 376 Next Layer Communications 377 Mariahilfer Guertel 37/7 378 Vienna 1150 379 AT 381 Email: cl@tix.at 382 Gyan S. Mishra 383 Verizon Inc. 384 13101 Columbia Pike 385 Silver Spring MD 20904 386 USA 388 Phone: 301 502-1347 389 Email: gyan.s.mishra@verizon.com 391 Yanhe Fan 392 Casa Systems 393 USA 395 Email: yfan@casa-systems.com 397 Yongqing Zhu 398 China Telecom 399 109, West Zhongshan Road, Tianhe District 400 Guangzhou 510000 401 China 403 Email: zhuyq.gd@chinatelecom.cn 405 Lei Liu 406 Fujitsu 408 USA 410 Email: liulei.kddi@gmail.com 412 Xufeng Liu 413 Volta Networks 415 McLean, VA 416 USA 418 Email: xufeng.liu.ietf@gmail.com