idnits 2.17.1 draft-li-idr-flowspec-srv6-04.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 (December 1, 2020) is 1242 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 122 -- Looks like a reference, but probably isn't: '1' on line 124 == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-21 == Outdated reference: A later version (-23) exists of draft-ietf-idr-flowspec-l2vpn-16 Summary: 1 error (**), 0 flaws (~~), 3 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: June 4, 2021 H. Chen 6 Futurewei 7 C. Loibl 8 Next Layer Communications 9 Y. Fan 10 Casa Systems 11 Y. Zhu 12 China Telecom 13 L. Liu 14 Fujitsu 15 X. Liu 16 Volta Networks 17 December 1, 2020 19 BGP Flow Specification for SRv6 20 draft-li-idr-flowspec-srv6-04 22 Abstract 24 This document proposes extensions to BGP Flow Specification for SRv6 25 for filtering SRv6 packets that match a sequence of conditions. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on June 4, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 69 3. The Flow Specification Encoding for SRv6 . . . . . . . . . . 4 70 3.1. Type TBD1 - Whole SID . . . . . . . . . . . . . . . . . . 4 71 3.2. Type TBD2 - Some bits of SID . . . . . . . . . . . . . . 5 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 74 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 77 7.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 [I-D.ietf-idr-rfc5575bis] describes in details about a new BGP NLRI 83 to distribute a flow specification, which is an n-tuple comprising a 84 sequence of matching criteria that can be applied to IP traffic. 85 [I-D.ietf-idr-flow-spec-v6] extends [I-D.ietf-idr-rfc5575bis] to make 86 it also usable and applicable to IPv6 data packets. 87 [I-D.ietf-idr-flowspec-l2vpn] extends the flow-spec rules for layer 2 88 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 [I-D.filsfils-spring-srv6-network-programming] defines the SRv6 96 network programming concept and its most basic functions. An SRv6 97 SID may have the form of LOC:FUNCT:ARGS::. 99 LOC: Each operator is free to use the locator length it chooses. 100 Most often the LOC part of the SID is routable and leads to the node 101 which instantiates that SID. 103 FUNCT: The FUNCT part of the SID is an opaque identification of a 104 local function bound to the SID. (e.g. End: Endpoint, End.X, End.T, 105 End.DX2 etc.). 107 ARGS: A function may require additional arguments that would be 108 placed immediately after the FUNCT. 110 This document specifies two new BGP Flow Specification (FS) component 111 types to support Segment Routing over IPv6 data plane (SRv6) 112 filtering. The match field is destination address of IPv6 header, 113 but it's a SID copy from SRH rather than a traditional IPv6 address 114 (refer to Figure 1). 116 +-----------------------------+ 117 IPv6 Header| SA | DA |<--Match field of this document 118 +--------------------^--------+ 119 | 120 +--------------------|--------+ 121 | +-------------+ | +-------------------+ 122 | | Segment[0] +-------> Loc | Func | Args | 123 | +-------------+ | +-------------------+ 124 | | Segment[1] | | 125 | +-------------+ | 126 | | ... | | 127 SR Header| +-------------+ | 128 | | Segment[n] | | 129 | +-------------+ | 130 | +-------------+ | 131 | ~ Option TLV ~ | 132 | +-------------+ | 133 +-----------------------------+ 135 Figure 1: Match Field 137 2. Definitions and Acronyms 139 o FS: Flow Specification 141 o BGP-FS: Border Gateway Protocol (BGP) Flow Specification (FS) 143 o SR: Segment Routing 145 o SRH: SR Header. 147 o SRv6: IPv6 Segment Routing, SRv6 is a method of forwarding IPv6 148 packets on the network based on the concept of source routing. 150 o SID: Segment Identifier 152 o BSID: Binding SID 154 3. The Flow Specification Encoding for SRv6 156 The Flow Specification NLRI-type consists of several optional 157 components, each of which begins with a type field (1 octet) followed 158 by a variable length parameter. 13 component types are defined in 159 [I-D.ietf-idr-rfc5575bis] and [I-D.ietf-idr-flow-spec-v6] for IPv4 160 and IPv6. This document defines two new component types for SRv6. 162 3.1. Type TBD1 - Whole SID 164 Encoding: 166 Contains a list of {operator, value} pairs that are used to match the 167 SID/binding SID or a range of whole SID. 169 The operator byte is encoded as: 171 0 1 2 3 4 5 6 7 172 +---+---+---+---+---+---+---+---+ 173 | e | a | 0 | 0 | 0 |lt |gt |eq | 174 +---+---+---+---+---+---+---+---+ 176 Where: 178 e - end-of-list bit. Set in the last {op, value} pair in the 179 sequence. 181 a - AND bit. If unset, the previous term is logically ORed with the 182 current one. If set, the operation is a logical AND. It should be 183 unset in the first operator byte of a sequence. The AND operator has 184 higher priority than OR for the purposes of evaluating logical 185 expressions. 187 0 - SHOULD be set to 0 on NLRI encoding, and MUST be ignored during 188 decoding. 190 lt - less than comparison between data and value. 192 gt - greater than comparison between data and value. 194 eq - equality between data and value. 196 The bits lt, gt, and eq can be combined to match the SID or a range 197 of SID (e.g. less than SID1 and greater than SID2). 199 The value field is encoded as: 201 0 1 2 3 202 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 203 +---------------------------------------------------------------+ 204 ~ SID(128bits) ~ 205 +---------------------------------------------------------------+ 207 The format of SID is described in 208 [I-D.ietf-6man-segment-routing-header] and 209 [I-D.filsfils-spring-srv6-network-programming] 211 3.2. Type TBD2 - Some bits of SID 213 For some scenarios route policy with the whole 128 bits SID matching 214 is too long and not necessary. 215 [I-D.filsfils-spring-srv6-network-programming] defines the format of 216 SID is LOC:FUNCT:ARGS::. In some scenarios, traffic packets can just 217 match Locator, Function ID, Argument or some combinations of these 218 different fields rather than whole 128 bits SID. The new component 219 type TBD2 defined below is for matching some bits of SID. 221 Encoding: 223 Contains a list of {operator, value} pairs that are used to match 224 some bits of SID. 226 The operator byte is encoded as: 228 0 1 2 3 4 5 6 7 229 +---+---+---+---+---+---+---+---+ 230 | e | a | field type|lt |gt |eq | 231 +---+---+---+---+---+---+---+---+ 233 Where: 235 e and a are the same as defined in Section "Type TBD1 - Whole SID". 237 field type: 239 000 : SID's LOC bits 241 001 : SID's FUNCT bits 243 010 : SID's LOC:FUNCT bits 244 011 : SID's FUNCT:ARGS bits 246 lt - less than comparison between data' and value'. 248 gt - greater than comparison between data' and value'. 250 eq - equality between data' and value'. 252 The data' and value' used in lt, gt and eq are indicated by the field 253 type in a operator and its corresponding length in the value field 254 following the operator. 256 The value field is encoded below as the lengths in bits of LOC, FUNCT 257 and ARGS followed by the SID rounding up to bytes: 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | LOC Length | FUNCT Length | ARGS Length | SID | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 ~ SID(continue) ~ 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Where: 269 LOC Length : 1-octet field indicating the length in bits of LOC in 270 SID. 272 FUNCT Length : 1-octet field indicating the length in bits of FUNCT 273 in SID. 275 ARGS Length : 1-octet field indicating the length in bits of ARGS in 276 SID. 278 SID : the SID containing LOC, FUNCT and ARGS, and rounding up to 279 bytes. 281 4. Security Considerations 283 No new security issues are introduced to the BGP protocol by this 284 specification over the security considerations in 285 [I-D.ietf-idr-rfc5575bis] and [I-D.ietf-idr-flow-spec-v6]. 287 5. IANA Considerations 289 This section complies with [RFC7153]. 291 Under "Flow Spec IPv6 Component Types" registry, IANA is requested to 292 assign the following values: 294 +-----------+-------------------+----------------+ 295 | Value | Name | Reference | 296 +-----------+-------------------+----------------+ 297 | TBD1 (14) | Whole SID | This Document | 298 +-----------+-------------------+----------------+ 299 | TBD2 (15) | Some bits of SID | This Document | 300 +-----------+-------------------+----------------+ 302 6. Acknowledgments 304 The authors would like to thank Shunwan Zhuang and Rainsword Wang for 305 their valuable suggestions and comments on this draft. 307 7. References 309 7.1. Normative References 311 [I-D.ietf-idr-flow-spec-v6] 312 Loibl, C., Raszuk, R., and S. Hares, "Dissemination of 313 Flow Specification Rules for IPv6", draft-ietf-idr-flow- 314 spec-v6-21 (work in progress), November 2020. 316 [I-D.ietf-idr-rfc5575bis] 317 Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 318 Bacher, "Dissemination of Flow Specification Rules", 319 draft-ietf-idr-rfc5575bis-27 (work in progress), October 320 2020. 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, 324 DOI 10.17487/RFC2119, March 1997, 325 . 327 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 328 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 329 March 2014, . 331 7.2. Informative References 333 [I-D.filsfils-spring-srv6-network-programming] 334 Filsfils, C., Camarillo, P., Leddy, J., 335 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 336 Network Programming", draft-filsfils-spring-srv6-network- 337 programming-07 (work in progress), February 2019. 339 [I-D.ietf-6man-segment-routing-header] 340 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 341 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 342 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 343 progress), October 2019. 345 [I-D.ietf-idr-flowspec-l2vpn] 346 Weiguo, H., Eastlake, D., Litkowski, S., and S. Zhuang, 347 "BGP Dissemination of L2 Flow Specification Rules", draft- 348 ietf-idr-flowspec-l2vpn-16 (work in progress), November 349 2020. 351 Authors' Addresses 353 Zhenbin Li 354 Huawei 355 156 Beiqing Road 356 Beijing, 100095 357 P.R. China 359 Email: lizhenbin@huawei.com 361 Lei Li 362 Huawei 363 156 Beiqing Road 364 Beijing 100095 365 P.R. China 367 Email: lily.lilei@huawei.com 369 Huaimo Chen 370 Futurewei 371 Boston, MA 372 USA 374 Email: Huaimo.chen@futurewei.com 376 Christoph Loibl 377 Next Layer Communications 378 Mariahilfer Guertel 37/7 379 Vienna 1150 380 AT 382 Email: cl@tix.at 383 Yanhe Fan 384 Casa Systems 385 USA 387 Email: yfan@casa-systems.com 389 Yongqing Zhu 390 China Telecom 391 109, West Zhongshan Road, Tianhe District 392 Guangzhou 510000 393 China 395 Email: zhuyq.gd@chinatelecom.cn 397 Lei Liu 398 Fujitsu 400 USA 402 Email: liulei.kddi@gmail.com 404 Xufeng Liu 405 Volta Networks 407 McLean, VA 408 USA 410 Email: xufeng.liu.ietf@gmail.com