idnits 2.17.00 (12 Aug 2021) /tmp/idnits21288/draft-ietf-bier-isis-extensions-07.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 9, 2018) is 1562 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-ospf-bier-extensions has been published as RFC 8444 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 13, 2018 Juniper Networks 6 S. Aldrin 7 Google 8 J. Zhang 9 Juniper Networks, Inc. 10 February 9, 2018 12 BIER support via ISIS 13 draft-ietf-bier-isis-extensions-07 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 https://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 August 13, 2018. 43 Copyright Notice 45 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . 3 63 4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. BIER Domains and Sub-Domains . . . . . . . . . . . . . . 4 65 4.2. Advertising BIER Information . . . . . . . . . . . . . . 4 66 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5.1. Multi Topology and Sub-Domain . . . . . . . . . . . . . . 5 68 5.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 5 69 5.3. BIER Algorithm . . . . . . . . . . . . . . . . . . . . . 5 70 5.4. Label advertisements for MPLS Encapsulation . . . . . . . 6 71 5.5. BFR-id Advertisements . . . . . . . . . . . . . . . . . . 6 72 5.6. Reporting Misconfiguration . . . . . . . . . . . . . . . 6 73 5.7. Flooding Reduction . . . . . . . . . . . . . . . . . . . 6 74 6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 6 75 6.1. BIER Info sub-TLV . . . . . . . . . . . . . . . . . . . . 6 76 6.2. BIER MPLS Encapsulation sub-sub-TLV . . . . . . . . . . . 7 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 81 9.2. Informative References . . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 2. Terminology 103 Some of the terminology specified in [RFC8279] is replicated here and 104 extended by necessary definitions: 106 BIER: Bit Index Explicit Replication (The overall architecture of 107 forwarding multicast using a Bit Position). 109 BIER-OL: BIER Overlay Signaling. (The method for the BFIR to learn 110 about BFER's). 112 BFR: Bit Forwarding Router (A router that participates in Bit Index 113 Multipoint Forwarding). A BFR is identified by a unique BFR- 114 prefix in a BIER domain. 116 BFIR: Bit Forwarding Ingress Router (The ingress border router that 117 inserts the BM into the packet). Each BFIR must have a valid BFR- 118 id assigned. 120 BFER: Bit Forwarding Egress Router. A router that participates in 121 Bit Index Forwarding as leaf. Each BFER must be a BFR. Each BFER 122 must have a valid BFR-id assigned. 124 BFT: Bit Forwarding Tree used to reach all BFERs in a domain. 126 BIER sub-domain: A further distinction within a BIER domain 127 identified by its unique sub-domain identifier. A BIER sub-domain 128 can support multiple BitString Lengths. 130 BFR-id: An optional, unique identifier for a BFR within a BIER sub- 131 domain. 133 Invalid BFR-id: Unassigned BFR-id. The special value 0 is reserved 134 for this purpose. 136 BAR BIER Algorithm. Algorithm used to calculate nexthops. 138 3. IANA Considerations 140 This document adds the following new sub-TLV to the registry of sub- 141 TLVs for TLVs 235, 237 [RFC5120] and TLVs 135,236 142 [RFC5305],[RFC5308]. 144 Value: 32 (suggested - to be assigned by IANA) 146 Name: BIER Info 148 This document also introduces a new registry for sub-sub-TLVs for the 149 BIER Info sub-TLV added above. The registration policy is Expert 150 Review as defined in [RFC8126]. This registry is part of the "IS-IS 151 TLV Codepoints" registry. The name of the registry is "sub-sub-TLVs 152 for BIER Info sub-TLV". The defined values are: 154 Type Name 155 ---- ---- 156 1 BIER MPLS Encapsulation 158 4. Concepts 160 4.1. BIER Domains and Sub-Domains 162 An ISIS signalled BIER domain is aligned with the scope of 163 distribution of BFR-prefixes that identify the BFRs within ISIS. 164 ISIS acts in such a case as the supporting BIER underlay. 166 Within such a domain, the extensions defined in this document 167 advertise BIER information for one or more BIER sub-domains. Each 168 sub-domain is uniquely identified by a subdomain-id. Each subdomain 169 is associated with a single ISIS topology [RFC5120], which may be any 170 of the topologies supported by ISIS. Local configuration controls 171 which pairs are supported by a router. The mapping of sub- 172 domains to topologies MUST be consistent within the IS-IS flooding 173 domain used to advertise BIER information. 175 Each BIER sub-domain has as its unique attributes the encapsulation 176 used and the type of tree it is using to forward BIER frames 177 (currently always SPF). Additionally, per supported bitstring length 178 in the sub-domain, each router will advertise the necessary label 179 ranges to support it. 181 4.2. Advertising BIER Information 183 BIER information advertisements are associated with a new sub-TLV in 184 the extended reachability TLVs. BIER information is always 185 associated with a host prefix which MUST be a node address for the 186 advertising node. The following restrictions apply: 188 o Prefix length MUST be 32 for an IPv4 prefix or 128 for an IPv6 189 prefix 191 o When the Prefix Attributes Flags sub-TLV is present N flag MUST be 192 set. [RFC7794] 194 o BIER sub-TLVs MUST be included when a prefix reachability 195 advertisement is leaked between levels. 197 5. Procedures 199 5.1. Multi Topology and Sub-Domain 201 A given sub-domain is supported within one and only one topology. 202 All routers in the flooding scope of the BIER sub-TLVs MUST advertise 203 the same sub-domain within the same multi-topology. A router 204 receiving an advertisement which does not match the locally 205 configured pair MUST report a misconfiguration of the received 206 pair. All received BIER advertisements associated with the 207 conflicting pair MUST be ignored. 209 Example: 211 The following combination of advertisements are valid: <0,0> <0,1> 212 <2,2>. 214 The following combination of advertisements are invalid: <0,0> <0,1> 215 <2,0>. Advertisements associated with <0,0> and <2,0> MUST be 216 ignored. 218 5.2. Encapsulation 220 Multiple encapsulations MAY be advertised/supported for a given 221 . Clearly, however, there MUST be at least one encapsulation 222 type in common in order for a BIER encapsulated packet to be 223 successfully forwarded between two BFRs. 225 5.3. BIER Algorithm 227 All routers in the flooding scope of the BIER TLVs MUST advertise a 228 supported algorithm for a given . The specified algorithm is 229 used when calculating the optimal path. The supported algorithm MUST 230 be consistent for all routers supporting a given . A router 231 receiving an advertisement with a BAR which does not match 232 the locally configured value MUST report a misconfiguration of the 233 received pair. All received BIER advertisements associated 234 with the conflicting pair MUST be ignored. 236 Currently only the default algorithm "SPF" is defined - which has a 237 reserved value of 0 and represents Shortest Path First (SPF) based on 238 IGP link metric. This is the standard shortest path algorithm as 239 computed by the IS-IS protocol. 241 5.4. Label advertisements for MPLS Encapsulation 243 A router that desires to participate in MUST advertise for 244 each bitstring length it supports in a Maximum Set ID that 245 guarantees to cover the maximum BFR-id injected into (which 246 implies a certain maximum set id per bitstring length as described in 247 [RFC8279]). Any router that violates this condition MUST be excluded 248 from BIER BFTs for . 250 5.5. BFR-id Advertisements 252 Each BFER/BFIR MAY advertise with its TLV the BFR-id that it 253 has administratively chosen. A valid BFR-id MUST be unique within 254 the flooding scope of the BIER advertisements. All BFERs/BFIRs MUST 255 detect advertisement of duplicate valid BFR-IDs for a given . 256 When such duplication is detected all of the routers advertising 257 duplicates MUST be treated as if they did not advertise a valid BFR- 258 id. This implies they cannot act as BFER or BFIR in that . 260 5.6. Reporting Misconfiguration 262 Whenever an advertisement is received which violates any of the 263 constraints defined in this document the receiving router MUST report 264 the misconfiguration. Such reports SHOULD be dampened to avoid 265 excessive logging output. 267 5.7. Flooding Reduction 269 BIER domain information SHOULD change infrequently. Frequent changes 270 will increase the number of Link State PDU (LSP) updates and 271 negatively impact performance in the network. 273 6. Packet Formats 275 All ISIS BIER information is carried within the TLVs 235, 237 276 [RFC5120] or TLVs 135 [RFC5305], or TLV 236 [RFC5308]. 278 6.1. BIER Info sub-TLV 280 This sub-TLV carries the information for the BIER sub-domains that 281 the router participates in as BFR. This sub-TLV MAY appear multiple 282 times in a given prefix-reachability TLV - once for each sub-domain 283 supported in the associated topology. 285 The sub-TLV advertises a single combination followed by 286 optional sub-sub-TLVs as described in the following sections. 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Type | Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | BAR | subdomain-id | BFR-id | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | sub-sub-TLVs (variable) | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Type: as indicated in IANA section. 300 Length: variable 302 BAR BIER Algorithm. 0 is the only supported value defined in this 303 document. Other values may be defined in the future. 8 bits 305 subdomain-id: Unique value identifying the BIER sub-domain. 1 octet 307 BFR-id: A 2 octet field encoding the BFR-id, as documented in 308 [RFC8279]. If no BFR-id has been assigned this field is set to 309 the invalid BFR-id. 311 6.2. BIER MPLS Encapsulation sub-sub-TLV 313 This sub-sub-TLV carries the information for the BIER MPLS 314 encapsulation including the label range for a specific bitstring 315 length for a certain . It is advertised within the BIER Info 316 sub-TLV (Section 6.1) . This sub-sub-TLV MAY appear multiple times 317 within a single BIER info sub-TLV. 319 On violation of any of the following conditions, the receiving router 320 MUST ignore the encapsulating BIER Info sub-TLV. 322 o Label ranges in multiple sub-sub-TLV MUST NOT overlap. 324 o Bitstring lengths in multiple sub-sub-TLVs MUST NOT be identical. 326 o The sub-sub-TLV MUST include the required bitstring lengths 327 encoded in precisely the same way as in [RFC8296]. 329 o All labels in the range MUST represent valid label values 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Type | Length | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Max SI |BS Len | Label | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Type: value of 1 indicating MPLS encapsulation. 340 Length: 4 342 Local BitString Length (BS Len): Encoded bitstring length as per 343 [RFC8296]. 4 bits. 345 Max SI Maximum Set Identifier (section 1 of [RFC8279]) used in the 346 encapsulation for this BIER sub-domain for this bitstring length, 347 1 octet. Each SI maps to a single label in the label range. The 348 first label is for SI=0, the second label is for SI=1, etc. 350 Label: First label of the range, 20 bits. The labels are as defined 351 in [RFC8296]. 353 7. Security Considerations 355 Implementations must assure that malformed TLV and Sub-TLV 356 permutations do not result in errors which cause hard protocol 357 failures. 359 8. Acknowledgements 361 The RFC is aligned with the 362 [I-D.draft-ietf-bier-ospf-bier-extensions-10] draft as far as the 363 protocol mechanisms overlap. 365 Many thanks for comments from (in no particular order) Hannes 366 Gredler, Ijsbrand Wijnands, Peter Psenak and Chris Bowers. 368 9. References 370 9.1. Normative References 372 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 373 dual environments", RFC 1195, DOI 10.17487/RFC1195, 374 December 1990, . 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, 378 DOI 10.17487/RFC2119, March 1997, 379 . 381 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 382 Topology (MT) Routing in Intermediate System to 383 Intermediate Systems (IS-ISs)", RFC 5120, 384 DOI 10.17487/RFC5120, February 2008, 385 . 387 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 388 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 389 2008, . 391 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 392 DOI 10.17487/RFC5308, October 2008, 393 . 395 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 396 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 397 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 398 March 2016, . 400 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 401 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 402 Explicit Replication (BIER)", RFC 8279, 403 DOI 10.17487/RFC8279, November 2017, 404 . 406 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 407 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 408 for Bit Index Explicit Replication (BIER) in MPLS and Non- 409 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 410 2018, . 412 9.2. Informative References 414 [I-D.draft-ietf-bier-ospf-bier-extensions-10] 415 Psenak et al., P., "OSPF Extension for Bit Index Explicit 416 Replication", internet-draft draft-ietf-bier-ospf-bier- 417 extensions-09.txt, Dec 2017. 419 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 420 Writing an IANA Considerations Section in RFCs", BCP 26, 421 RFC 8126, DOI 10.17487/RFC8126, June 2017, 422 . 424 Authors' Addresses 426 Les Ginsberg (editor) 427 Cisco Systems 428 510 McCarthy Blvd. 429 Milpitas, CA 95035 430 USA 432 Email: ginsberg@cisco.com 434 Tony Przygienda 435 Juniper Networks 437 Email: prz@juniper.net 439 Sam Aldrin 440 Google 441 1600 Amphitheatre Parkway 442 Mountain View, CA 443 USA 445 Email: aldrin.ietf@gmail.com 447 Jeffrey (Zhaohui) Zhang 448 Juniper Networks, Inc. 449 10 Technology Park Drive 450 Westford, MA 01886 451 USA 453 Email: zzhang@juniper.net