idnits 2.17.1 draft-ietf-bier-isis-extensions-08.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 (February 22, 2018) is 2248 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-14 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: August 26, 2018 Juniper Networks 6 S. Aldrin 7 Google 8 J. Zhang 9 Juniper Networks, Inc. 10 February 22, 2018 12 BIER support via ISIS 13 draft-ietf-bier-isis-extensions-08 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 August 26, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 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. Label advertisements for MPLS Encapsulation . . . . . . . 6 71 5.3. BFR-id Advertisements . . . . . . . . . . . . . . . . . . 6 72 5.4. Logging Misconfiguration . . . . . . . . . . . . . . . . 6 73 5.5. Flooding Reduction . . . . . . . . . . . . . . . . . . . 6 74 6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 7 75 6.1. BIER Info sub-TLV . . . . . . . . . . . . . . . . . . . . 7 76 6.2. BIER MPLS Encapsulation sub-sub-TLV . . . . . . . . . . . 8 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 9.2. Informative References . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 Bit Index Explicit Replication (BIER) [RFC8279] defines an 87 architecture where all intended multicast receivers are encoded as 88 bitmask in the Multicast packet header within different 89 encapsulations such as [RFC8296]. A router that receives such a 90 packet will forward the packet based on the Bit Position in the 91 packet header towards the receiver(s), following a precomputed tree 92 for each of the bits in the packet. Each receiver is represented by 93 a unique bit in the bitmask. 95 This document presents necessary extensions to the currently deployed 96 ISIS for IP [RFC1195] protocol to support distribution of information 97 necessary for operation of BIER domains and sub-domains. This 98 document defines a new TLV to be advertised by every router 99 participating in BIER signaling. 101 This document defines support for MPLS encapsulation as specified in 102 [RFC8296]. Support for other encapsulation types is outside the 103 scope of this document. The use of multiple encapsulation types is 104 outside the scope of this document. 106 2. Terminology 108 Some of the terminology specified in [RFC8279] is replicated here and 109 extended 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 BIER sub-domain: A further distinction within a BIER domain 132 identified by its unique sub-domain identifier. A BIER sub-domain 133 can support multiple BitString Lengths. 135 BFR-id: An optional, unique identifier for a BFR within a BIER sub- 136 domain. 138 Invalid BFR-id: Unassigned BFR-id. The special value 0 is reserved 139 for this purpose. 141 BAR BIER Algorithm. Used to calculate underlay next hops. 143 IPA IGP Algorithm. May be used to modify, enhance or replace the 144 calculation of underlay paths as defined by the BAR value 146 SPF Shortest Path First routing calculation based on IGP link metric 148 3. IANA Considerations 150 This document adds the following new sub-TLV to the registry of Sub- 151 TLVs for TLVs 135, 235, 236, and 237. 153 Value: 32 (suggested - to be assigned by IANA) 155 Name: BIER Info 157 This document also introduces a new registry for sub-sub-TLVs for the 158 BIER Info sub-TLV added above. The registration policy is Expert 159 Review as defined in [RFC8126]. This registry is part of the "IS-IS 160 TLV Codepoints" registry. The name of the registry is "sub-sub-TLVs 161 for BIER Info sub-TLV". The defined values are: 163 Type Name 164 ---- ---- 165 1 BIER MPLS Encapsulation 167 IANA is requested to set up a registry called "BIER Algorithm 168 Registry" under category "Bit Index Explicit Replication". The 169 registration policies [RFC8126] for this registry are: 171 "Standards Action" for values 0-127 173 "Specification Required" for values 128-240 175 "Experimental Use" for values 240-254" 177 The initial values in the BIER Algorithm Registry are: 179 0: No BIER specific algorithm is used 181 1-254: Unassigned 183 255: Reserved 185 4. Concepts 187 4.1. BIER Domains and Sub-Domains 189 An ISIS signalled BIER domain is aligned with the scope of 190 distribution of BFR-prefixes that identify the BFRs within ISIS. 191 ISIS acts in such a case as the supporting BIER underlay. 193 Within such a domain, the extensions defined in this document 194 advertise BIER information for one or more BIER sub-domains. Each 195 sub-domain is uniquely identified by a subdomain-id (SD). Each 196 subdomain is associated with a single ISIS topology (MT) [RFC5120], 197 which may be any of the topologies supported by ISIS. Local 198 configuration controls which pairs are supported by a router. 199 The mapping of sub-domains to topologies MUST be consistent within 200 the IS-IS flooding domain used to advertise BIER information. 202 Each BIER sub-domain has as its unique attributes the encapsulation 203 used and the type of tree it is using to forward BIER frames 204 (currently always SPF). Additionally, per supported bitstring length 205 in the sub-domain, each router will advertise the necessary label 206 ranges to support it. 208 4.2. Advertising BIER Information 210 BIER information advertisements are associated with a new sub-TLV in 211 the extended reachability TLVs. BIER information is always 212 associated with a host prefix which MUST be a node address for the 213 advertising node. The following restrictions apply: 215 o Prefix length MUST be 32 for an IPv4 prefix or 128 for an IPv6 216 prefix 218 o When the Prefix Attributes Flags sub-TLV is present N flag MUST be 219 set. [RFC7794] 221 o BIER sub-TLVs MUST be included when a prefix reachability 222 advertisement is leaked between levels. 224 5. Procedures 226 5.1. Multi Topology and Sub-Domain 228 A given sub-domain is supported within one and only one topology. 229 All routers in the flooding scope of the BIER sub-TLVs MUST advertise 230 the same sub-domain within the same multi-topology. A router 231 receiving an advertisement which does not match the locally 232 configured pair MUST report a misconfiguration of the received 233 pair. All received BIER advertisements associated with the 234 conflicting pair MUST be ignored. 236 Example: 238 The following combination of advertisements are valid: <0,0> <0,1> 239 <2,2>. 241 The following combination of advertisements are invalid: <0,0> <0,1> 242 <2,0>. Advertisements associated with <0,0> and <2,0> MUST be 243 ignored. 245 5.2. Label advertisements for MPLS Encapsulation 247 A router that desires to participate in MUST advertise for 248 each bitstring length it supports in a Maximum Set ID that 249 guarantees to cover the maximum BFR-id injected into (which 250 implies a certain maximum set id per bitstring length as described in 251 [RFC8279]). Any router that violates this condition MUST be excluded 252 from BIER BFTs for . 254 5.3. BFR-id Advertisements 256 Each BFER/BFIR MAY advertise with its TLV the BFR-id that it 257 has administratively chosen. A valid BFR-id MUST be unique within 258 the flooding scope of the BIER advertisements. All BFERs/BFIRs MUST 259 detect advertisement of duplicate valid BFR-IDs for a given . 260 When such duplication is detected all of the routers advertising 261 duplicates MUST be treated as if they did not advertise a valid BFR- 262 id. This implies they cannot act as BFER or BFIR in that . 264 5.4. Logging Misconfiguration 266 Whenever an advertisement is received which violates any of the 267 constraints defined in this document the receiving router MUST 268 support logging this occurrence. Logging SHOULD be dampened to avoid 269 excessive output. 271 5.5. Flooding Reduction 273 BIER domain information SHOULD change infrequently. Frequent changes 274 will increase the number of Link State PDU (LSP) updates and 275 negatively impact performance in the network. 277 6. Packet Formats 279 All ISIS BIER information is carried within the TLVs 235, 237 280 [RFC5120] or TLVs 135 [RFC5305], or TLV 236 [RFC5308]. 282 6.1. BIER Info sub-TLV 284 This sub-TLV carries the information for the BIER sub-domains that 285 the router participates in as BFR. This sub-TLV MAY appear multiple 286 times in a given prefix-reachability TLV - once for each sub-domain 287 supported in the associated topology. 289 The sub-TLV advertises a single combination followed by 290 optional sub-sub-TLVs as described in the following sections. 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type | Length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | BAR | IPA | subdomain-id | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | BFR-id | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | sub-sub-TLVs (variable) | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Type: as indicated in IANA section. 306 Length: variable 308 BAR BIER Algorithm. Specifies a BIER specific algorithm used to 309 calculate underlay paths to reach BFERs. Values are allocated 310 from the BIER Algorithm Registry. 1 octet 312 IPA IGP algorithm. Specifies an IGP Algorithm to either modify, 313 enhance or replace the calculation of underlay paths to reach 314 BFERs as defined by the BAR value. Values are from the IGP 315 Algorithm registry. 1 octet 317 subdomain-id: Unique value identifying the BIER sub-domain. 1 octet 319 BFR-id: A 2 octet field encoding the BFR-id, as documented in 320 [RFC8279]. If no BFR-id has been assigned this field is set to 321 the invalid BFR-id. 323 The use of non-zero values in either the BAR field or the IPA field 324 is outside the scope of this document. If an implementation does not 325 support the use of non-zero values in these fields, but receives a 326 BIER Info sub-TLV containing non-zero values in these fields, it 327 SHOULD treat the advertising router as incapable of supporting BIER 328 (one way of handling incapable routers is documented in section 6.9 329 of [RFC8279] and additional methods may be defined in the future). 331 6.2. BIER MPLS Encapsulation sub-sub-TLV 333 This sub-sub-TLV carries the information for the BIER MPLS 334 encapsulation including the label range for a specific bitstring 335 length for a certain . It is advertised within the BIER Info 336 sub-TLV (Section 6.1) . This sub-sub-TLV MAY appear multiple times 337 within a single BIER info sub-TLV. 339 On violation of any of the following conditions, the receiving router 340 MUST ignore the encapsulating BIER Info sub-TLV. 342 o Label ranges in multiple sub-sub-TLVs MUST NOT overlap. 344 o Bitstring lengths in multiple sub-sub-TLVs MUST NOT be identical. 346 o The sub-sub-TLV MUST include the required bitstring lengths 347 encoded in precisely the same way as in [RFC8296]. 349 o All labels in the range MUST represent valid label values 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Type | Length | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Max SI |BS Len | Label | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 Type: value of 1 indicating MPLS encapsulation. 361 Length: 4 363 Local BitString Length (BS Len): Encoded bitstring length as per 364 [RFC8296]. 4 bits. 366 Max SI Maximum Set Identifier (section 1 of [RFC8279]) used in the 367 encapsulation for this BIER sub-domain for this bitstring length, 368 1 octet. Each SI maps to a single label in the label range. The 369 first label is for SI=0, the second label is for SI=1, etc. 371 Label: First label of the range, 20 bits. The labels are as defined 372 in [RFC8296]. 374 7. Security Considerations 376 Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. 377 Advertisement of the additional information defined in this document 378 introduces no new security concerns. 380 BIER specific security considerations are discussed in [RFC8279]. 382 8. Acknowledgements 384 The RFC is aligned with the 385 [I-D.draft-ietf-bier-ospf-bier-extensions-14] draft as far as the 386 protocol mechanisms overlap. 388 Many thanks for comments from (in no particular order) Hannes 389 Gredler, Ijsbrand Wijnands, Peter Psenak and Chris Bowers. 391 9. References 393 9.1. Normative References 395 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 396 dual environments", RFC 1195, DOI 10.17487/RFC1195, 397 December 1990, . 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, 401 DOI 10.17487/RFC2119, March 1997, 402 . 404 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 405 Topology (MT) Routing in Intermediate System to 406 Intermediate Systems (IS-ISs)", RFC 5120, 407 DOI 10.17487/RFC5120, February 2008, 408 . 410 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 411 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 412 2008, . 414 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 415 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 416 2008, . 418 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 419 DOI 10.17487/RFC5308, October 2008, 420 . 422 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 423 and M. Fanto, "IS-IS Generic Cryptographic 424 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 425 2009, . 427 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 428 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 429 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 430 March 2016, . 432 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 433 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 434 May 2017, . 436 9.2. Informative References 438 [I-D.draft-ietf-bier-ospf-bier-extensions-14] 439 Psenak et al., P., "OSPF Extension for Bit Index Explicit 440 Replication", internet-draft draft-ietf-bier-ospf-bier- 441 extensions-14, February 2018. 443 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 444 Writing an IANA Considerations Section in RFCs", BCP 26, 445 RFC 8126, DOI 10.17487/RFC8126, June 2017, 446 . 448 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 449 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 450 Explicit Replication (BIER)", RFC 8279, 451 DOI 10.17487/RFC8279, November 2017, 452 . 454 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 455 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 456 for Bit Index Explicit Replication (BIER) in MPLS and Non- 457 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 458 2018, . 460 Authors' Addresses 462 Les Ginsberg (editor) 463 Cisco Systems 464 510 McCarthy Blvd. 465 Milpitas, CA 95035 466 USA 468 Email: ginsberg@cisco.com 470 Tony Przygienda 471 Juniper Networks 473 Email: prz@juniper.net 475 Sam Aldrin 476 Google 477 1600 Amphitheatre Parkway 478 Mountain View, CA 479 USA 481 Email: aldrin.ietf@gmail.com 483 Jeffrey (Zhaohui) Zhang 484 Juniper Networks, Inc. 485 10 Technology Park Drive 486 Westford, MA 01886 487 USA 489 Email: zzhang@juniper.net