idnits 2.17.00 (12 Aug 2021) /tmp/idnits33559/draft-prz-bier-bfrid-assignment-00.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 == Line 596 has weird spacing: '...main-id subdo...' == Line 625 has weird spacing: '... values reser...' -- The document date (March 09, 2015) is 2623 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) == Unused Reference: 'RFC4971' is defined on line 677, but no explicit reference was found in the text == Unused Reference: 'RFC5120' is defined on line 681, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'RFC5308' is defined on line 688, but no explicit reference was found in the text == Unused Reference: 'RFC6513' is defined on line 691, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-wijnands-bier-architecture-04 ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Przygienda 3 Internet-Draft J. Tantsura 4 Intended status: Standards Track Ericsson 5 Expires: September 10, 2015 March 09, 2015 7 Automatic Assignment of BIER BFR-ids in ISIS 8 draft-prz-bier-bfrid-assignment-00 10 Abstract 12 Specification of an ISIS extension to support auto-election of BFR 13 IDs in BIER using ISIS. 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in RFC 2119 [RFC2119] . 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 10, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. Election Algorithm . . . . . . . . . . . . . . . . . . . 5 60 4.2. D-BFR Procedures . . . . . . . . . . . . . . . . . . . . 7 61 4.2.1. Assignment of BMPs to BFERs in . . . . . . . . . 7 62 4.3. BD-BFR Procedures . . . . . . . . . . . . . . . . . . . . 8 63 4.4. BFER Procedures . . . . . . . . . . . . . . . . . . . . . 8 64 5. Special Considerations . . . . . . . . . . . . . . . . . . . 8 65 5.1. BD-BFER to D-BFER Transition . . . . . . . . . . . . . . 8 66 6. Election FSM for BFR . . . . . . . . . . . . . . . . . . 9 67 6.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.2. Events . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 7. FSM Figure/Events for BFER: TBD . . . . . . . . . . . . . . . 11 70 8. Backwards Compatiblity . . . . . . . . . . . . . . . . . . . 11 71 9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 11 72 9.1. BIER-PE: BIER Protocol Election sub-sub-TLV . . . . . . . 11 73 9.2. Reuse of the Reserved Bits in BIER Info sub-TLV . . . . . 12 74 9.3. BIER-PE-BMP: BIER PE BMP Assignments TLV . . . . . . . . 13 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 77 12. Normative References . . . . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 80 1. Introduction 82 Bit Index Explicit Replication (BIER) 83 [I-D.draft-wijnands-bier-architecture-04] defines an architecture 84 where all intended multicast receivers are encoded as bitmask in the 85 Multicast packet header within different encapsulations such as 86 [I-D.draft-wijnands-mpls-bier-encapsulation-02]. A router that 87 receives such a packet will forward the packet based on the Bit 88 Position in the packet header towards the receiver(s), following a 89 precomputed tree for each of the bits in the packet. Each receiver 90 is represented by a unique bit in the bitmask corresponding to its 91 BFR-id. BFR-ids are sub-domain specific. 93 Once the number of receivers becomes large (i.e. many sets are 94 present) or receivers choose to participate in many independent sub- 95 domains, assignment of a unique BIER bit to a node is a non-trivial 96 problem that can benefit highly from an automated solution. The 97 usual trade-offs are either a centralized (server) approach or a 98 distributed approach which (from experience with other protocols such 99 as DHCP or OSPF), provide at the cost of additional protocol 100 complexity higher availability. 102 This document presents necessary, optional extensions to the 103 currently deployed ISIS for IP [RFC1195] protocol to support 104 automatic election of BFR-ids by means of a distributed protocol. 105 This document defines new TLVs to be advertised by every router 106 participating in BIER signaling and supporting such an election. In 107 case some nodes are statically configured with a BFR-id, the protocol 108 can detect misconfiguration, i.e. overlapping bit assignments or 109 otherwise respects statically assigned BFR ids. 111 This extension operates seamlessly in a backwards compatible fashion 112 with BIER procedures for ISIS as defined in 113 [I-D.draft-przygienda-bier-isis-ranges-02]. Only BFRs implementing 114 this extensions benefit from automatic assignment. 116 2. Terminology 118 Some of the terminology specified in 119 [I-D.draft-wijnands-bier-architecture-04] is replicated here and 120 extended by necessary definitions: 122 BIER: Bit Index Explicit Replication (The overall architecture of 123 forwarding multicast using a Bit Position). 125 BIER-OL: BIER Overlay Signaling. (The method for the BFIR to learn 126 about BFER's). 128 BFR: Bit Forwarding Router (A router that participates in Bit Index 129 Multipoint Forwarding). A BFR is identified by a unique BFR- 130 prefix in a BIER domain. 132 BFIR: Bit Forwarding Ingress Router (The ingress border router that 133 inserts the BM into the packet). 135 BFER: Bit Forwarding Egress Router. A router that participates in 136 Bit Index Forwarding as leaf. Each BFER must be a BFR. Each BFER 137 must have a valid BFR-id assigned. 139 BFT: Bit Forwarding Tree used to reach all BFERs in a domain. 141 BIFT: Bit Index Forwarding Table. 143 BMS: Bit Mask Set. Set containing bit positions of all BFER 144 participating in a set. 146 BMP: Bit Mask Position, a given bit in a BMS. 148 Invalid BMP: Unassigned Bit Mask Position, consisting of all 0s. 150 IGP signalled BIER domain: A BIER underlay where the BIER 151 synchronization information is carried in IGP. Observe that a 152 multi-topology is NOT a separate BIER domain in IGP. 154 BIER sub-domain: A further distinction within a BIER domain 155 identified by its unique sub-domain identifier. A BIER sub-domain 156 can support multiple BitString Lengths. 158 BFR-id: An optional, unique identifier for a BFR within a BIER sub- 159 domain. 161 Invalid BFR-id: Unassigned BFR-id, consisting of all 0s. 163 3. IANA Considerations 165 This document adds the following new sub-sub-TLVs to the registry of 166 sub-TLVs for BIER Info sub-TLV. 168 BIER Protocol Election sub-sub-TLV Value: TBD (suggested - to be 169 assigned by IANA) 171 This document adds the following new TLV to the registery of ISIS 172 TLVs. 174 BIER PE BMP Assignments TLV Value: TBD (suggested - to be assigned 175 by IANA) 177 4. Procedures 179 The following sections present BIER IGP protocol procedures for the 180 auto-election and maintainance of unique BIER BFR-ids across 181 subdomains. Compared to purely administrative assignment of the 182 bitmask use of those procedures largely facilitates deployment of 183 BIER in large setups. The election and bit assignment procedures 184 described in the according sections indicate how the BFRs participate 185 in an election mechanism that allows them to 187 o use a dynamically chosen Designated and Backup Designated router 188 for coordination and distribution of necessary state across all 189 participants in the set across the network in a robust fashion 191 o allocate the necessary BMP in a sub-domain for each BFER 192 o automatically or administratively partition the elections for 193 different sub-domains across the set of BFRs for maximum 194 reliability 196 o discover administrative misconfiguration of BFERs 198 4.1. Election Algorithm 200 After a sub-domain 201 [I-D.draft-przygienda-bier-isis-ranges-02] is enabled, the according 202 election procedures for D-BFR and Backup D-BFR are performed based 203 upon the set of available BIER-PE sub-sub-TLVs. Given the fact that 204 SD is uniquely tied to its MT per today's architecture and MLs are of 205 no further importance to the introduced procedures, a sub-domain will 206 be abbreviated without loss of generality as . 208 The election is indebted to and largely modeled (to the point of 209 quoting parts of it verbatim) after the DR OSPF Election procedure in 210 OSPF [RFC2328] which has proven to work exceedingly well over many 211 years in the field. 213 This section describes the algorithm used for calculating a network's 214 Designated BFR and Backup Designated BFR and procedures that allow 215 those to allocate bit mask bits to a participating BFER in a sub- 216 domain SD which we designate as BFER. The election runs per SD 217 the router is participating in. The initial time a router runs the 218 election algorithm, the D-BFR and BD-BFR are initialized to 219 0.0.0.0 or equivalent empty router ID. This indicates the lack of 220 both a Designated BFR and a Backup Designated BFR. 222 The D-BFR election algorithm proceeds as follows: 224 o Call the router doing the calculation Router X. A router can 225 participate in multiple elections for other BMS and multi- 226 topologies at varying priorities. 228 o The list of BFRs participating in whose according BIER- 229 PEs have been received by Router X and are connected (i.e. 230 reachable via SPF computation) in standard topology MUST be 231 examined. 233 o Router X itself MUST be also considered to be on the list. 235 o Discard all routers from the list that are ineligible to become 236 D-BFR. (Routers having Router Priority of 0 for MUST NOT 237 be eligible to become D-BFR.) 239 The following steps MUST then be executed, considering only those 240 routers that remain on the list: 242 1. Note the current values for D-BFR and Backup D-BFR. This 243 is used later for comparison purposes. 245 2. Calculate the new Backup D-BFR as follows. 247 * Only those routers on the list that have not declared 248 themselves to be D-BFR MUST be eligible to become Backup 249 D-BFR. 251 * If one or more of these routers have declared themselves 252 Backup D-BFR (i.e., they are currently listing themselves 253 as Backup D-BFR, but not as D-BFR, in their according 254 BIER-PE packets) the one having highest Router Priority for 255 MUST be declared to be Backup D-BFR. 257 * In case of a tie, the one having the highest Router ID XOR'ed 258 with SD (assuming big endian order, both values right-aligned 259 and all bits of the shorter value filled up with zeroes to the 260 length of the longer value) MUST be chosen. 262 * If no routers have declared themselves Backup D-BFR, the 263 router having highest Router Priority for MUST be chosen, 264 (again excluding those routers who have declared themselves 265 D-BFR), and again use the Router ID XOR'ed with SD to 266 break ties. 268 3. Calculate the new D-BFR for the network as follows. If one 269 or more of the routers have declared themselves D-BFR (i.e., 270 they are currently listing themselves as D-BFR in their BIER- 271 PE advertisements) the one having highest Router Priority for 272 is declared to be D-BFR. In case of a tie, the one 273 having the highest Router ID XOR'ed with SD is chosen. If no 274 routers have declared themselves D-BFR, assign the D-BFR 275 to be the same as the newly elected BD-BFR. 277 4. If Router X is now newly the D-BFR or newly the BD- 278 BFR, or is now no longer the D-BFR or no longer the BD- 279 BFR, repeat steps 2 and 3, and then proceed to step 5. For 280 example, if Router X is now the D-BFR, when step 2 is 281 repeated X will no longer be eligible for BD-BFR 282 election. Among other things, this will ensure that no router 283 will declare itself both BD-BFR and D-BFR. 285 5. As a result of these calculations, the router itself may now be 286 D-BFR or BD-BFR. See Section 4.2 and Section 4.3 for the 287 additional duties this would entail. 289 6. If the above calculations have caused the identity of either the 290 D-BFR or BD-BFR to change, all routers must re-evaluate 291 whether they have been elected D-BFR or BD-BFR and 292 initiate according procedures. In case the new D-BFR or BD- 293 BFR is not advertising according bitmask assignment and they 294 are needed, they initiate according procedures in Section 4.2.1. 296 The reason behind the election algorithm's complexity is the desire 297 for an orderly transition from BD-BFR to D-BFR, when the 298 current D-BFR fails. This orderly transition is ensured through 299 the introduction of hysteresis: no new BD-BFR can be chosen until 300 the old Backup accepts its new D-BFR responsibilities. 302 The above procedure may elect the same router to be both D-BFR 303 and BD-BFR, although that router will never be the calculating 304 router (Router X) itself. The elected D-BFR may not be the 305 router having the highest Router Priority for , nor will the BD- 306 BFR necessarily have the second highest Router Priority. If 307 Router X is not itself eligible to become D-BFR, it is 308 possible that neither a BD-BFR nor a D-BFR will be selected 309 in the above procedure. Note also that if Router X is the only 310 router that is eligible to become D-BFR, it will select itself as 311 D-BFR and there will be no BD-BFR for the network. 313 4.2. D-BFR Procedures 315 A router that assumes D-BFR role for a given combination invokes 316 additional set of procedures as synchronization and election point 317 for all the BFRs in . 319 4.2.1. Assignment of BMPs to BFERs in 321 Each BFER includes a strongly abbreviated DHCP-like FSM to obtain 322 from the D-BFR its BMP or to advertise an administrative 323 preference of its BMP. 325 The procedure is initiated by a BFER announcing in BIER Info sub- 326 TLV for its assigned bit (or request for BMP assignment). The 327 D-BFR initiates then a set of procedures to assign BMPs to such 328 BFER in the or announces collisions. 330 Observe that BFERs can request (or announce) the bits even before a 331 BDR has been chosen so the election and assignment are largely 332 orthogonal sets of procedures. 334 4.3. BD-BFR Procedures 336 A router that is elected BD-BFR MUST mirror in its advertisements 337 the exact state of the D-BFR and on each received advertisement 338 maintains its internal states to use as starting point in all 339 D-BFR procedures in case it looses connectivity (i.e. it cannot 340 compute SPF reachability to the D-BFR in standard topology) to the 341 D-BFR. 343 4.4. BFER Procedures 345 A BFER in controls its BMP in the set by providing values in its 346 BIER Info sub-TLV for and signalling towards B-DR using A and R 347 bits per Section 9.2. If it advertises the BFR-id without A or R bit 348 set it indicates a fixed value it has chosen administratively. 350 It may request the assignment of a BMP by setting the R bit. The 351 prefered BFR-id is signalled by providing a BFR-id value. The D-BFR 352 MUST try to keep the preferred setting value when choosing BMP for 353 the BFER. All other BFRs MUST NOT use the BFR-id value when the R 354 bit is set. In case of routers not understanding this extensions, 355 the behavior is enforced by the means of the C bit. 357 Once the BFER has been assigned a value from D-BFR and is willing to 358 accept it, it MUST copy the value into the BFR-id field in the BIER- 359 PE-BMPs it receives and set the A bit while clearing the R bit. 361 On the other side, the D-BFR for advertises the BMP assignments 362 by the means of advertising BIER-PE-BMP for . 364 5. Special Considerations 366 5.1. BD-BFER to D-BFER Transition 368 In the normal case a router will assume its role as D-BFR 369 promoting itself from BD-BFR with its own set of procedures. 370 Based on those it will hold the state of the abdicating D-BFR and 371 it MUST use this state as initial state for the D-BFR procedures it 372 initiates per Section 4.2 . This should warranty a seamless fall-over 373 without changes in the assignments of bits for BFERs for the 374 according which SHOULD take preference over all other 375 considerations. Observe that the implication is that a configured 376 administrative preference MUST NOT be used unless changed or set 377 explicitly again. The FSMs visualize this behavior more explicitly. 379 6. Election FSM for BFR 381 +------+ 382 | ==== | E1 = PE Expired OR 383 | Init | PI Expired New Admin 384 | ==== | Pref 385 +-+----+ +--+ 386 | | | 387 | Joined SD +--------++ | 388 | Rcvd First PE for SD Lost DR | ======= <-+ 389 | +--------------+ Passive | 390 +-v----+ | | ======= | 391 | ==== | | +^--------+ 392 | Wait |Timer +--------v-+ Lost | 393 | ==== +------------> ======== +-------------+ 394 +------+ | Election | 395 +---------+ ======== +--------+ 396 | Won BDR +^-------^-+ Won DR | 397 | | | | 398 | | |New DR | 399 +----v+ | |Seen +v---+ 400 | === +---------+ +---------+ == | 401 | BDR | New BDR | DR | 402 +--> === | Lost DR +---+ == | 403 | ++----+ | +^---+ 404 | | E1 | | 405 +---+ Diff R Flag | | 406 New DR PE Diff A Flag | | 407 New Admin Pref +-------v+ | 408 | BMP +---+ 409 | Assign | 410 +--------+ 412 The full set of procedures can be described as a finite state machine 413 per run within each participating BFR with the following events 414 and transitions 416 6.1. States 418 Init Initial State of the Machine 420 Wait State waiting for routers to update their PEs for on 421 startup 423 Election State that runs the election procedures and generates 424 according events that progress it into another state immediately 426 Passive State entered when lost both DR and BDR in election. 428 Elected DR 430 Elected BDR 432 BMP Assign State in which the assignment of bits happens upons 433 requests from BFERs. 435 6.2. Events 437 Timer Initial timer waiting for s of other routers before election 438 is triggered. 440 Signalling/Rcvd First PE First PE for has been received or 441 signalling enabled for the set S on BFR. 443 Lost DR Current D-BFR cannot be reached anymore via SPF 444 computation in standard topology. 446 Lost Lost election for D-BFR and BD-BFR. 448 Won BDR Won election for BD-BFR. 450 Won DR Won election for D-BFR. 452 New BDR A new BD-BFR has been elected by the D-BFR. 454 New DR PE New BIER-PE Instance from D-BFR. 456 New Admin Pref Changed Administrative preference. 458 Diff R Flag R flag has been announced by a BFR which was not present 459 before. In case of a new R flag, an assignment should be 460 attempted. In case of R flag being deleted 462 if the A flag is set, the validity of the copied BFR-id with 463 the assignment is checked 465 if the A flag is clear, the value is assumed non-negotiable and 466 re-assignments may be necessary 468 Diff A Flag A flag has been withdrawn or announced. If A flag was 469 present before and 471 R flag is clear, the value is assumed non-negotiable and re- 472 assignments may be necessary. 474 R flag is set, a new assignment is requested. 476 If A flag was not present before and 478 R flag is clear, the validity of the copied BFR-id with the 479 assignment is checked 481 R flag is set, the client MUST be declared faulty and 482 disregarded. 484 To Be Completed TBD 486 7. FSM Figure/Events for BFER: TBD 488 8. Backwards Compatiblity 490 The procedures prescribed guarantee a complete backwards compatiblity 491 to [I-D.draft-przygienda-bier-isis-ranges-02]. During the assignment 492 procedure the according values are hidden from BFRs lacking this 493 extension by the means of the C bit. Once assigned, they become 494 visible. On the other hand, BFR-id values chosen by the BFRs without 495 election extensions are respected in assignment. 497 9. Packet Formats 499 Some of the new information is carried within the the existing BIER 500 Info sub-TLV per [I-D.draft-przygienda-bier-isis-ranges-02] and some 501 presents a new ISIS TLV. 503 9.1. BIER-PE: BIER Protocol Election sub-sub-TLV 505 This sub-sub-TLV is included in the BIER Info sub-TLV of the 506 according sub-domain as specified by 507 [I-D.draft-przygienda-bier-isis-ranges-02]. It MUST be included in 508 the BIER Info sub-TLV only once, otherwise the first instance is 509 used. 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Type | Length | D-BFR Priority| Reserved | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | D-BFR ID | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | BD-BFR ID | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Type: TBD1. 522 Length: 1 octet. 524 Priority Priority at which this router is set to become D-BFR for 525 the . 527 D-BFR ID ID of the router chosen as D-BFR. If the router elected 528 itself as D-BFR it MUST set it to its own ID. 530 BD-BFR ID ID of the router chosen as BD-BFR. If the router 531 elected itself as BD-BFR it MUST set it to its own ID. 533 9.2. Reuse of the Reserved Bits in BIER Info sub-TLV 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Type | Length | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 |Ver|C|0 0 0 A R| subdomain-id | BFR-id | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Version Version of the protocol. It remains at 0. 545 C The compatiblity bit. It is set according to following rules: 547 If the R bit is set, C is set to 0, i.e. the TLV is not 548 compatible with version 0 of the BIER information. This will 549 prevent routers not implementing this specification from 550 looking at this advertisement. 552 If the R bit is clear, C is set to 1. In case the BFR-id has 553 been obtained without an error by requesting it from a D-BFR, 554 the value is copied into BFR-id of this sub-TLV, otherwise it 555 is set to invalid BFR-id. 557 R Request Bit. When set, this bit advertises that the BFER is 558 willing to accept another BMP than the one administratively 559 desired from D-BFR. The value of BMP is then determined by 560 the according element in BIER-PE-BMP of the D-BFR. 562 A When this bit is set, the BFER advertises that the value indicated 563 in the BFR-id has been copied from the assignment provided by 564 D-BFR. If clear and BFR-id is set, the value is administratively 565 assigned and is non-negotiable. 567 BFR-id If set and R bit is clear, it indicates the BFR-id the BFR is 568 occupying to the D-BFR. If the R bit is set, it indicates the 569 desired BFR-id to be assigned or no preference. 571 9.3. BIER-PE-BMP: BIER PE BMP Assignments TLV 573 This TLV is advertised only for the for which the router has 574 been elected to be D-BDR or BD-BDR. It can repeat multiple 575 times. 577 0 1 2 3 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Type | Length | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 |R R R R| MT-ID | subdomain-id |# of Assigments| 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 <---+ 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 586 | AF |E|Stats| Assigned BFR-id | Prefix Length | # Bit 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mask 588 | Address Prefix (variable) | Assgn 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 590 <---+ 592 Type TBD 594 MT-ID Multi topology for which the assignments are provided 596 subdomain-id subdomain-id for which the assignments are provided 598 AF identifies address family of the prefix for which the assignment 599 is provided. Values TBD 601 Prefix Length Prefix length of the prefix for which the assignment 602 is provided. 604 Prefix Prefix containing the identifying prefix from TLVs 235, 237, 605 135 or 236 for which the assignment is provided. 607 Assigned BFR-id Bit Mask Position assigned by D-BFR, set to invalid 608 BMP on an error status. 2 octets. 610 E Bit indicating assignment error, i.e. the BFER does NOT have a 611 valid assignment. 613 Status Status of the assignment, 3 bits. 615 0 Assignment is OK and can be used (based on either 616 administratively requested BMP or chosen by D-BFR for the 617 requesting BFER). E-bit MUST be clear. 619 1 error: Unresolvable collision with other administratively set 620 values, Bit Mask Position cannot be used. E-bit MUST be set. 622 2 error: Out of Bit Mask Positions for the Topology and Set, Bit 623 Mask Position cannot be used. E-bit MUST be set. 625 all other values reserved, MUST NOT be used. 627 The assignments SHOULD be sorted on BFER-ID. Assignments MUST NOT 628 repeat when the TLV is advertised multiple times and a router 629 discovering such condition MUST issue an adequate warning. When 630 multiple assignments for the same BFR are found, the first one in 631 first TLV MUST be used and all others disregarded. 633 The assignments MUST NOT repeat any BIER Info sub-TLVs that have the 634 R and A bit cleared, e.g. purely administrative assignments. A 635 router discovering such condition MUST issue an adequate warning and 636 disregard such assignments. 638 The assignments MUST repeat all assigned BIER Info sub-TLVs (that 639 have A bit set). When such assignment is not advertised anymore, the 640 according BFER MUST interpret that as loss as assignment, i.e. start 641 with R bit again or set the BFR-id to invalid BFR-id. 643 10. Security Considerations 645 Implementations must assure that malformed TLV and sub-TLV 646 permutations do not result in errors which cause hard protocol 647 failures. 649 11. Acknowledgements 651 TBD. 653 12. Normative References 655 [I-D.draft-przygienda-bier-isis-ranges-02] 656 Przygienda et al., A., "BIER support via ISIS", internet- 657 draft draft-przygienda-bier-isis-ranges-02.txt, Jan 2015. 659 [I-D.draft-wijnands-bier-architecture-04] 660 Wijnands, IJ., "Stateless Multicast using Bit Index 661 Explicit Replication Architecture", internet-draft draft- 662 wijnands-bier-architecture-04.txt, February 2015. 664 [I-D.draft-wijnands-mpls-bier-encapsulation-02] 665 Wijnands et al., IJ., "Bit Index Explicit Replication 666 using MPLS encapsulation", internet-draft draft-wijnands- 667 mpls-bier-encapsulation-02.txt, December 2014. 669 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 670 dual environments", RFC 1195, December 1990. 672 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 673 Requirement Levels", BCP 14, RFC 2119, March 1997. 675 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 677 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 678 System to Intermediate System (IS-IS) Extensions for 679 Advertising Router Information", RFC 4971, July 2007. 681 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 682 Topology (MT) Routing in Intermediate System to 683 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 685 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 686 Engineering", RFC 5305, October 2008. 688 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 689 2008. 691 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 692 VPNs", RFC 6513, February 2012. 694 Authors' Addresses 696 Tony Przygienda 697 Ericsson 698 300 Holger Way 699 San Jose, CA 95134 700 USA 702 Email: antoni.przygienda@ericsson.com 704 Jeff Tantsura 705 Ericsson 706 300 Holger Way 707 San Jose, CA 95134 708 USA 710 Email: jeff.tantsura@ericsson.com