idnits 2.17.1 draft-dhanaraj-bier-lsr-ethernet-extensions-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 ([RFC8279], [RFC2328], [RFC1195], [RFC8296]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC8296, but the abstract doesn't seem to directly say this. It does mention RFC8296 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 29, 2019) is 1912 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) == Outdated reference: A later version (-04) exists of draft-ietf-bier-non-mpls-bift-encoding-01 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Dhanaraj, Ed. 3 Internet-Draft Huawei 4 Updates: 8296 (if approved) IJ. Wijnands 5 Intended status: Standards Track P. Psenak 6 Expires: August 2, 2019 Cisco Systems, Inc. 7 Z. Zhang 8 Juniper Networks. 9 G. Yan 10 J. Xie 11 Huawei 12 January 29, 2019 14 LSR Extensions for BIER over Ethernet 15 draft-dhanaraj-bier-lsr-ethernet-extensions-00 17 Abstract 19 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 20 that provides multicast forwarding through a "BIER domain" without 21 requiring intermediate routers to maintain multicast related per-flow 22 state. BIER can be supported in MPLS and non-MPLS networks. The 23 common BIER header format and encapsulation for MPLS and non-MPLS 24 networks is specified in [RFC8296]. 26 This document specifies the required extensions to the IS-IS 27 [RFC1195] and OSPFv2 [RFC2328] protocol for supporting BIER in non- 28 MPLS networks using BIER in Ethernet encapsulation. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 2, 2019. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 67 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. IS-IS BIER Ethernet Encapsulation Sub-sub TLV . . . . . . 5 69 3.2. OSPFv2 BIER Ethernet Encapsulation Sub-TLV . . . . . . . 6 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 5.1. IS-IS sub-sub-TLVs for BIER Info sub-TLV Registry . . . . 8 73 5.2. OSPFv2 Extended Prefix TLV Sub-TLVs Registry . . . . . . 8 74 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 7.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 83 that provides multicast forwarding through a "BIER domain" without 84 requiring intermediate routers to maintain multicast related per-flow 85 state. BIER can be supported in MPLS and non-MPLS networks. 87 [RFC8296] specifies a common BIER header format for both MPLS and 88 non-MPLS networks, though the first 20-bits of the BIER header 89 (referred as BIFT-id) is a "MPLS Label" in case of MPLS networks and 90 is a "domain-wide-unique-value" representing the combination of SD- 91 BSL-SI in case of non-MPLS networks. 92 [I-D.ietf-bier-non-mpls-bift-encoding] specifies two optional ways of 93 statically assigning domain-wide-unique mapping between BIFT-IDs and 94 SD-BSL-SI combination. 96 However, BIER architecture [RFC8279] does NOT require domain-wide- 97 unique BIFT-IDs to be used (even for non-MPLS encapsulation). As 98 discussed in [I-D.zzhang-bier-rift], the BIFT-ID in case of non-MPLS 99 encapsulation can also just be a local 20-bit opaque value and 100 signaled just like in MPLS case. 102 As an example, suppose a particular BIER domain contains a SD (SD 0), 103 supports two BSLs (256 and 512), and contains 1024 BFRs. A BFR that 104 is provisioned for above SD, and that supports both BSLs, could 105 advertise the following set of BIFT-id's: 107 BIFT-id 1: corresponding to SD 0, BSL 256, SI 0. 109 BIFT-id 2: corresponding to SD 0, BSL 256, SI 1. 111 BIFT-id 3: corresponding to SD 0, BSL 256, SI 2. 113 BIFT-id 4: corresponding to SD 0, BSL 256, SI 3. 115 BIFT-id 5: corresponding to SD 0, BSL 512, SI 0. 117 BIFT-id 6: corresponding to SD 0, BSL 512, SI 1. 119 Notice that the example uses ranges of continuous BIFT-ids: 121 BIFT-id range [1 to 4] correspond to . The first 122 BIFT-id in the range correspond to SI=0, the second correspond to 123 SI=1, and so on. 125 BIFT-id range [5 to 6] correspond to . The first 126 BIFT-id in the range correspond to SI=0, the second correspond to 127 SI=1. 129 Strictly speaking, using contiguous range is not required, but it is 130 done for the purpose of simplified signaling similar to MPLS label 131 blocks (notice that locally assigning BIFT-ID ranges requires no 132 manual processing just like in the case of MPLS label block 133 allocation). 135 Processing and forwarding of BIER packets requires special software 136 and hardware capabilities. The BFRs supporting a BIER encapsulation 137 type MUST advertise this capability (along with the other required 138 parameters specific to the encapsulation) to the other routers in 139 BIER domain. This advertisement, for example, will enable the other 140 BFRs in the BIER domain in deciding, whether to include or exclude 141 the advertising router from the BAR and/or IPA algorithm while 142 computing the multicast path for a specific encapsulation type. 144 [RFC8401] and [RFC8444] specifies the required extensions to the IS- 145 IS [RFC1195] and OSPFv2 [RFC2328] protocol respectively for the 146 distribution of BIER sub-domain information including the Sub-sub-TLV 147 required to support BIER in MPLS encapsulation for MPLS networks. 149 This document specifies the required extensions to the IS-IS 150 [RFC1195] and OSPFv2 [RFC2328] protocol for supporting BIER using 151 BIER in Ethernet encapsulation with dynamically and locally assigned 152 BIFT-IDs. 154 Support for other encapsulation types are outside the scope of this 155 document. 157 2. Terminology 159 Some of the terminology specified in [RFC8279] is replicated here and 160 extended by necessary definitions: 162 BIER: Bit Index Explicit Replication 163 (The overall architecture of forwarding multicast using a Bit 164 Position). 166 BIER-MPLS: BIER in MPLS encapsulation. 167 (Encapsulation of BIER header inside MPLS header in MPLS 168 networks). 170 BIER-ETH: BIER in Ethernet encapsulation. 171 (Encapsulation of BIER header inside Ethernet header 172 (EtherType=0xAB37) in non-MPLS networks). 174 BFR: Bit Forwarding Router (A router that participates in Bit Index 175 Multipoint Forwarding). A BFR is identified by a unique BFR- 176 prefix in a BIER domain. 178 BIFT: Bit Index Forwarding Table used to forward the BIER packets in 179 a domain. 181 BAR: BIER Algorithm. Used to calculate underlay nexthops 182 as defined by the BAR value. 184 IPA: IGP Algorithm. May be used to modify, enhance or replace the 185 calculation of underlay paths as defined by the BAR value 187 2.1. Requirements Language 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 191 "OPTIONAL" in this document are to be interpreted as described in BCP 192 14 [RFC2119] [RFC8174] when, and only when, they appear in all 193 capitals, as shown here. 195 3. Specification 197 A BIER sub-domain MAY support multiple BIER encapsulation types like 198 BIER-MPLS, BIER-ETH. The different encapsulation types supported by 199 a BFR in a sub-domain MUST share the same BFR-id. This would allow 200 the BFR's in transit to translate the encapsulation from one type to 201 the other while forwarding the packet in the BIER sub-domain. 203 When a BFIR/BFR supports multiple BIER encapsulation types, when 204 sending to a BIER neighbor it MUST use a type that the neighbor also 205 supports. If the neighbor also supports more than one encapsulation 206 type that this BFIR/BFR supports, the type selection could be a 207 matter of local policy and is outside the scope of this document. 209 3.1. IS-IS BIER Ethernet Encapsulation Sub-sub TLV 211 BIER Info sub-TLV defined in [RFC8401] is used to advertise the sub- 212 domain id, and other associated parameters of the sub-domain like 213 BFR-id, MT, BAR, IPA. 215 This document introduces new sub-sub-TLV under BIER Info sub-TLV to 216 advertise the ethernet encapsulation capability and other associated 217 parameters of the encapsulation. 219 This sub-sub-TLV carries the information for the BIER Ethernet 220 encapsulation including the BitString length supported for a certain 221 pair. 223 It is advertised within the BIER Info sub-TLV defined in [RFC8401] 224 which in-turn is carried within the TLVs 235, 237 [RFC5120] or TLVs 225 135 [RFC5305], or TLV 236 [RFC5308]. 227 This sub-sub-TLV MAY appear multiple times within a single BIER Info 228 sub-TLV. If the same BitString length is repeated in multiple BIER 229 Ethernet encapsulation sub-sub-TLVs inside the same BIER Info sub- 230 TLV, the BIER Info sub-TLV MUST be ignored. 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Type | Length | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Max SI |BS Len | BIFT-id | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Type: 2 (suggested value - To be assigned by IANA). 242 Length: 4 244 Max SI: A 1 octet field encoding the Maximum Set Identifier 245 (Section 1 of [RFC8279]) used in the encapsulation for this BIER 246 subdomain for this BitString length. The first BIFT-id is for SI=0, 247 the second BIFT-id is for SI=1, etc. If the BIFT-id associated with 248 the Maximum Set Identifier exceeds the 20-bit range, the sub-sub-TLV 249 MUST be ignored. 251 Local BitString Length (BS Len): A 4 bit field encoding the 252 bitstring length (as per [RFC8296]) supported for the encapsulation. 254 BIFT-id: A 20 bit field encoding the first BIFT-id of the BIFT-id 255 range. 257 The "BIFT-id range" is the set of 20-bit values beginning with the 258 BIFT-id and ending with (BIFT-id + (Max SI)). A unique BIFT-id range 259 is allocated for each BitString length and sub-domain-id. These BIFT- 260 id's are used for BIER forwarding as described in [RFC8279] and 261 [RFC8296]. 263 The size of the BIFT-id range is determined by the number of SI's 264 (Section 1 of [RFC8279]) that are used in the network. Each SI maps 265 to a single BIFT-id in the BIFT-id range: the first BIFT-id is for 266 SI=0, the second BIFT-id is for SI=1, etc. 268 If the BIFT-id associated with the Maximum Set Identifier exceeds 269 the 20-bit range, the BIER Ethernet Encapsulation Sub-sub-TLV 270 containing the error MUST be ignored. 272 3.2. OSPFv2 BIER Ethernet Encapsulation Sub-TLV 274 BIER Sub-TLV defined in [RFC8444] is used to advertise the sub-domain 275 id, and other associated parameters of the sub-domain like BFR-id, 276 MT, BAR, IPA. 278 This document introduces new Sub-TLV under BIER Sub-TLV to advertise 279 the ethernet encapsulation capability and other associated parameters 280 of the encapsulation. 282 This Sub-TLV carries the information for the BIER Ethernet 283 encapsulation including the BitString length supported for a certain 284 pair. 286 It is advertised within the BIER Sub-TLV defined in [RFC8444] which 287 in-turn is carried within the OSPFv2 Extended Prefix TLV defined in 288 [RFC7684]. 290 This Sub-TLV MAY appear multiple times within a single BIER Sub-TLV. 291 If the same BitString length is repeated in multiple BIER Ethernet 292 encapsulation Sub-TLVs inside the same BIER Sub-TLV, the BIER Sub-TLV 293 MUST be ignored. 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Type | Length | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Max SI | BIFT-id | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 |BS Len | Reserved | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Type: 11 (suggested value - To be assigned by IANA). 307 Length: 8 309 Max SI: A 1 octet field encoding the Maximum Set Identifier 310 (Section 1 of [RFC8279]) used in the encapsulation for this BIER 311 subdomain for this BitString length. The first BIFT-id is for SI=0, 312 the second BIFT-id is for SI=1, etc. If the BIFT-id associated with 313 the Maximum Set Identifier exceeds the 20-bit range, the sub-sub-TLV 314 MUST be ignored. 316 BIFT-id: A 3-octet field, where the 20 rightmost bits represent the 317 first BIFT-id in the BIFT-id range. The 4 leftmost bits MUST be 318 ignored. 320 The "BIFT-id range" is the set of 20-bit values beginning with the 321 BIFT-id and ending with (BIFT-id + (Max SI)). A unique BIFT-id range 322 is allocated for each BitString length and sub-domain-id. These BIFT- 323 id's are used for BIER forwarding as described in [RFC8279] and 324 [RFC8296]. 326 The size of the BIFT-id range is determined by the number of SI's 327 (Section 1 of [RFC8279]) that are used in the network. Each SI maps 328 to a single BIFT-id in the BIFT-id range: the first BIFT-id is for 329 SI=0, the second BIFT-id is for SI=1, etc. 331 If the BIFT-id associated with the Maximum Set Identifier exceeds 332 the 20-bit range, the BIER Ethernet Encapsulation Sub-sub-TLV 333 containing the error MUST be ignored. 335 Local BitString Length (BS Len): A 4 bit field encoding the 336 bitstring length (as per [RFC8296]) supported for the encapsulation. 338 Reserved: SHOULD be set to 0 on transmission and MUST be ignored on 339 reception. 341 4. Security Considerations 343 Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310] 344 and the security concerns for IS-IS extensions for BIER are addressed 345 in [RFC8401]. This document introduces new sub-sub-TLV for the 346 already existing IS-IS TLVs defined for distributing the BIER sub- 347 domain information in [RFC8401]. It does not introduce any new 348 security risks to IS-IS. 350 Security concerns and required extensions for OSPFv2 are addressed in 351 [RFC2328] and [RFC7684] and the security concerns for OSPFv2 352 extensions for BIER are addressed in [RFC8444]. This document 353 introduces new Sub-TLV for the already existing OSPFv2 TLV defined 354 for distributing the BIER sub-domain information in [RFC8444]. It 355 does not introduce any new security risks to OSPFv2. 357 5. IANA Considerations 359 The document requests new allocations from the IANA registries as 360 follows 362 5.1. IS-IS sub-sub-TLVs for BIER Info sub-TLV Registry 364 BIER Ethernet Encapsulation sub-sub-TLV: 2 (suggested) 366 5.2. OSPFv2 Extended Prefix TLV Sub-TLVs Registry 368 BIER Ethernet Encapsulation Sub-TLV: 11 (suggested) 370 6. Acknowledgments 372 The author wants to thank Antonie Przygienda for his comments and 373 suggestions. 375 7. References 377 7.1. Normative References 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, 381 DOI 10.17487/RFC2119, March 1997, 382 . 384 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 385 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 386 Explicit Replication (BIER)", RFC 8279, 387 DOI 10.17487/RFC8279, November 2017, 388 . 390 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 391 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 392 for Bit Index Explicit Replication (BIER) in MPLS and Non- 393 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 394 2018, . 396 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 397 Zhang, "Bit Index Explicit Replication (BIER) Support via 398 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 399 . 401 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 402 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 403 Extensions for Bit Index Explicit Replication (BIER)", 404 RFC 8444, DOI 10.17487/RFC8444, November 2018, 405 . 407 7.2. Informative References 409 [I-D.ietf-bier-non-mpls-bift-encoding] 410 Wijnands, I., Xu, X., and H. Bidgoli, "An Optional 411 Encoding of the BIFT-id Field in the non-MPLS BIER 412 Encapsulation", draft-ietf-bier-non-mpls-bift-encoding-01 413 (work in progress), October 2018. 415 [I-D.zzhang-bier-rift] 416 Zhang, Z., Ma, S., and Z. Zhang, "Supporting BIER with 417 RIFT", draft-zzhang-bier-rift-00 (work in progress), March 418 2018. 420 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 421 dual environments", RFC 1195, DOI 10.17487/RFC1195, 422 December 1990, . 424 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 425 DOI 10.17487/RFC2328, April 1998, 426 . 428 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 429 Topology (MT) Routing in Intermediate System to 430 Intermediate Systems (IS-ISs)", RFC 5120, 431 DOI 10.17487/RFC5120, February 2008, 432 . 434 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 435 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 436 2008, . 438 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 439 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 440 2008, . 442 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 443 DOI 10.17487/RFC5308, October 2008, 444 . 446 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 447 and M. Fanto, "IS-IS Generic Cryptographic 448 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 449 2009, . 451 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 452 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 453 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 454 2015, . 456 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 457 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 458 May 2017, . 460 Authors' Addresses 462 Senthil Dhanaraj (editor) 463 Huawei 465 Email: senthil.dhanaraj.ietf@gmail.com 467 IJsbrand Wijnands 468 Cisco Systems, Inc. 470 Email: ice@cisco.com 472 Peter Psenak 473 Cisco Systems, Inc. 475 Email: ppsenak@cisco.com 477 Zhaohui Zhang 478 Juniper Networks. 480 Email: zzhang@juniper.net 482 Gang Yan 483 Huawei 485 Email: yangang@huawei.com 487 Jingrong Xie 488 Huawei 490 Email: xiejingrong@huawei.com