idnits 2.17.1 draft-ietf-bier-isis-extensions-03.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 (September 22, 2016) is 2771 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 (-08) exists of draft-ietf-bier-architecture-04 == Outdated reference: A later version (-12) exists of draft-ietf-bier-mpls-encapsulation-05 == Outdated reference: A later version (-18) exists of draft-ietf-bier-ospf-bier-extensions-04 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 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: March 26, 2017 Juniper Networks 6 S. Aldrin 7 Google 8 J. Zhang 9 Juniper Networks, Inc. 10 September 22, 2016 12 BIER support via ISIS 13 draft-ietf-bier-isis-extensions-03 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 March 26, 2017. 43 Copyright Notice 45 Copyright (c) 2016 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 . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . 6 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. Normative References . . . . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 Bit Index Explicit Replication (BIER) 88 [I-D.draft-ietf-bier-architecture-04] defines an architecture where 89 all intended multicast receivers are encoded as bitmask in the 90 Multicast packet header within different encapsulations such as 91 [I-D.draft-ietf-bier-mpls-encapsulation-05]. A router that receives 92 such a packet will forward the packet based on the Bit Position in 93 the packet header towards the receiver(s), following a precomputed 94 tree for each of the bits in the packet. Each receiver is 95 represented by a unique bit in the bitmask. 97 This document presents necessary extensions to the currently deployed 98 ISIS for IP [RFC1195] protocol to support distribution of information 99 necessary for operation of BIER domains and sub-domains. This 100 document defines a new TLV to be advertised by every router 101 participating in BIER signaling. 103 2. Terminology 105 Some of the terminology specified in 106 [I-D.draft-ietf-bier-architecture-04] is replicated here and extended 107 by necessary definitions: 109 BIER: Bit Index Explicit Replication (The overall architecture of 110 forwarding multicast using a Bit Position). 112 BIER-OL: BIER Overlay Signaling. (The method for the BFIR to learn 113 about BFER's). 115 BFR: Bit Forwarding Router (A router that participates in Bit Index 116 Multipoint Forwarding). A BFR is identified by a unique BFR- 117 prefix in a BIER domain. 119 BFIR: Bit Forwarding Ingress Router (The ingress border router that 120 inserts the BM into the packet). Each BFIR must have a valid BFR- 121 id assigned. 123 BFER: Bit Forwarding Egress Router. A router that participates in 124 Bit Index Forwarding as leaf. Each BFER must be a BFR. Each BFER 125 must have a valid BFR-id assigned. 127 BFT: Bit Forwarding Tree used to reach all BFERs in a domain. 129 BIFT: Bit Index Forwarding Table. 131 BMS: Bit Mask Set. Set containing bit positions of all BFER 132 participating in a set. 134 BMP: Bit Mask Position, a given bit in a BMS. 136 Invalid BMP: Unassigned Bit Mask Position, consisting of all 0s. 138 IGP signalled BIER domain: A BIER underlay where the BIER 139 synchronization information is carried in IGP. Observe that a 140 multi-topology is NOT a separate BIER domain in IGP. 142 BIER sub-domain: A further distinction within a BIER domain 143 identified by its unique sub-domain identifier. A BIER sub-domain 144 can support multiple BitString Lengths. 146 BFR-id: An optional, unique identifier for a BFR within a BIER sub- 147 domain. 149 Invalid BFR-id: Unassigned BFR-id, consisting of all 0s. 151 3. IANA Considerations 153 This document adds the following new sub-TLV to the registry of sub- 154 TLVs for TLVs 235, 237 [RFC5120] and TLVs 135,236 155 [RFC5305],[RFC5308]. 157 Value: 32 (suggested - to be assigned by IANA) 159 Name: BIER Info 161 This document also introduces a new registry for sub-sub-TLVs for the 162 BIER Info sub-TLV added above. The registration policy is Expert 163 Review as defined in [RFC5226]. This registry is part of the "IS-IS 164 TLV Codepoints" registry. The name of the registry is "sub-sub-TLVs 165 for BIER Info sub-TLV". The defined values are: 167 Type Name 168 ---- ---- 169 1 BIER MPLS Encapsulation 170 2 BIER sub-domain Tree Type 171 3 BIER sub-domain BSL conversion 173 4. Concepts 175 4.1. BIER Domains and Sub-Domains 177 An ISIS signalled BIER domain is aligned with the scope of 178 distribution of BFR-prefixes that identify the BFRs within ISIS. 179 ISIS acts in such a case as the supporting BIER underlay. 181 Within such a domain, the extensions defined in this document 182 advertise BIER information for one or more BIER sub-domains. Each 183 sub-domain is uniquely identified by a subdomain-id. Each subdomain 184 is associated with a single ISIS topology [RFC5120], which may be any 185 of the topologies supported by ISIS. Local configuration controls 186 which pairs are supported by a router. The mapping of sub- 187 domains to topologies MUST be consistent within a BIER flooding 188 domain. 190 Each BIER sub-domain has as its unique attributes the encapsulation 191 used and the type of tree it is using to forward BIER frames 192 (currently always SPF). Additionally, per supported bitstring length 193 in the sub-domain, each router will advertise the necessary label 194 ranges to support it. 196 4.2. Advertising BIER Information 198 BIER information advertisements are associated with a new sub-TLV in 199 the extended reachability TLVs. BIER information is always 200 associated with a host prefix which MUST be a node address for the 201 advertising node. The following restrictions apply: 203 o Prefix length MUST be 32 for an IPv4 prefix or 128 for an IPv6 204 prefix 206 o When the Prefix Attributes Flags sub-TLV is present N flag MUST be 207 set and X and R flags MUST NOT be set. [RFC7794] 209 o BIER sub-TLVs MUST NOT be included when a prefix reachability 210 advertisement is leaked between levels. 212 5. Procedures 214 5.1. Enabling a BIER Sub-Domain 216 A given sub-domain with identifier SD with supported bitstring 217 lengths MLs in a multi-topology MT [RFC5120] is denoted further as 218 and does not have to be advertised by default by BFRs to 219 preserve the scaling of the protocol (i.e. ISIS carries no TLVs 220 containing any of the elements related to ). The 221 advertisement may be triggered e.g. by a first BIER sub-TLV 222 (Section 6.1) containing advertised into the area. The 223 specific trigger itself is outside the scope of this RFC but can be 224 for example a VPN desiring to initiate a BIER sub-domain as MI-PMSI 225 [RFC6513] tree or a pre-configured BFER (since BFERs will always 226 advertise the BIER sub-TLV to make sure they can be reached). It is 227 outside the scope of this document to describe what trigger for a 228 router capable of participating in is used to start the 229 origination of the necessary information to join into it. 231 5.2. Multi Topology and Sub-Domain 233 A given sub-domain is supported within one and only one topology. 234 All routers in the flooding scope of the BIER sub-TLVs MUST advertise 235 the same sub-domain within the same multi-topology. A router 236 receiving an advertisement which does not match the locally 237 configured pair MUST report a misconfiguration of the received pair. All received BIER advertisements associated with the 239 conflicting pair MUST be ignored. 241 5.3. Encapsulation 243 All routers in the flooding scope of the BIER TLVs MUST advertise the 244 same encapsulation for a given . A router discovering 245 encapsulation advertised that is different from its own MUST report a 246 misconfiguration of a specific . All received BIER 247 advertisements associated with the conflicting pair MUST be 248 ignored. 250 5.4. Tree Type 252 All routers in the flooding scope of the BIER TLVs MAY advertise a 253 supported tree type for a given . Tree type indicates the 254 algorithm used when calculating the optimal path. Currently only the 255 default algorithm "SPF" is defined - which has a tree type of 0. If 256 no tree type is advertised tree type 0 is assumed. The supported 257 tree type MUST be consistent for all routers supporting a given 258 . 260 5.5. Label advertisements for MPLS Encapsulation 262 A router that desires to participate in MUST advertise for 263 each bitstring length it supports in a label range size that 264 guarantees to cover the maximum BFR-id injected into (which 265 implies a certain maximum set id per bitstring length as described in 266 [I-D.draft-ietf-bier-architecture-04]). Any router that violates 267 this condition MUST be excluded from BIER BFTs for . 269 5.6. BFR-id Advertisements 271 Each BFER/BFIR MAY advertise with its TLV the BFR-id that it 272 has administratively chosen. A valid BFR-id MUST be unique within 273 the flooding scope of the BIER advertisments. All BFERs/BFIRs MUST 274 detect advertisement of duplicate valid BFR-IDs for a given . 275 When such duplication is detected all of the routers advertising 276 duplicates MUST be treated as if they did not advertise a valid BFR- 277 id. This implies they cannot act as BFER or BFIR in that . 279 5.7. Reporting Misconfiguration 281 Whenever an advertisement is received which violates any of the 282 constraints defined in this document the receiving router MUST report 283 the misconfiguration. 285 5.8. Flooding Reduction 287 BIER domain information SHOULD change infrequently. Frequent changes 288 will increase the number of Link State PDU (LSP) updates and 289 negatively impact performance in the network. 291 6. Packet Formats 293 All ISIS BIER information is carried within the TLVs 235, 237 294 [RFC5120] or TLVs 135 [RFC5305], or TLV 236 [RFC5308]. 296 6.1. BIER Info sub-TLV 298 This sub-TLV carries the information for the BIER sub-domains that 299 the router participates in as BFR. This sub-TLV MAY appear multiple 300 times in a given prefix-reachability TLV - once for each sub-domain 301 supported in the associated topology. 303 The sub-TLV advertises a single combination followed by 304 optional sub-sub-TLVs as described in the following sections. 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Type | Length | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Reserved | subdomain-id | BFR-id | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Type: as indicated in IANA section. 316 Length: 1 octet. 318 Reserved: MUST be 0 on transmission, ignored on reception. May be 319 used in future versions. 8 bits 321 subdomain-id: Unique value identifying the BIER sub-domain. 1 octet 323 BFR-id: A 2 octet field encoding the BFR-id, as documented in 324 [I-D.draft-ietf-bier-architecture-04]. If no BFR-id has been 325 assigned this field is set to the invalid BFR-id. 327 6.2. BIER MPLS Encapsulation sub-sub-TLV 329 This sub-sub-TLV carries the information for the BIER MPLS 330 encapsulation including the label range for a specific bitstring 331 length for a certain . It is advertised within the BIER Info 332 sub-TLV (Section 6.1) . This sub-sub-TLV MAY appear multiple times 333 within a single BIER info sub-TLV. 335 On violation of any of the following conditions, the receiving router 336 MUST ignore the encapsulating BIER Info sub-TLV. 338 o Label ranges in multiple sub-sub-TLV MUST NOT overlap. 340 o Bitstring lengths in multiple sub-sub-TLVs MUST NOT be identical. 342 o The sub-sub-TLV MUST include the required bitstring lengths 343 encoded in precisely the same way as in 344 [I-D.draft-ietf-bier-mpls-encapsulation-05]. 346 o The label range size MUST be greater than 0. 348 o All labels in the range MUST represent valid label values 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 | Lbl Range Size|BS Len | Label | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Type: value of 1 indicating MPLS encapsulation. 360 Length: 1 octet. 362 Local BitString Length (BS Len): Encoded bitstring length as per [I- 363 D.draft-ietf-bier-mpls-encapsulation-05]. 4 bits. 365 Label Range Size: Number of labels in the range used on 366 encapsulation for this BIER sub-domain for this bitstring length, 367 1 octet. 369 Label: First label of the range, 20 bits. The labels are as defined 370 in [I-D.draft-ietf-bier-mpls-encapsulation-05]. 372 6.3. Optional BIER sub-domain Tree Type sub-sub-TLV 374 This sub-sub-TLV carries the information associated with the 375 supported BIER tree type for a combination. It is carried 376 within the BIER Info sub-TLV (Section 6.1) that the router 377 participates in as BFR. This sub-sub-TLV is optional and its absence 378 has the same semantics as its presence with Tree Type value 0 (SPF). 379 When Tree Type 0 is used it is recommended that this sub-sub-TLV be 380 omitted in order to reduce the space consumed in the parent TLV. 382 This sub-sub-TLV MUST NOT occur more than once in a BIER Info sub- 383 TLV. If multiple occurences of this sub-sub-TLV are present in a 384 single BIER Info sub-TLV the encapsulating BIER Info sub-TLV MUST be 385 ignored. 387 If the tree type (implied or explicitly advertised) does not match 388 the locally configured tree type associated with the matching pair the encapsulating sub-TLV MUST be ignored. 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Type | Length | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Tree Type | 397 +-+-+-+-+-+-+-+-+ 399 Type: value of 1 indicating BIER Tree Type. 401 Length: 1 octet. 403 Tree Type: 1 octet 405 6.4. Optional BIER sub-domain BSL conversion sub-sub-TLV 407 This sub-sub-TLV indicates whether the BFR is capable of imposing a 408 different Bit String Length (BSL) than the one it received in a BIER 409 encapsulated packet. Such a capability may allow future, advanced 410 tree types which ensure simple migration procedures from one BSL to 411 another in a given or prevent stable blackholes in scenarios 412 where not all routers support the same set of BSLs in a given 413 . It is carried within the BIER Info sub-TLV (Section 6.1). 414 This sub-sub-TLV is optional and its absence indicates that the 415 router is NOT capable of imposing different BSLs but will always 416 forward the packet with the BSL unchanged. This sub-sub-TLV MAY 417 occur at most once in a given BIER info sub-TLV. If multiple 418 occurences of this sub-sub-TLV are received in a given BIER info sub- 419 TLV the encapsulating sub-TLV MUST be ignored. 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Type | Length | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 7. Security Considerations 429 Implementations must assure that malformed TLV and Sub-TLV 430 permutations do not result in errors which cause hard protocol 431 failures. 433 8. Acknowledgements 435 The RFC is aligned with the 436 [I-D.draft-ietf-bier-ospf-bier-extensions-04] draft as far as the 437 protocol mechanisms overlap. 439 Many thanks for comments from (in no particular order) Hannes 440 Gredler, Ijsbrand Wijnands, Peter Psenak and Chris Bowers. 442 9. Normative References 444 [I-D.draft-ietf-bier-architecture-04] 445 Wijnands et al., IJ., "Stateless Multicast using Bit Index 446 Explicit Replication Architecture", internet-draft draft- 447 ietf-bier-architecture-04.txt, Jul 2016. 449 [I-D.draft-ietf-bier-mpls-encapsulation-05] 450 Wijnands et al., IJ., "Bit Index Explicit Replication 451 using MPLS encapsulation", internet-draft draft-ietf-bier- 452 mpls-encapsulation-05.txt, Jul 2016. 454 [I-D.draft-ietf-bier-ospf-bier-extensions-04] 455 Psenak et al., P., "OSPF Extension for Bit Index Explicit 456 Replication", internet-draft draft-ietf-bier-ospf-bier- 457 extensions-04.txt, Sep 2016. 459 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 460 dual environments", RFC 1195, DOI 10.17487/RFC1195, 461 December 1990, . 463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", BCP 14, RFC 2119, 465 DOI 10.17487/RFC2119, March 1997, 466 . 468 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 469 Topology (MT) Routing in Intermediate System to 470 Intermediate Systems (IS-ISs)", RFC 5120, 471 DOI 10.17487/RFC5120, February 2008, 472 . 474 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 475 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 476 DOI 10.17487/RFC5226, May 2008, 477 . 479 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 480 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 481 2008, . 483 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 484 DOI 10.17487/RFC5308, October 2008, 485 . 487 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 488 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 489 2012, . 491 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 492 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 493 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 494 March 2016, . 496 Authors' Addresses 498 Les Ginsberg (editor) 499 Cisco Systems 500 510 McCarthy Blvd. 501 Milpitas, CA 95035 502 USA 504 Email: ginsberg@cisco.com 506 Tony Przygienda 507 Juniper Networks 509 Email: prz@juniper.net 510 Sam Aldrin 511 Google 512 1600 Amphitheatre Parkway 513 Mountain View, CA 514 USA 516 Email: aldrin.ietf@gmail.com 518 Jeffrey (Zhaohui) Zhang 519 Juniper Networks, Inc. 520 10 Technology Park Drive 521 Westford, MA 01886 522 USA 524 Email: zzhang@juniper.net