idnits 2.17.1 draft-zhang-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 : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-bier-architecture]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 306: '...ntinue allocating BFR-ids, it MUST NOT...' RFC 2119 keyword, line 413: '... set, the client MUST be declared faul...' RFC 2119 keyword, line 421: '... is set to 0, it MUST NOT announce its...' RFC 2119 keyword, line 443: '... specified by [I-D.ietf-bier-ospf-bier-extensions]. It MUST be...' RFC 2119 keyword, line 473: '...self as D-BFR it MUST set it to its ow...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 21, 2015) is 3050 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: 'I-D.ietf-bier-mpls-encapsulation' is defined on line 616, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 629, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-02 == Outdated reference: A later version (-11) exists of draft-ietf-bier-isis-extensions-01 == Outdated reference: A later version (-12) exists of draft-ietf-bier-mpls-encapsulation-02 == Outdated reference: A later version (-18) exists of draft-ietf-bier-ospf-bier-extensions-01 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER WG Z. Zhang 3 Internet-Draft C. Wang 4 Intended status: Standards Track ZTE Corporation 5 Expires: June 23, 2016 December 21, 2015 7 Automatic Assignment of BIER BFR-ids in OSPF 8 draft-zhang-bier-bfrid-assignment-00 10 Abstract 12 [I-D.ietf-bier-architecture] has introduced a new method to forward 13 multicast flow, without explicit multicast states storing in every 14 node along the multicast paths. This document introduces a method to 15 allocate BFR-id automatically through OSPF extension. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 23, 2016. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5 54 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 4.1. D-BFR Election Algorithm . . . . . . . . . . . . . . . . . 6 56 4.2. D-BFR Procedures . . . . . . . . . . . . . . . . . . . . . 8 57 4.2.1. Assignment of BMPs to BFRs . . . . . . . . . . . . . . 8 58 4.3. BD-BFR Procedures . . . . . . . . . . . . . . . . . . . . 8 59 4.4. BFER Procedures . . . . . . . . . . . . . . . . . . . . . 8 60 5. Special Considerations . . . . . . . . . . . . . . . . . . . . 9 61 5.1. BD-BFR to D-BFR Transition . . . . . . . . . . . . . . . . 9 62 5.2. Election FSM for BFR . . . . . . . . . . . . . . . . . . . 9 63 5.2.1. States . . . . . . . . . . . . . . . . . . . . . . . . 10 64 5.2.2. Events . . . . . . . . . . . . . . . . . . . . . . . . 11 65 5.2.3. Rules . . . . . . . . . . . . . . . . . . . . . . . . 12 66 5.2.4. Warning and Logging . . . . . . . . . . . . . . . . . 12 67 6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 13 68 6.1. BIER-PE BIER Protocol Election Sub-sub-TLV . . . . . . . . 13 69 6.2. Reuse of the Reserved Bits in BIER Info sub-TLV . . . . . 13 70 6.3. BIER-PE-BMP: BIER PE BMP Assignments TLV . . . . . . . . . 14 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 72 8. Normative References . . . . . . . . . . . . . . . . . . . . . 18 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 75 1. Introduction 77 [I-D.ietf-bier-architecture] defines a new efficient forwarding way 78 for multicast flow. The crucial object in this method is BFR-id for 79 every BFERs. All nodes in the BIER domain learn the BFR-ids of 80 BFERs, and forward the packet according to the BIER header that are 81 composed by the BFR-ids. 83 Although the BFR-id can be acquired by central controllers or 84 statically, it will be more convenient if there is a way to allocate 85 the BFR-id automatically. 87 This document introduces a new method to allocate BFR-id for BFERs in 88 BIER domain. And this document also defines the format of OSPF 89 extension for BFR-id auto assignment. 91 This document gets benefit from the DR election algorithm that is 92 defined in RFC2328. And the main idea of this document is the same 93 as that is defined in "draft-prz-bier-bfrid-assignment". The only 94 difference between the two documents is the protocol format. 96 2. Terminology 98 Some of the terminology specified in [I-D.ietf-bier-architecture] is 99 replicated here and extended by necessary definitions: 101 BIER: Bit Index Explicit Replication (The overall architecture of 102 forwarding multicast using a Bit Position). 104 BIER-OL: BIER Overlay Signaling. (The method for the BFIR to learn 105 about BFER's). 107 BFR: Bit Forwarding Router (A router that participates in Bit Index 108 Multipoint Forwarding). A BFR is identified by a unique BFR-prefix 109 in a BIER domain. 111 BFIR: Bit Forwarding Ingress Router (The ingress border router that 112 inserts the BM into the packet). 114 BFER: Bit Forwarding Egress Router. A router that participates in 115 Bit Index Forwarding as leaf. Each BFER must be a BFR. Each BFER 116 must have a valid BFR-id assigned. 118 BFT: Bit Forwarding Tree used to reach all BFERs in a domain. 120 BIFT: Bit Index Forwarding Table. 122 BMS: Bit Mask Set. Set containing bit positions of all BFER 123 participating in a set. 125 BMP: Bit Mask Position, a given bit in a BMS. 127 Invalid BMP: Unassigned Bit Mask Position, consisting of all 0s. 129 IGP signaled BIER domain: A BIER underlay where the BIER 130 synchronization information is carried in IGP. Observe that a multi- 131 topology is NOT a separate BIER domain in IGP. 133 BIER sub-domain: A further distinction within a BIER domain 134 identified by its unique sub-domain identifier. A BIER sub-domain 135 can support multiple BitString Lengths. 137 BFR-id: An optional, unique identifier for a BFR within a BIER sub- 138 domain. 140 Invalid BFR-id: Unassigned BFR-id, consisting of all 0s. 142 3. IANA considerations 144 This document adds the following new sub-sub-TLVs to the registry of 145 sub-TLVs for BIER Info sub-TLV. 147 BIER Protocol Election sub-sub-TLV Value: TBD (suggested - to be 148 assigned by IANA) 150 This document adds the following new TLV to the registery of OSPF 151 TLVs. 153 BIER PE BMP Assignments TLV Value: TBD (suggested - to be assigned by 154 IANA) 156 4. Procedures 158 At first, all the BIER nodes collect the information of D-BFR 159 candidates and BD-BFR candidates through the advertisements of BIER 160 protocol election sub-sub-TLVs. All the BFRs flood the sub-sub-TLVs 161 per sub-domain or per BMS to all other nodes. 163 The D-BFR election algorithm is most like the DR elect function in 164 OSPF protocol. And the FSM is also like the function in OSPF 165 protocol. The algorithm described below is most from RFC2328. 167 OSPF floods the DR/BDR information through OSPF hello packets. BIER 168 nodes flood the BIER protocol election sub-sub-TLVs along with BIER 169 information sub-TLV. 171 ALL the BIER nodes elect the D-BFR and BD-BFR through the Designated 172 Router BFR function. And the D-BFR assigns BFR-ids according to the 173 received BIER information sub-TLV which request to allocate a BFR-id. 174 After D-BFR assigns all the BFR-ids and floods the assignment to all 175 the BIER nodes, BD-BFR mirrors the assignment as its base assignment. 176 If there are some collisions existing, the BFRs that are not 177 allocated BFR-id negotiate the BFR-id assignment procedure with D-BFR 178 again. 180 4.1. D-BFR Election Algorithm 182 The Designated Router BFR election algorithm proceeds as follows: 184 o Call the router doing the calculation Router X. The list of 185 neighbors attached to the network and having established 186 bidirectional communication with Router X is examined. 188 o The state of BFRs that may be D-BFR or BD-BFR should be examined 189 by SPF computation. 191 o Router X itself is also considered to be on the list. 193 o Discard all routers from the list that are ineligible to become 194 DR-BDR. (Routers having Router Priority of 0 are ineligible to 195 become D-BFR.) The following steps are then executed, considering 196 only those routers that remain on the list: 198 (1) Note the current values for the network's D-BFR and BD-BFR. 199 This is used later for comparison purposes. 201 (2) Calculate the new BD-BFR for the network as follows. Only 202 those routers on the list that have not declared themselves to be 203 D-BFR are eligible to become BD-BFR. If one or more of these routers 204 have declared themselves BD-BFR (i.e., they are currently listing 205 themselves as BD-BFR, but not as D-BFR, in their sub-sub-TLVs) the 206 one having highest Router Priority is declared to be BD-BFR. In case 207 of a tie, the one having the highest Router ID is chosen. If no 208 routers have declared themselves BD-BFR, choose the router having 209 highest Router Priority, (again excluding those routers who have 210 declared themselves D-BFR), and again use the Router ID to break 211 ties. 213 (3) Calculate the new Designated Router for the network as 214 follows. If one or more of the routers have declared themselves 215 D-BFR (i.e., they are currently listing themselves as D-BFR in their 216 BIER PE sub-sub-TLV) the one having highest Router Priority is 217 declared to be D-BFR. In case of a tie, the one having the highest 218 Router ID is chosen. If no routers have declared themselves D-BFR, 219 assign the D-BFR to be the same as the newly elected BD-BFR. 221 (4) If Router X is now newly the D-BFR or newly the BD-BFR, or 222 is now no longer the D-BFR or no longer the BD-BFR, repeat steps 2 223 and 3, and then proceed to step 5. For example, if Router X is now 224 the DR-BDR, when step 2 is repeated X will no longer be eligible for 225 BD-BFR election. Among other things, this will ensure that no router 226 will declare itself both BD-BFR and D-BFR. 228 (5) As a result of these calculations, the router itself may now 229 be D-BFR or BD-BFR. See Section4.2 and Section4.3 for the additional 230 duties this would entail. 232 (6) If the above calculations have caused the identity of either 233 the D-BFR or BD-BFR to change, all the routers must re-evaluate 234 whether they have been selected D-BFR or BD-BFR and initiate 235 according procedures. In case the new D-BFR is not advertising 236 according bitmask assignment and they are needed, they initiate 237 according procedures in Section4.2. 239 The reason behind the election algorithm's complexity is the desire 240 for an orderly transition from BD-BFR to D-BFR, when the current 241 D-BFR fails. This orderly transition is ensured through the 242 introduction of hysteresis: no new BD-BFR can be chosen until the old 243 Backup accepts its new D-BFR responsibilities. 245 The above procedure may elect the same router to be both D-BFR and 246 BD-BFR, although that router will never be the calculating router 247 (Router X) itself. The elected D-BFR may not be the router having 248 the highest Router Priority, nor will the BD-BFR necessarily have the 249 second highest Router Priority. If Router X is not itself eligible 250 to become D-BFR, it is possible that neither a BD-BFR nor a D-BFR 251 will be selected in the above procedure. Note also that if Router X 252 is the only attached router that is eligible to become D-BFR, it will 253 select itself as D-BFR and there will be no BD-BFR for the network. 255 4.2. D-BFR Procedures 257 Similar to the D-BFR and BD-BFR election procedure, the assignment of 258 D-BFR is also base on a sub-domian or a BMS. 260 4.2.1. Assignment of BMPs to BFRs 262 The procedure is initiated by a BFER announcing R bit in BIER Info 263 sub-TLV. The D-BFR assigns BMPs to such BFER or announces 264 collisions. 266 Observe that BFERs can request (or announce) the R bits even before a 267 D-BFR has been chosen so the election and assignment are largely 268 orthogonal sets of procedures. 270 The BFR-ids in one sub-domain or a BMS should be assigned one by one 271 as far as possible. 273 4.3. BD-BFR Procedures 275 BD-BFR mirrors the BIER PE BMP Assignments TLV from the advertisement 276 of D-BFR. And BD-BFR uses the existing assignment as the initial 277 input of probably allocation. 279 4.4. BFER Procedures 281 BFER sends the BIER protocol Election sub-sub-TLV at first. If the 282 BFER wants itself to be a D-BFR or BD-BFR, it should adjust the D-BFR 283 priority in advance. After BFER receives the BIER protocol Election 284 sub-sub-TLVs from other BIER nodes, it elects the D-BFR and BD-BFR 285 according to the function defined in Section4.1. 287 If the BFER finds that itself is the D-BFR, it should do the 288 assignment of D-BFR. If the BFER finds that itself is the BD-BFR, it 289 mirrors the assignment advertisement of D-BFR. If the BFER is 290 neither D-BFR nor BD-BFR, it should only care the interaction between 291 itself and D-BFR. 293 BFER which need be allocated BFR-id sends the request in BIER info 294 sub-TLV. If one certain BFR-id is pre-configured, BFER sends this 295 BFR-id to D-BFR along with BIER info sub-TLV. And D-BFR takes the 296 certain BFR-id into account preferential. If BFER can't receive the 297 satisfied result from the PE BMP assignments TLV, it should log the 298 error and negotiate with D-BFR again. 300 5. Special Considerations 302 5.1. BD-BFR to D-BFR Transition 304 BD-BFR stores the assignments of D-BFR advertisement. And BD-BFR 305 treats this existing allocation as initial state. When BD-BFR should 306 take charge of D-BFR and continue allocating BFR-ids, it MUST NOT 307 change existing allocation, in other words, BD-BFR should allocate 308 new BFR-ids to the new nodes of the network. 310 5.2. Election FSM for BFR 312 This section describes the finite state machine that runs on every 313 BFR. 315 +------+ 316 | ==== | E1 = PE Expired OR 317 | Init | PI Expired New Admin 318 | ==== | Pref 319 +-+----+ +--+ 320 | | | 321 | Joined SD Lost DR/ +--------++ | 322 | Rcvd First PE for SD New Admin Pref | ======= <-+ 323 | +-------------------+ Passive | 324 +-v----+ | | ======= | 325 | ==== | | +^--------+ 326 | Wait |Timer +--------v-+ Lost | 327 | ==== +------------> ======== +-----------------+ 328 +------+ | Election | 329 +---------+ ======== +--------+ 330 | Won BDR +^-------^-+ Won DR | 331 | | | | 332 | | |New DR | 333 +----v+ | |Seen +v---+ 334 | === +---------+ +---------+ == | 335 | BDR | New BDR | DR | 336 +--> === | Lost DR +---+ == | 337 | ++----+ | +^---+ 338 | | E1 | | 339 +---+ Diff R Flag | | 340 New DR PE Diff A Flag | | 341 New Admin Pref +-------v+ | 342 | BMP +---+ 343 | Assign | 344 +--------+ 346 Figure 1: D-BFR/BD-BFR election FSM 348 5.2.1. States 350 Init: Initial State of the Machine 352 Wait: State waiting for routers to update their PEs for the sub- 353 domian on startup 355 Election: State that runs the election procedures and generates 356 according events that progress it into another state immediately 358 Passive: State entered when lost both DR and BDR in election. 360 Elected D-BFR 362 Elected BD-BFR 363 BMP Assign: State in which the assignment of bits happens upon 364 requests from BFERs. 366 5.2.2. Events 368 Timer: Initial timer waiting for s of other routers before election 369 is triggered. 371 Signalling/Rcvd First PE: First PE for has been received or signaling 372 enabled for the set S on BFR. 374 Lost DR: Current D-BFR cannot be reached anymore via SPF computation 375 in standard topology. 377 Lost: Lost election for D-BFR and BD-BFR. 379 Won BDR: Won election for BD-BFR. 381 Won DR: Won election for D-BFR. 383 New BDR: A new BD-BFR has been elected by the D-BFR. 385 New DR PE: New BIER-PE Instance from D-BFR. 387 New Admin Pref: Changed Administrative preference. And it triggers 388 the election of BD-BFR. 390 Diff R Flag: R flag has been announced by a BFR which was not present 391 before. In case of a new R flag, an assignment should be attempted. 392 In case of R flag being deleted 394 if the A flag is set, the validity of the copied BFR-id with the 395 assignment is checked 397 if the A flag is clear, the value is assumed non-negotiable and 398 re-assignments may be necessary 400 Diff A Flag: A flag has been withdrawn or announced. 402 If A flag was present before and 404 R flag is clear, the value is assumed non-negotiable and re- 405 assignments may be necessary. 407 R flag is set, a new assignment is requested. 409 If A flag was not present before and 410 R flag is clear, the validity of the copied BFR-id with the 411 assignment is checked 413 R flag is set, the client MUST be declared faulty and 414 disregarded. 416 5.2.3. Rules 418 When a new BFR originates its BIER protocol election advertisement, 419 and it is one candidate to be D-BFR or BD-BFR, it should announce 420 itself to be BD-BFR instead of D-BFR. If the administrative priority 421 is set to 0, it MUST NOT announce itself to be D-BFR or BD-BFR. 423 5.2.4. Warning and Logging 425 Election failure If there is no candidate for D-BFR and BD-BFR after 426 election timer expired, D-BFR and BD-BFR can't be elected, it should 427 trigger a warning or an error log. 429 D-BFR reachability After a D-BFR is elected, if the D-BFR is 430 unreachable, it should trigger a warning or an error log. 432 Flag error If the C bit, R bit and A bit are used incorrect, it 433 should trigger a warning or an error log. 435 6. Packet Formats 437 The BIER information is advertised in a sub-TLV, and this information 438 is associated with the BFR-prefix, this defination is described in 439 [I-D.ietf-bier-ospf-bier-extensions] . 441 A new sub-sub-TLV that is defined for BIER DR election algorithm is 442 included in the BIER Info sub-TLV of the according sub-domain as 443 specified by [I-D.ietf-bier-ospf-bier-extensions]. It MUST be 444 included in the BIER Info sub-TLV only once, otherwise the first 445 instance is used. As the [I-D.ietf-bier-architecture] said, the 446 middle nodes that will not be BFER do not need the BFR-id. But in 447 some situations, one of the middle node will be used to be treated as 448 D-BFR to allocate BFR-ids, the middle node should also send the sub- 449 sub-TLV with the BIER info sub-TLV to indicate that it should be 450 treated as one of the candidate of D-BFR. 452 6.1. BIER-PE BIER Protocol Election Sub-sub-TLV 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Type | Length | D-BFR Priority| Reserved | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | D-BFR ID | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | BD-BFR ID | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Figure 2 BIER Protocol Election sub-sub-TLV 465 o Type: TBD. 467 o Length: 1 octet. 469 o Priority: Priority at which this router is set to become D-BFR for 470 the sub-domain. 472 o D-BFR ID: ID of the router chosen as D-BFR. If the router elected 473 itself as D-BFR it MUST set it to its own ID. 475 o BD-BFR ID: ID of the router chosen as BD-BFR. If the router 476 elected itself as BD-BFR it MUST set it to its own ID. 478 6.2. Reuse of the Reserved Bits in BIER Info sub-TLV 480 The format listed here may seem more like the format that is defined 481 in [I-D.ietf-bier-isis-extensions]than that is defined in 482 [I-D.ietf-bier-ospf-bier-extensions], because the 484 [I-D.ietf-bier-isis-extensions] has been discusssed more sufficient, 485 and the format of BIER info sub-TLV will be uniform later between 486 ISIS and OSPF. 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Type | Length | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 |Ver|C|0 0 0 A R| subdomain-id | BFR-id | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 Figure 3 Reuse of the Reserved Bits in BIER Info sub-TLV 497 Version: Version of the protocol. It remains at 0. 499 C: The compatiblity bit. It is set according to following rules: 501 If the R bit is set, C is set to 0, i.e. the TLV is not 502 compatible with version 0 of the BIER information. This will prevent 503 routers not implementing this specification from looking at this 504 advertisement. 506 If the R bit is clear, C is set to 1. In case the BFR-id has 507 been obtained without an error by requesting it from a D-BFR, the 508 value is copied into BFR-id of this sub-TLV, otherwise it is set to 509 invalid BFR-id. 511 R: Request Bit. When set, this bit advertises that the BFER is 512 willing to accept another BMP than the one administratively desired 513 from D-BFR. The value of BMP is then determined by the according 514 element in BIER-PE-BMP of the D-BFR. 516 A: When this bit is set, the BFER advertises that the value indicated 517 in the BFR-id has been copied from the assignment provided by D-BFR. 518 If clear and BFR-id is set, the value is administratively assigned 519 and is non-negotiable. 521 BFR-id: If set and R bit is clear, it indicates the BFR-id the BFR is 522 occupying to the D-BFR. If the R bit is set, it indicates the 523 desired BFR-id to be assigned or no preference. 525 6.3. BIER-PE-BMP: BIER PE BMP Assignments TLV 527 This TLV is advertised only for a sub-domain or a BMS for which the 528 router has been elected to be D-BDR or BD-BDR. It can repeat 529 multiple times. 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Type | Length | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 |R R R R| BMS ID | subdomain-id |# of Assigments| 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 <---+ 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 540 | AF |E|Stats| Assigned BFR-id | Prefix Length | # Bit 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mask 542 | Address Prefix (variable) | Assgn 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 544 <---+ 546 Figure 4 BIER PE BMP Assignments TLV 548 Type: TBD 550 BMS ID: BMS ID for which the assignments are provided 552 subdomain-id: subdomain-id for which the assignments are provided 554 AF: identifies address family of the prefix for which the assignment 555 is provided. It includes IPv4 and IPv6. Values TBD 557 Prefix Length: Prefix length of the prefix for which the assignment 558 is provided. 560 Prefix: The BFR-prefix of BIER nodes. 562 Assigned BFR-id: Bit Mask Position assigned by D-BFR, set to invalid 563 BMP on an error status. 2 octets. 565 E: Bit indicating assignment error, i.e. the BFER does NOT have a 566 valid assignment. 568 Status: Status of the assignment, 3 bits. 570 0 Assignment is OK and can be used (based on either 571 administratively requested BMP or chosen by D-BFR for the requesting 572 BFER). E-bit MUST be clear. 574 1 error: Unresolvable collision with other administratively set 575 values, Bit Mask Position cannot be used. E-bit MUST be set. 577 2 error: Out of Bit Mask Positions for the Topology and Set, Bit 578 Mask Position cannot be used. E-bit MUST be set. 580 all other values reserved, MUST NOT be used. 582 The assignments SHOULD be sorted on BFER-ID. Assignments MUST NOT 583 repeat when the TLV is advertised multiple times and a router 584 discovering such condition MUST issue an adequate warning. When 585 multiple assignments for the same BFR are found, the first one in 586 first TLV MUST be used and all others disregarded. 588 The assignments MUST NOT repeat any BIER Info sub-TLVs that have the 589 R and A bit cleared, e.g. purely administrative assignments. A 590 router discovering such condition MUST issue an adequate warning and 591 disregard such assignments. 593 The assignments MUST repeat all assigned BIER Info sub-TLVs (that 594 have A bit set). When such assignment is not advertised anymore, the 595 according BFER MUST interpret that as loss as assignment, i.e. start 596 with R bit again or set the BFR-id to invalid BFR-id. 598 7. Security Considerations 600 For general BIER Security Considerations. 602 8. Normative References 604 [I-D.ietf-bier-architecture] 605 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 606 S. Aldrin, "Multicast using Bit Index Explicit 607 Replication", draft-ietf-bier-architecture-02 (work in 608 progress), July 2015. 610 [I-D.ietf-bier-isis-extensions] 611 Ginsberg, L., Przygienda, T., Aldrin, S., and J. Zhang, 612 "BIER support via ISIS", 613 draft-ietf-bier-isis-extensions-01 (work in progress), 614 October 2015. 616 [I-D.ietf-bier-mpls-encapsulation] 617 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and 618 S. Aldrin, "Encapsulation for Bit Index Explicit 619 Replication in MPLS Networks", 620 draft-ietf-bier-mpls-encapsulation-02 (work in progress), 621 August 2015. 623 [I-D.ietf-bier-ospf-bier-extensions] 624 Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 625 Przygienda, T., Zhang, J., and S. Aldrin, "OSPF Extensions 626 For BIER", draft-ietf-bier-ospf-bier-extensions-01 (work 627 in progress), October 2015. 629 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/ 630 RFC2328, April 1998, 631 . 633 Authors' Addresses 635 Zheng(Sandy) Zhang 636 ZTE Corporation 637 No. 50 Software Ave, Yuhuatai Distinct 638 Nanjing, 639 China 641 Phone: 642 Email: zhang.zheng@zte.com.cn 644 Cui(Linda) Wang 645 ZTE Corporation 646 No. 50 Software Ave, Yuhuatai Distinct 647 Nanjing, 648 China 650 Phone: 651 Email: wang.cui1@zte.com.cn