idnits 2.17.1 draft-ietf-bier-isis-extensions-10.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 (March 11, 2018) is 2231 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 (-18) exists of draft-ietf-bier-ospf-bier-extensions-15 Summary: 0 errors (**), 0 flaws (~~), 2 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: September 12, 2018 Juniper Networks 6 S. Aldrin 7 Google 8 J. Zhang 9 Juniper Networks, Inc. 10 March 11, 2018 12 BIER support via ISIS 13 draft-ietf-bier-isis-extensions-10 15 Abstract 17 This document defines ISIS extensions to support multicast forwarding 18 using the Bit Index Explicit Replication (BIER) architecture. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 24 "OPTIONAL" in this document are to be interpreted as described in BCP 25 14 [RFC2119] [RFC8174] when, and only when, they appear in all 26 capitals, as shown here. 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 September 12, 2018. 45 Copyright Notice 47 Copyright (c) 2018 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. BIER Domains and Sub-Domains . . . . . . . . . . . . . . 5 67 4.2. Advertising BIER Information . . . . . . . . . . . . . . 5 68 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 5.1. Multi Topology and Sub-Domain . . . . . . . . . . . . . . 5 70 5.2. BFR-id Advertisements . . . . . . . . . . . . . . . . . . 6 71 5.3. Logging Misconfiguration . . . . . . . . . . . . . . . . 6 72 5.4. Flooding Reduction . . . . . . . . . . . . . . . . . . . 6 73 6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 6 74 6.1. BIER Info sub-TLV . . . . . . . . . . . . . . . . . . . . 7 75 6.2. BIER MPLS Encapsulation sub-sub-TLV . . . . . . . . . . . 8 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 80 9.2. Informative References . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 Bit Index Explicit Replication (BIER) [RFC8279] defines an 86 architecture where all intended multicast receivers are encoded as 87 bitmask in the Multicast packet header within different 88 encapsulations such as [RFC8296]. A router that receives such a 89 packet will forward the packet based on the Bit Position in the 90 packet header towards the receiver(s), following a precomputed tree 91 for each of the bits in the packet. Each receiver is represented by 92 a unique bit in the bitmask. 94 This document presents necessary extensions to the currently deployed 95 ISIS for IP [RFC1195] protocol to support distribution of information 96 necessary for operation of BIER domains and sub-domains. This 97 document defines a new TLV to be advertised by every router 98 participating in BIER signaling. 100 This document defines support for MPLS encapsulation as specified in 101 [RFC8296]. Support for other encapsulation types is outside the 102 scope of this document. The use of multiple encapsulation types is 103 outside the scope of this document. 105 2. Terminology 107 Some of the terminology specified in [RFC8279] is replicated here and 108 extended by necessary definitions: 110 BIER: Bit Index Explicit Replication (The overall architecture of 111 forwarding multicast using a Bit Position). 113 BIER-OL: BIER Overlay Signaling. (The method for the BFIR to learn 114 about BFER's). 116 BFR: Bit Forwarding Router (A router that participates in Bit Index 117 Multipoint Forwarding). A BFR is identified by a unique BFR- 118 prefix in a BIER domain. 120 BFIR: Bit Forwarding Ingress Router (The ingress border router that 121 inserts the BM into the packet). Each BFIR must have a valid BFR- 122 id assigned. 124 BFER: Bit Forwarding Egress Router. A router that participates in 125 Bit Index Forwarding as leaf. Each BFER must be a BFR. Each BFER 126 must have a valid BFR-id assigned. 128 BFT: Bit Forwarding Tree used to reach all BFERs in a domain. 130 BIER sub-domain: A further distinction within a BIER domain 131 identified by its unique sub-domain identifier. A BIER sub-domain 132 can support multiple BitString Lengths. 134 BFR-id: An optional, unique identifier for a BFR within a BIER sub- 135 domain. 137 Invalid BFR-id: Unassigned BFR-id. The special value 0 is reserved 138 for this purpose. 140 BAR BIER Algorithm. Used to calculate underlay next hops. 142 IPA IGP Algorithm. May be used to modify, enhance or replace the 143 calculation of underlay paths as defined by the BAR value 145 SPF Shortest Path First routing calculation based on IGP link metric 147 3. IANA Considerations 149 This document adds the following new sub-TLV to the registry of Sub- 150 TLVs for TLVs 135, 235, 236, and 237. 152 Value: 32 (suggested - to be assigned by IANA) 154 Name: BIER Info 156 This document also introduces a new registry for sub-sub-TLVs for the 157 BIER Info sub-TLV added above. The registration policy is Expert 158 Review as defined in [RFC8126]. This registry is part of the "IS-IS 159 TLV Codepoints" registry. The name of the registry is "sub-sub-TLVs 160 for BIER Info sub-TLV". The defined values are: 162 Type Name 163 ---- ---- 164 1 BIER MPLS Encapsulation 166 IANA is requested to set up a registry called "BIER Algorithm 167 Registry" under category "Bit Index Explicit Replication". The 168 registration policies [RFC8126] for this registry are: 170 "Standards Action" for values 0-127 172 "Specification Required" for values 128-240 174 "Experimental Use" for values 240-254" 176 The initial values in the BIER Algorithm Registry are: 178 0: No BIER specific algorithm is used 180 1-254: Unassigned 182 255: Reserved 184 4. Concepts 185 4.1. BIER Domains and Sub-Domains 187 An ISIS signalled BIER domain is aligned with the scope of 188 distribution of BFR-prefixes that identify the BFRs within ISIS. 189 ISIS acts in such a case as the supporting BIER underlay. 191 Within such a domain, the extensions defined in this document 192 advertise BIER information for one or more BIER sub-domains. Each 193 sub-domain is uniquely identified by a subdomain-id (SD). Each 194 subdomain is associated with a single ISIS topology (MT) [RFC5120], 195 which may be any of the topologies supported by ISIS. Local 196 configuration controls which pairs are supported by a router. 197 The mapping of sub-domains to topologies MUST be consistent within 198 the IS-IS flooding domain used to advertise BIER information. 200 Each BIER sub-domain has as its unique attributes the encapsulation 201 used and the type of tree it is using to forward BIER frames 202 (currently always SPF). Additionally, per supported bitstring length 203 in the sub-domain, each router will advertise the necessary label 204 ranges to support it. 206 4.2. Advertising BIER Information 208 BIER information advertisements are associated with a new sub-TLV in 209 the extended reachability TLVs. BIER information is always 210 associated with a host prefix which MUST be a node address for the 211 advertising node. If this is not the case the advertisement MUST be 212 ignored. Therefore the following restrictions apply: 214 o Prefix length MUST be 32 for an IPv4 prefix or 128 for an IPv6 215 prefix 217 o When the Prefix Attributes Flags sub-TLV is present N flag MUST be 218 set and R flag MUST NOT be set. [RFC7794] 220 o BIER sub-TLVs MUST be included when a prefix reachability 221 advertisement is leaked between levels. 223 5. Procedures 225 5.1. Multi Topology and Sub-Domain 227 A given sub-domain is supported within one and only one topology. 228 All routers in the flooding scope of the BIER sub-TLVs MUST advertise 229 the same sub-domain within the same multi-topology. A router 230 receiving an advertisement which does not match the locally 231 configured pair MUST report a misconfiguration of the received 232 pair. All received BIER advertisements associated with the 233 conflicting pair MUST be ignored. Note that in the presence 234 of such a misconfiguration this will lead to partitioning of the sub- 235 domian. 237 Example: 239 The following combination of advertisements are valid: <0,0> <0,1> 240 <2,2>. 242 The following combination of advertisements are invalid: <0,0> <0,1> 243 <2,0>. Advertisements associated with <0,0> and <2,0> must be 244 ignored. 246 5.2. BFR-id Advertisements 248 If a BFER/BFIR is configured with a BFR-id then it advertises this 249 value in its BIER advertisements. If no BFR-id is configured then 250 the value "Invalid BFR-id" is advertised. A valid BFR-id MUST be 251 unique within the flooding scope of the BIER advertisements. All 252 BFERs/BFIRs MUST detect advertisement of duplicate valid BFR-IDs for 253 a given . When such duplication is detected all of the 254 routers advertising duplicates MUST be treated as if they did not 255 advertise a valid BFR-id. This implies they cannot act as BFER or 256 BFIR in that . 258 5.3. Logging Misconfiguration 260 Whenever an advertisement is received which violates any of the 261 constraints defined in this document the receiving router MUST 262 support logging this occurrence. Logging SHOULD be dampened to avoid 263 excessive output. 265 5.4. Flooding Reduction 267 It is expected that changes in BIER domain information which is 268 advertised by IS-IS occur infrequently. If this expectation is not 269 met for an extended period of time (more than a few seconds of 270 burstiness) changes will increase the number of Link State PDU (LSP) 271 updates and negatively impact performance in the network. 272 Implementations SHOULD protect against this possibility e.g., by 273 dampening updates if they occur over an extended period of time. 275 6. Packet Formats 277 All ISIS BIER information is carried within the TLVs 235, 237 278 [RFC5120] or TLVs 135 [RFC5305], or TLV 236 [RFC5308]. 280 6.1. BIER Info sub-TLV 282 This sub-TLV carries the information for the BIER sub-domains that 283 the router participates in as BFR. This sub-TLV MAY appear multiple 284 times in a given prefix-reachability TLV - once for each sub-domain 285 supported in the associated topology. 287 The sub-TLV advertises a single combination followed by 288 optional sub-sub-TLVs as described in the following sections. 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type | Length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | BAR | IPA | subdomain-id | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | BFR-id | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | sub-sub-TLVs (variable) | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Type: as indicated in IANA section. 304 Length: variable 306 BAR BIER Algorithm. Specifies a BIER specific algorithm used to 307 calculate underlay paths to reach BFERs. Values are allocated 308 from the BIER Algorithm Registry. 1 octet 310 IPA IGP algorithm. Specifies an IGP Algorithm to either modify, 311 enhance or replace the calculation of underlay paths to reach 312 BFERs as defined by the BAR value. Values are from the IGP 313 Algorithm registry. 1 octet 315 subdomain-id: Unique value identifying the BIER sub-domain. 1 octet 317 BFR-id: A 2 octet field encoding the BFR-id, as documented in 318 [RFC8279]. If no BFR-id has been assigned the value of this field 319 is set to "Invalid BFR-id", which is defined as illegal in 320 [RFC8279] . 322 The use of non-zero values in either the BAR field or the IPA field 323 is outside the scope of this document. If an implementation does not 324 support the use of non-zero values in these fields, but receives a 325 BIER Info sub-TLV containing non-zero values in these fields, it 326 SHOULD treat the advertising router as incapable of supporting BIER 327 (one way of handling incapable routers is documented in section 6.9 328 of [RFC8279] and additional methods may be defined in the future). 330 6.2. BIER MPLS Encapsulation sub-sub-TLV 332 This sub-sub-TLV carries the information for the BIER MPLS 333 encapsulation including the label range for a specific bitstring 334 length for a certain . It is advertised within the BIER Info 335 sub-TLV (Section 6.1) . This sub-sub-TLV MAY appear multiple times 336 within a single BIER info sub-TLV. 338 If the same Bitstring length is repeated in multiple sub-sub-TLVs 339 inside the same BIER Info Sub-TLV, the BIER Info sub-TLV MUST be 340 ignored. 342 Label ranges within all BIER MPLS Encapsulation sub-sub-TLVs across 343 all BIER Info sub-TLVs advertised by the same BFR MUST NOT overlap. 344 If overlap is detected, the advertising router MUST be treated as if 345 it did not advertise any BIER sub-TLVs. 347 Label values MUST NOT match any of the reserved values defined in 348 [RFC3032] 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Type | Length | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Max SI |BS Len | Label | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Type: value of 1 indicating MPLS encapsulation. 360 Length: 4 362 Max SI Maximum Set Identifier (section 1 of [RFC8279]) used in the 363 encapsulation for this BIER sub-domain for this bitstring length, 364 1 octet. Each SI maps to a single label in the label range. The 365 first label is for SI=0, the second label is for SI=1, etc. If 366 the label associated with the Maximum Set Identifier exceeds the 367 20 bit range the sub-sub-TLV MUST be ignored. 369 Local BitString Length (BS Len): Encoded bitstring length as per 370 [RFC8296]. 4 bits. 372 Label: First label of the range, 20 bits. The labels are as defined 373 in [RFC8296]. 375 7. Security Considerations 377 Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. 378 Advertisement of the additional information defined in this document 379 introduces no new security concerns. 381 BIER specific security considerations are discussed in [RFC8279]. 383 8. Acknowledgements 385 The RFC is aligned with the 386 [I-D.draft-ietf-bier-ospf-bier-extensions-15] draft as far as the 387 protocol mechanisms overlap. 389 Many thanks for comments from (in no particular order) Hannes 390 Gredler, Ijsbrand Wijnands, Peter Psenak and Chris Bowers. 392 9. References 394 9.1. Normative References 396 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 397 dual environments", RFC 1195, DOI 10.17487/RFC1195, 398 December 1990, . 400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 401 Requirement Levels", BCP 14, RFC 2119, 402 DOI 10.17487/RFC2119, March 1997, 403 . 405 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 406 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 407 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 408 . 410 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 411 Topology (MT) Routing in Intermediate System to 412 Intermediate Systems (IS-ISs)", RFC 5120, 413 DOI 10.17487/RFC5120, February 2008, 414 . 416 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 417 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 418 2008, . 420 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 421 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 422 2008, . 424 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 425 DOI 10.17487/RFC5308, October 2008, 426 . 428 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 429 and M. Fanto, "IS-IS Generic Cryptographic 430 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 431 2009, . 433 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 434 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 435 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 436 March 2016, . 438 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 439 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 440 May 2017, . 442 9.2. Informative References 444 [I-D.draft-ietf-bier-ospf-bier-extensions-15] 445 Psenak et al., P., "OSPF Extension for Bit Index Explicit 446 Replication", internet-draft draft-ietf-bier-ospf-bier- 447 extensions-15, February 2018. 449 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 450 Writing an IANA Considerations Section in RFCs", BCP 26, 451 RFC 8126, DOI 10.17487/RFC8126, June 2017, 452 . 454 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 455 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 456 Explicit Replication (BIER)", RFC 8279, 457 DOI 10.17487/RFC8279, November 2017, 458 . 460 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 461 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 462 for Bit Index Explicit Replication (BIER) in MPLS and Non- 463 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 464 2018, . 466 Authors' Addresses 468 Les Ginsberg (editor) 469 Cisco Systems 470 510 McCarthy Blvd. 471 Milpitas, CA 95035 472 USA 474 Email: ginsberg@cisco.com 476 Tony Przygienda 477 Juniper Networks 479 Email: prz@juniper.net 481 Sam Aldrin 482 Google 483 1600 Amphitheatre Parkway 484 Mountain View, CA 485 USA 487 Email: aldrin.ietf@gmail.com 489 Jeffrey (Zhaohui) Zhang 490 Juniper Networks, Inc. 491 10 Technology Park Drive 492 Westford, MA 01886 493 USA 495 Email: zzhang@juniper.net