idnits 2.17.1 draft-ietf-bier-isis-extensions-06.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 (October 22, 2017) is 2379 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 (-12) exists of draft-ietf-bier-mpls-encapsulation-10 == Outdated reference: A later version (-18) exists of draft-ietf-bier-ospf-bier-extensions-08 Summary: 0 errors (**), 0 flaws (~~), 3 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: April 25, 2018 Juniper Networks 6 S. Aldrin 7 Google 8 J. Zhang 9 Juniper Networks, Inc. 10 October 22, 2017 12 BIER support via ISIS 13 draft-ietf-bier-isis-extensions-06 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 April 25, 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 (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 . . . . . . . . . . . . . . . . . . . . . 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. 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 6.3. Optional BIER sub-domain BSL conversion sub-sub-TLV . . . 8 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 82 9.2. Informative References . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Introduction 87 Bit Index Explicit Replication (BIER) 88 [I-D.draft-ietf-bier-architecture-08] 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-10]. 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-08] 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 BIER sub-domain: A further distinction within a BIER domain 130 identified by its unique sub-domain identifier. A BIER sub-domain 131 can support multiple BitString Lengths. 133 BFR-id: An optional, unique identifier for a BFR within a BIER sub- 134 domain. 136 Invalid BFR-id: Unassigned BFR-id. The special value 0 is reserved 137 for this purpose. 139 BAR BIER Algorithm. Algorithm used to calculate unicast nexthops 141 3. IANA Considerations 143 This document adds the following new sub-TLV to the registry of sub- 144 TLVs for TLVs 235, 237 [RFC5120] and TLVs 135,236 145 [RFC5305],[RFC5308]. 147 Value: 32 (suggested - to be assigned by IANA) 149 Name: BIER Info 151 This document also introduces a new registry for sub-sub-TLVs for the 152 BIER Info sub-TLV added above. The registration policy is Expert 153 Review as defined in [RFC8126]. This registry is part of the "IS-IS 154 TLV Codepoints" registry. The name of the registry is "sub-sub-TLVs 155 for BIER Info sub-TLV". The defined values are: 157 Type Name 158 ---- ---- 159 1 BIER MPLS Encapsulation 160 3 BIER sub-domain BSL conversion 162 4. Concepts 164 4.1. BIER Domains and Sub-Domains 166 An ISIS signalled BIER domain is aligned with the scope of 167 distribution of BFR-prefixes that identify the BFRs within ISIS. 168 ISIS acts in such a case as the supporting BIER underlay. 170 Within such a domain, the extensions defined in this document 171 advertise BIER information for one or more BIER sub-domains. Each 172 sub-domain is uniquely identified by a subdomain-id. Each subdomain 173 is associated with a single ISIS topology [RFC5120], which may be any 174 of the topologies supported by ISIS. Local configuration controls 175 which pairs are supported by a router. The mapping of sub- 176 domains to topologies MUST be consistent within a BIER flooding 177 domain. 179 Each BIER sub-domain has as its unique attributes the encapsulation 180 used and the type of tree it is using to forward BIER frames 181 (currently always SPF). Additionally, per supported bitstring length 182 in the sub-domain, each router will advertise the necessary label 183 ranges to support it. 185 4.2. Advertising BIER Information 187 BIER information advertisements are associated with a new sub-TLV in 188 the extended reachability TLVs. BIER information is always 189 associated with a host prefix which MUST be a node address for the 190 advertising node. The following restrictions apply: 192 o Prefix length MUST be 32 for an IPv4 prefix or 128 for an IPv6 193 prefix 195 o When the Prefix Attributes Flags sub-TLV is present N flag MUST be 196 set. [RFC7794] 198 o BIER sub-TLVs MUST be included when a prefix reachability 199 advertisement is leaked between levels. 201 5. Procedures 203 5.1. Multi Topology and Sub-Domain 205 A given sub-domain is supported within one and only one topology. 206 All routers in the flooding scope of the BIER sub-TLVs MUST advertise 207 the same sub-domain within the same multi-topology. A router 208 receiving an advertisement which does not match the locally 209 configured pair MUST report a misconfiguration of the received pair. All received BIER advertisements associated with the 211 conflicting pair MUST be ignored. 213 5.2. Encapsulation 215 All routers in the flooding scope of the BIER TLVs MUST advertise the 216 same encapsulation for a given . A router discovering 217 encapsulation advertised that is different from its own MUST report a 218 misconfiguration of a specific . All received BIER 219 advertisements associated with the conflicting pair MUST be 220 ignored. 222 5.3. BIER Algorithm 224 All routers in the flooding scope of the BIER TLVs MUST advertise a 225 supported algorithm for a given . The specified algorithm is 226 used when calculating the optimal path. Currently only the default 227 algorithm "SPF" is defined - which has a reserved value of 0. The 228 supported algorithm MUST be consistent for all routers supporting a 229 given . A router receiving an advertisement with a 230 BAR which does not match the locally configured value MUST report a 231 misconfiguration of the received pair. All received BIER 232 advertisements associated with the conflicting pair MUST be 233 ignored. 235 5.4. Label advertisements for MPLS Encapsulation 237 A router that desires to participate in MUST advertise for 238 each bitstring length it supports in a label range size that 239 guarantees to cover the maximum BFR-id injected into (which 240 implies a certain maximum set id per bitstring length as described in 241 [I-D.draft-ietf-bier-architecture-08]). Any router that violates 242 this condition MUST be excluded from BIER BFTs for . 244 5.5. BFR-id Advertisements 246 Each BFER/BFIR MAY advertise with its TLV the BFR-id that it 247 has administratively chosen. A valid BFR-id MUST be unique within 248 the flooding scope of the BIER advertisments. All BFERs/BFIRs MUST 249 detect advertisement of duplicate valid BFR-IDs for a given . 250 When such duplication is detected all of the routers advertising 251 duplicates MUST be treated as if they did not advertise a valid BFR- 252 id. This implies they cannot act as BFER or BFIR in that . 254 5.6. Reporting Misconfiguration 256 Whenever an advertisement is received which violates any of the 257 constraints defined in this document the receiving router MUST report 258 the misconfiguration. Such reports SHOULD be dampened to avoid 259 excessive logging output. 261 5.7. Flooding Reduction 263 BIER domain information SHOULD change infrequently. Frequent changes 264 will increase the number of Link State PDU (LSP) updates and 265 negatively impact performance in the network. 267 6. Packet Formats 269 All ISIS BIER information is carried within the TLVs 235, 237 270 [RFC5120] or TLVs 135 [RFC5305], or TLV 236 [RFC5308]. 272 6.1. BIER Info sub-TLV 274 This sub-TLV carries the information for the BIER sub-domains that 275 the router participates in as BFR. This sub-TLV MAY appear multiple 276 times in a given prefix-reachability TLV - once for each sub-domain 277 supported in the associated topology. 279 The sub-TLV advertises a single combination followed by 280 optional sub-sub-TLVs as described in the following sections. 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Type | Length | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | BAR | subdomain-id | BFR-id | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | sub-sub-TLVs (variable) | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Type: as indicated in IANA section. 294 Length: variable 296 BAR BIER Algorithm. 0 is the only supported value defined in this 297 document. Other values may be defined in the future. 8 bits 299 subdomain-id: Unique value identifying the BIER sub-domain. 1 octet 301 BFR-id: A 2 octet field encoding the BFR-id, as documented in 302 [I-D.draft-ietf-bier-architecture-08]. If no BFR-id has been 303 assigned this field is set to the invalid BFR-id. 305 6.2. BIER MPLS Encapsulation sub-sub-TLV 307 This sub-sub-TLV carries the information for the BIER MPLS 308 encapsulation including the label range for a specific bitstring 309 length for a certain . It is advertised within the BIER Info 310 sub-TLV (Section 6.1) . This sub-sub-TLV MAY appear multiple times 311 within a single BIER info sub-TLV. 313 On violation of any of the following conditions, the receiving router 314 MUST ignore the encapsulating BIER Info sub-TLV. 316 o Label ranges in multiple sub-sub-TLV MUST NOT overlap. 318 o Bitstring lengths in multiple sub-sub-TLVs MUST NOT be identical. 320 o The sub-sub-TLV MUST include the required bitstring lengths 321 encoded in precisely the same way as in 322 [I-D.draft-ietf-bier-mpls-encapsulation-10]. 324 o The label range size MUST be greater than 0. 326 o All labels in the range MUST represent valid label values 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Type | Length | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Lbl Range Size|BS Len | Label | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Type: value of 1 indicating MPLS encapsulation. 338 Length: 4 340 Local BitString Length (BS Len): Encoded bitstring length as per [I- 341 D.draft-ietf-bier-mpls-encapsulation-10]. 4 bits. 343 Label Range Size: Number of labels in the range used on 344 encapsulation for this BIER sub-domain for this bitstring length, 345 1 octet. The size of the label range is determined by the number 346 of Set Identifiers (SI) (section 1 of [I-D.ietf-bier- 347 architecture]) that are used in the network. Each SI maps to a 348 single label in the label range. The first label is for SI=0, the 349 second label is for SI=1, etc. 351 Label: First label of the range, 20 bits. The labels are as defined 352 in [I-D.draft-ietf-bier-mpls-encapsulation-10]. 354 6.3. Optional BIER sub-domain BSL conversion sub-sub-TLV 356 This sub-sub-TLV indicates whether the BFR is capable of imposing a 357 different Bit String Length (BSL) than the one it received in a BIER 358 encapsulated packet. Such a capability may allow future, advanced 359 tree types which ensure simple migration procedures from one BSL to 360 another in a given or prevent stable blackholes in scenarios 361 where not all routers support the same set of BSLs in a given 362 . Conversions are supported only between the set of BSLs 363 advertised as supported by the router. It is carried within the BIER 364 Info sub-TLV (Section 6.1). This sub-sub-TLV is optional and its 365 absence indicates that the router is NOT capable of imposing 366 different BSLs but will always forward the packet with the BSL 367 unchanged. This sub-sub-TLV MAY occur at most once in a given BIER 368 info sub-TLV. If multiple occurences of this sub-sub-TLV are 369 received in a given BIER info sub-TLV the encapsulating sub-TLV MUST 370 be ignored. 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Type | Length | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 Type: value of 3 indicating BIER sub-domain BSL Conversion 380 Length: 0 382 7. Security Considerations 384 Implementations must assure that malformed TLV and Sub-TLV 385 permutations do not result in errors which cause hard protocol 386 failures. 388 8. Acknowledgements 390 The RFC is aligned with the 391 [I-D.draft-ietf-bier-ospf-bier-extensions-08] draft as far as the 392 protocol mechanisms overlap. 394 Many thanks for comments from (in no particular order) Hannes 395 Gredler, Ijsbrand Wijnands, Peter Psenak and Chris Bowers. 397 9. References 399 9.1. Normative References 401 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 402 dual environments", RFC 1195, DOI 10.17487/RFC1195, 403 December 1990, . 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, 407 DOI 10.17487/RFC2119, March 1997, 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 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 417 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 418 2008, . 420 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 421 DOI 10.17487/RFC5308, October 2008, 422 . 424 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 425 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 426 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 427 March 2016, . 429 9.2. Informative References 431 [I-D.draft-ietf-bier-architecture-08] 432 Wijnands et al., IJ., "Stateless Multicast using Bit Index 433 Explicit Replication Architecture", internet-draft draft- 434 ietf-bier-architecture-08.txt, Sep 2017. 436 [I-D.draft-ietf-bier-mpls-encapsulation-10] 437 Wijnands et al., IJ., "Bit Index Explicit Replication 438 using MPLS encapsulation", internet-draft draft-ietf-bier- 439 mpls-encapsulation-10.txt, Sep 2017. 441 [I-D.draft-ietf-bier-ospf-bier-extensions-08] 442 Psenak et al., P., "OSPF Extension for Bit Index Explicit 443 Replication", internet-draft draft-ietf-bier-ospf-bier- 444 extensions-08.txt, Oct 2017. 446 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 447 Writing an IANA Considerations Section in RFCs", BCP 26, 448 RFC 8126, DOI 10.17487/RFC8126, June 2017, 449 . 451 Authors' Addresses 453 Les Ginsberg (editor) 454 Cisco Systems 455 510 McCarthy Blvd. 456 Milpitas, CA 95035 457 USA 459 Email: ginsberg@cisco.com 461 Tony Przygienda 462 Juniper Networks 464 Email: prz@juniper.net 465 Sam Aldrin 466 Google 467 1600 Amphitheatre Parkway 468 Mountain View, CA 469 USA 471 Email: aldrin.ietf@gmail.com 473 Jeffrey (Zhaohui) Zhang 474 Juniper Networks, Inc. 475 10 Technology Park Drive 476 Westford, MA 01886 477 USA 479 Email: zzhang@juniper.net