idnits 2.17.00 (12 Aug 2021) /tmp/idnits26694/draft-ietf-bier-isis-extensions-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 27, 2017) is 1759 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: draft-ietf-bier-mpls-encapsulation has been published as RFC 8296 == Outdated reference: draft-ietf-bier-ospf-bier-extensions has been published as RFC 8444 == Outdated reference: draft-ietf-bier-architecture has been published as RFC 8279 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Ginsberg, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track A. Przygienda 5 Expires: January 28, 2018 Juniper Networks 6 S. Aldrin 7 Google 8 J. Zhang 9 Juniper Networks, Inc. 10 July 27, 2017 12 BIER support via ISIS 13 draft-ietf-bier-isis-extensions-05 15 Abstract 17 Specification of an ISIS extension to support BIER domains and sub- 18 domains. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119] . 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 28, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. BIER Domains and Sub-Domains . . . . . . . . . . . . . . 4 65 4.2. Advertising BIER Information . . . . . . . . . . . . . . 5 66 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5.1. Enabling a BIER Sub-Domain . . . . . . . . . . . . . . . 5 68 5.2. Multi Topology and Sub-Domain . . . . . . . . . . . . . . 6 69 5.3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6 70 5.4. Tree Type . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5.5. Label advertisements for MPLS Encapsulation . . . . . . . 6 72 5.6. BFR-id Advertisements . . . . . . . . . . . . . . . . . . 6 73 5.7. Reporting Misconfiguration . . . . . . . . . . . . . . . 7 74 5.8. Flooding Reduction . . . . . . . . . . . . . . . . . . . 7 75 6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 7 76 6.1. BIER Info sub-TLV . . . . . . . . . . . . . . . . . . . . 7 77 6.2. BIER MPLS Encapsulation sub-sub-TLV . . . . . . . . . . . 8 78 6.3. Optional BIER sub-domain Tree Type sub-sub-TLV . . . . . 9 79 6.4. Optional BIER sub-domain BSL conversion sub-sub-TLV . . . 9 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 84 9.2. Informative References . . . . . . . . . . . . . . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 87 1. Introduction 89 Bit Index Explicit Replication (BIER) 90 [I-D.draft-ietf-bier-architecture-07] defines an architecture where 91 all intended multicast receivers are encoded as bitmask in the 92 Multicast packet header within different encapsulations such as 93 [I-D.draft-ietf-bier-mpls-encapsulation-07]. A router that receives 94 such a packet will forward the packet based on the Bit Position in 95 the packet header towards the receiver(s), following a precomputed 96 tree for each of the bits in the packet. Each receiver is 97 represented by a unique bit in the bitmask. 99 This document presents necessary extensions to the currently deployed 100 ISIS for IP [RFC1195] protocol to support distribution of information 101 necessary for operation of BIER domains and sub-domains. This 102 document defines a new TLV to be advertised by every router 103 participating in BIER signaling. 105 2. Terminology 107 Some of the terminology specified in 108 [I-D.draft-ietf-bier-architecture-07] is replicated here and extended 109 by necessary definitions: 111 BIER: Bit Index Explicit Replication (The overall architecture of 112 forwarding multicast using a Bit Position). 114 BIER-OL: BIER Overlay Signaling. (The method for the BFIR to learn 115 about BFER's). 117 BFR: Bit Forwarding Router (A router that participates in Bit Index 118 Multipoint Forwarding). A BFR is identified by a unique BFR- 119 prefix in a BIER domain. 121 BFIR: Bit Forwarding Ingress Router (The ingress border router that 122 inserts the BM into the packet). Each BFIR must have a valid BFR- 123 id assigned. 125 BFER: Bit Forwarding Egress Router. A router that participates in 126 Bit Index Forwarding as leaf. Each BFER must be a BFR. Each BFER 127 must have a valid BFR-id assigned. 129 BFT: Bit Forwarding Tree used to reach all BFERs in a domain. 131 BIFT: Bit Index Forwarding Table. 133 BMS: Bit Mask Set. Set containing bit positions of all BFER 134 participating in a set. 136 BMP: Bit Mask Position, a given bit in a BMS. 138 Invalid BMP: Unassigned Bit Mask Position, consisting of all 0s. 140 IGP signalled BIER domain: A BIER underlay where the BIER 141 synchronization information is carried in IGP. Observe that a 142 multi-topology is NOT a separate BIER domain in IGP. 144 BIER sub-domain: A further distinction within a BIER domain 145 identified by its unique sub-domain identifier. A BIER sub-domain 146 can support multiple BitString Lengths. 148 BFR-id: An optional, unique identifier for a BFR within a BIER sub- 149 domain. 151 Invalid BFR-id: Unassigned BFR-id, consisting of all 0s. 153 3. IANA Considerations 155 This document adds the following new sub-TLV to the registry of sub- 156 TLVs for TLVs 235, 237 [RFC5120] and TLVs 135,236 157 [RFC5305],[RFC5308]. 159 Value: 32 (suggested - to be assigned by IANA) 161 Name: BIER Info 163 This document also introduces a new registry for sub-sub-TLVs for the 164 BIER Info sub-TLV added above. The registration policy is Expert 165 Review as defined in [RFC8126]. This registry is part of the "IS-IS 166 TLV Codepoints" registry. The name of the registry is "sub-sub-TLVs 167 for BIER Info sub-TLV". The defined values are: 169 Type Name 170 ---- ---- 171 1 BIER MPLS Encapsulation 172 2 BIER sub-domain Tree Type 173 3 BIER sub-domain BSL conversion 175 4. Concepts 177 4.1. BIER Domains and Sub-Domains 179 An ISIS signalled BIER domain is aligned with the scope of 180 distribution of BFR-prefixes that identify the BFRs within ISIS. 181 ISIS acts in such a case as the supporting BIER underlay. 183 Within such a domain, the extensions defined in this document 184 advertise BIER information for one or more BIER sub-domains. Each 185 sub-domain is uniquely identified by a subdomain-id. Each subdomain 186 is associated with a single ISIS topology [RFC5120], which may be any 187 of the topologies supported by ISIS. Local configuration controls 188 which pairs are supported by a router. The mapping of sub- 189 domains to topologies MUST be consistent within a BIER flooding 190 domain. 192 Each BIER sub-domain has as its unique attributes the encapsulation 193 used and the type of tree it is using to forward BIER frames 194 (currently always SPF). Additionally, per supported bitstring length 195 in the sub-domain, each router will advertise the necessary label 196 ranges to support it. 198 At present, IS-IS support for a given BIER domain/sub-domain is 199 limited to a single area - or to the IS-IS L2 sub-domain. 201 4.2. Advertising BIER Information 203 BIER information advertisements are associated with a new sub-TLV in 204 the extended reachability TLVs. BIER information is always 205 associated with a host prefix which MUST be a node address for the 206 advertising node. The following restrictions apply: 208 o Prefix length MUST be 32 for an IPv4 prefix or 128 for an IPv6 209 prefix 211 o When the Prefix Attributes Flags sub-TLV is present N flag MUST be 212 set and X and R flags MUST NOT be set. [RFC7794] 214 o BIER sub-TLVs MUST NOT be included when a prefix reachability 215 advertisement is leaked between levels. 217 5. Procedures 219 5.1. Enabling a BIER Sub-Domain 221 A given sub-domain with identifier SD with supported bitstring 222 lengths MLs in a multi-topology MT [RFC5120] is denoted further as 223 and does not have to be advertised by default by BFRs to 224 preserve the scaling of the protocol (i.e. ISIS carries no TLVs 225 containing any of the elements related to ). The 226 advertisement may be triggered e.g. by a first BIER sub-TLV 227 (Section 6.1) containing advertised into the Level 1 area (or 228 the Level 2 IS-IS sub-domain). The specific trigger itself is 229 outside the scope of this RFC but can be for example a VPN desiring 230 to initiate a BIER sub-domain as MI-PMSI [RFC6513] tree or a pre- 231 configured BFER (since BFERs will always advertise the BIER sub-TLV 232 to make sure they can be reached). It is outside the scope of this 233 document to describe what trigger for a router capable of 234 participating in is used to start the origination of the 235 necessary information to join into it. 237 5.2. Multi Topology and Sub-Domain 239 A given sub-domain is supported within one and only one topology. 240 All routers in the flooding scope of the BIER sub-TLVs MUST advertise 241 the same sub-domain within the same multi-topology. A router 242 receiving an advertisement which does not match the locally 243 configured pair MUST report a misconfiguration of the received pair. All received BIER advertisements associated with the 245 conflicting pair MUST be ignored. 247 5.3. Encapsulation 249 All routers in the flooding scope of the BIER TLVs MUST advertise the 250 same encapsulation for a given . A router discovering 251 encapsulation advertised that is different from its own MUST report a 252 misconfiguration of a specific . All received BIER 253 advertisements associated with the conflicting pair MUST be 254 ignored. 256 5.4. Tree Type 258 All routers in the flooding scope of the BIER TLVs MAY advertise a 259 supported tree type for a given . Tree type indicates the 260 algorithm used when calculating the optimal path. Currently only the 261 default algorithm "SPF" is defined - which has a tree type of 0. If 262 no tree type is advertised tree type 0 is assumed. The supported 263 tree type MUST be consistent for all routers supporting a given 264 . 266 5.5. Label advertisements for MPLS Encapsulation 268 A router that desires to participate in MUST advertise for 269 each bitstring length it supports in a label range size that 270 guarantees to cover the maximum BFR-id injected into (which 271 implies a certain maximum set id per bitstring length as described in 272 [I-D.draft-ietf-bier-architecture-07]). Any router that violates 273 this condition MUST be excluded from BIER BFTs for . 275 5.6. BFR-id Advertisements 277 Each BFER/BFIR MAY advertise with its TLV the BFR-id that it 278 has administratively chosen. A valid BFR-id MUST be unique within 279 the flooding scope of the BIER advertisments. All BFERs/BFIRs MUST 280 detect advertisement of duplicate valid BFR-IDs for a given . 281 When such duplication is detected all of the routers advertising 282 duplicates MUST be treated as if they did not advertise a valid BFR- 283 id. This implies they cannot act as BFER or BFIR in that . 285 5.7. Reporting Misconfiguration 287 Whenever an advertisement is received which violates any of the 288 constraints defined in this document the receiving router MUST report 289 the misconfiguration. 291 5.8. Flooding Reduction 293 BIER domain information SHOULD change infrequently. Frequent changes 294 will increase the number of Link State PDU (LSP) updates and 295 negatively impact performance in the network. 297 6. Packet Formats 299 All ISIS BIER information is carried within the TLVs 235, 237 300 [RFC5120] or TLVs 135 [RFC5305], or TLV 236 [RFC5308]. 302 6.1. BIER Info sub-TLV 304 This sub-TLV carries the information for the BIER sub-domains that 305 the router participates in as BFR. This sub-TLV MAY appear multiple 306 times in a given prefix-reachability TLV - once for each sub-domain 307 supported in the associated topology. 309 The sub-TLV advertises a single combination followed by 310 optional sub-sub-TLVs as described in the following sections. 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Type | Length | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Reserved | subdomain-id | BFR-id | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Type: as indicated in IANA section. 322 Length: 1 octet. 324 Reserved: MUST be 0 on transmission, ignored on reception. May be 325 used in future versions. 8 bits 327 subdomain-id: Unique value identifying the BIER sub-domain. 1 octet 328 BFR-id: A 2 octet field encoding the BFR-id, as documented in 329 [I-D.draft-ietf-bier-architecture-07]. If no BFR-id has been 330 assigned this field is set to the invalid BFR-id. 332 6.2. BIER MPLS Encapsulation sub-sub-TLV 334 This sub-sub-TLV carries the information for the BIER MPLS 335 encapsulation including the label range for a specific bitstring 336 length for a certain . It is advertised within the BIER Info 337 sub-TLV (Section 6.1) . This sub-sub-TLV MAY appear multiple times 338 within a single BIER info sub-TLV. 340 On violation of any of the following conditions, the receiving router 341 MUST ignore the encapsulating BIER Info sub-TLV. 343 o Label ranges in multiple sub-sub-TLV MUST NOT overlap. 345 o Bitstring lengths in multiple sub-sub-TLVs MUST NOT be identical. 347 o The sub-sub-TLV MUST include the required bitstring lengths 348 encoded in precisely the same way as in 349 [I-D.draft-ietf-bier-mpls-encapsulation-07]. 351 o The label range size MUST be greater than 0. 353 o All labels in the range MUST represent valid label values 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Type | Length | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Lbl Range Size|BS Len | Label | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Type: value of 1 indicating MPLS encapsulation. 365 Length: 1 octet. 367 Local BitString Length (BS Len): Encoded bitstring length as per [I- 368 D.draft-ietf-bier-mpls-encapsulation-07]. 4 bits. 370 Label Range Size: Number of labels in the range used on 371 encapsulation for this BIER sub-domain for this bitstring length, 372 1 octet. 374 Label: First label of the range, 20 bits. The labels are as defined 375 in [I-D.draft-ietf-bier-mpls-encapsulation-07]. 377 6.3. Optional BIER sub-domain Tree Type sub-sub-TLV 379 This sub-sub-TLV carries the information associated with the 380 supported BIER tree type for a combination. It is carried 381 within the BIER Info sub-TLV (Section 6.1) that the router 382 participates in as BFR. This sub-sub-TLV is optional and its absence 383 has the same semantics as its presence with Tree Type value 0 (SPF). 384 When Tree Type 0 is used it is recommended that this sub-sub-TLV be 385 omitted in order to reduce the space consumed in the parent TLV. 387 This sub-sub-TLV MUST NOT occur more than once in a BIER Info sub- 388 TLV. If multiple occurences of this sub-sub-TLV are present in a 389 single BIER Info sub-TLV the encapsulating BIER Info sub-TLV MUST be 390 ignored. 392 If the tree type (implied or explicitly advertised) does not match 393 the locally configured tree type associated with the matching pair the encapsulating sub-TLV MUST be ignored. 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Type | Length | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Tree Type | 402 +-+-+-+-+-+-+-+-+ 404 Type: value of 1 indicating BIER Tree Type. 406 Length: 1 octet. 408 Tree Type: 1 octet 410 6.4. Optional BIER sub-domain BSL conversion sub-sub-TLV 412 This sub-sub-TLV indicates whether the BFR is capable of imposing a 413 different Bit String Length (BSL) than the one it received in a BIER 414 encapsulated packet. Such a capability may allow future, advanced 415 tree types which ensure simple migration procedures from one BSL to 416 another in a given or prevent stable blackholes in scenarios 417 where not all routers support the same set of BSLs in a given 418 . It is carried within the BIER Info sub-TLV (Section 6.1). 419 This sub-sub-TLV is optional and its absence indicates that the 420 router is NOT capable of imposing different BSLs but will always 421 forward the packet with the BSL unchanged. This sub-sub-TLV MAY 422 occur at most once in a given BIER info sub-TLV. If multiple 423 occurences of this sub-sub-TLV are received in a given BIER info sub- 424 TLV the encapsulating sub-TLV MUST be ignored. 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Type | Length | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 7. Security Considerations 434 Implementations must assure that malformed TLV and Sub-TLV 435 permutations do not result in errors which cause hard protocol 436 failures. 438 8. Acknowledgements 440 The RFC is aligned with the 441 [I-D.draft-ietf-bier-ospf-bier-extensions-07] draft as far as the 442 protocol mechanisms overlap. 444 Many thanks for comments from (in no particular order) Hannes 445 Gredler, Ijsbrand Wijnands, Peter Psenak and Chris Bowers. 447 9. References 449 9.1. Normative References 451 [I-D.draft-ietf-bier-mpls-encapsulation-07] 452 Wijnands et al., IJ., "Bit Index Explicit Replication 453 using MPLS encapsulation", internet-draft draft-ietf-bier- 454 mpls-encapsulation-07.txt, Jun 2017. 456 [I-D.draft-ietf-bier-ospf-bier-extensions-07] 457 Psenak et al., P., "OSPF Extension for Bit Index Explicit 458 Replication", internet-draft draft-ietf-bier-ospf-bier- 459 extensions-07.txt, Jul 2017. 461 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 462 dual environments", RFC 1195, DOI 10.17487/RFC1195, 463 December 1990, . 465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 466 Requirement Levels", BCP 14, RFC 2119, 467 DOI 10.17487/RFC2119, March 1997, 468 . 470 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 471 Topology (MT) Routing in Intermediate System to 472 Intermediate Systems (IS-ISs)", RFC 5120, 473 DOI 10.17487/RFC5120, February 2008, 474 . 476 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 477 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 478 2008, . 480 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 481 DOI 10.17487/RFC5308, October 2008, 482 . 484 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 485 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 486 2012, . 488 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 489 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 490 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 491 March 2016, . 493 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 494 Writing an IANA Considerations Section in RFCs", BCP 26, 495 RFC 8126, DOI 10.17487/RFC8126, June 2017, 496 . 498 9.2. Informative References 500 [I-D.draft-ietf-bier-architecture-07] 501 Wijnands et al., IJ., "Stateless Multicast using Bit Index 502 Explicit Replication Architecture", internet-draft draft- 503 ietf-bier-architecture-07.txt, Jun 2017. 505 Authors' Addresses 506 Les Ginsberg (editor) 507 Cisco Systems 508 510 McCarthy Blvd. 509 Milpitas, CA 95035 510 USA 512 Email: ginsberg@cisco.com 514 Tony Przygienda 515 Juniper Networks 517 Email: prz@juniper.net 519 Sam Aldrin 520 Google 521 1600 Amphitheatre Parkway 522 Mountain View, CA 523 USA 525 Email: aldrin.ietf@gmail.com 527 Jeffrey (Zhaohui) Zhang 528 Juniper Networks, Inc. 529 10 Technology Park Drive 530 Westford, MA 01886 531 USA 533 Email: zzhang@juniper.net