idnits 2.17.1 draft-xie-mpls-ldp-bier-extension-01.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 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC5036], [I-D.xie-bier-mvpn-mpls-p2mp], [RFC6388]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 5, 2018) is 2059 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) == Missing Reference: 'PDxx' is mentioned on line 431, but not defined == Missing Reference: '-Dxx' is mentioned on line 421, but not defined == Missing Reference: '--xR' is mentioned on line 422, but not defined == Missing Reference: '--x-' is mentioned on line 423, but not defined == Missing Reference: '-DIx' is mentioned on line 432, but not defined == Missing Reference: '-D-x' is mentioned on line 433, but not defined == Missing Reference: '--Ix' is mentioned on line 428, but not defined == Missing Reference: '---x' is mentioned on line 429, but not defined == Missing Reference: '--IR' is mentioned on line 434, but not defined == Missing Reference: '--I-' is mentioned on line 435, but not defined == Missing Reference: '---R' is mentioned on line 436, but not defined == Missing Reference: '----' is mentioned on line 437, but not defined == Missing Reference: 'XXX-' is mentioned on line 460, but not defined == Missing Reference: 'XXXR' is mentioned on line 462, but not defined == Missing Reference: 'XXXX' is mentioned on line 462, but not defined == Unused Reference: 'I-D.ietf-bier-mvpn' is defined on line 504, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 3988 Summary: 3 errors (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Xie 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track M. Chen 5 Expires: March 9, 2019 R. Li 6 Huawei 7 September 5, 2018 9 Multipoint LDP Extension for P2MP-based BIER 10 draft-xie-mpls-ldp-bier-extension-01 12 Abstract 14 Bit Index Explicit Replication (BIER) is a new architecture that 15 provides optimal multicast forwarding without requiring intermediate 16 routers to maintain any per-flow state by using a multicast-specific 17 BIER header. An extension to the Label Distribution Protocol (LDP) 18 defined in [RFC5036] for the setup of point-to-multipoint (P2MP) is 19 described in [RFC6388] is called mLDP, and is used for multicast- 20 specific tree building. This document describes mLDP extensions to 21 setup a P2MP with BIER information, which is called P2MP based BIER 22 in [I-D.xie-bier-mvpn-mpls-p2mp]. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 9, 2019. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. MLDP P2MP BIER Signalling . . . . . . . . . . . . . . . . . . 4 67 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.3. Signaling the P2MP BIER . . . . . . . . . . . . . . . . . 5 70 3.4. The P2MP BIER LSP Identifier . . . . . . . . . . . . . . 5 71 3.5. BIER TLV . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.6. Make Before Break (MBB) . . . . . . . . . . . . . . . . . 7 73 4. Capability and Error handling . . . . . . . . . . . . . . . . 7 74 4.1. BIER Capability . . . . . . . . . . . . . . . . . . . . . 7 75 4.2. BIER Status . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.3. Check Capability and Use Status for Error Handling . . . 9 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 8.2. Informative References . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 Bit Index Explicit Replication (BIER) is a new architecture that 88 provides optimal multicast forwarding without requiring intermediate 89 routers to maintain any per-flow state by using a multicast-specific 90 BIER header. An extension to the Label Distribution Protocol (LDP) 91 defined in [RFC5036] for the setup of point-to-multipoint (P2MP) is 92 described in [RFC6388] is called mLDP, and is used for multicast- 93 specific tree building. This document describes mLDP extensions to 94 setup a P2MP with BIER information, which is called a P2MP based BIER 95 in [I-D.xie-bier-mvpn-mpls-p2mp] . 97 Related documents that may be of interest include [RFC5561], and 98 [RFC3988]. 100 2. Terminology 102 Readers of this document are assumed to be familiar with the 103 terminology and concepts of the documents listed as Normative 104 References. For convenience, some of the more frequently used terms 105 and new terms list below. 107 o mLDP: Multipoint extensions for LDP. 109 o P2MP LSP: An LSP that has one Ingress LSR and one or more Egress 110 LSRs. 112 o Ingress LSR: An Ingress LSR for a particular LSP is an LSR that 113 can send a data packet along the LSP. MP2MP LSPs can have 114 multiple Ingress LSRs, P2MP LSPs have just one, and that node is 115 often referred to as the "root node". 117 o Egress LSR: An Egress LSR for a particular LSP is an LSR that can 118 remove a data packet from that LSP for further processing. P2P 119 and MP2P LSPs have only a single egress node, but P2MP and MP2MP 120 LSPs can have multiple egress nodes. 122 o Transit LSR: An LSR that has reachability to the root of the MP 123 LSP via a directly connected upstream LSR and one or more directly 124 connected downstream LSRs. 126 o Bud LSR: An LSR that is an egress but also has one or more 127 directly connected downstream LSRs. 129 o Leaf node: A leaf node can be either an Egress or Bud LSR when 130 referred to in the context of a P2MP LSP. 132 o FEC: Forwarding Equivalence Class 134 o P2MP FEC: defined in RFC6388. 136 o F-BM: Forwarding Bit Mask 138 o BSL: Bit String Length, that is 64, 128, 256, etc (per [RFC8279]). 140 3. MLDP P2MP BIER Signalling 142 3.1. Definitions 144 F-BM: Forwarding Bit Mask, An array of Bit, which is defined in 145 [RFC8279]. 147 Peer F-BM: For LSR A and P2MP FEC, this is the F-BM that 148 included in Label Mapping from a downstream LSR for P2MP FEC 149 to A. 151 Downstream F-BM: For LSR A and P2MP FEC, this is the OR'ing 152 result of each of the F-BM included in Label Mapping from downstream 153 LSR for P2MP FEC to A. A use this Downstream F-BM in its 154 Lable Mapping to upstream node for P2MP FEC. In other words, 155 A's Downstream F-BM is A's upstream node's Peer F-BM. 157 3.2. Example 159 Consider LSRs A - F, interconnected as follows: 161 ( A ) ------------ ( B ) ------------ ( C ) ------------ ( D ) 162 (Root) \ \ 1 (0:0001) 163 \ \ 164 ( E ) ( F ) 165 3 (0:0100) 2 (0:0010) 167 Figure 1: P2MP-based BIER Topology 169 Say that the node D has a BFR-id 1, F has a BFR-id 2, and E has a 170 BFR-id 3, and we use a Bit String Length 4 (which is not valid per 171 [RFC8296]) as an example. 173 Consider an P2MP FEC for which A is the Root, and say 174 that D,E,F are all the Leafs of this P2MP FEC. 176 While D send LDP Mapping to C, it includes a F-BM 0001. Say that C 177 got a Peer F-BM 0001, and then C form a Downstream F-BM 0001. 179 While F send LDP Mapping to C, it includes a F-BM 0010. Say that C 180 got a Peer F-BM 0010, and then C form a Downstream F-BM 0011. 182 While C send LDP Mapping to B, it includes a F-BM 0010. Say that B 183 got a Peer F-BM 0011, and then B form a Downstream F-BM 0011. 185 While E send LDP Mapping to B, it includes a F-BM 0100. Say that B 186 got a Peer F-BM 0100, and then B form a Downstream F-BM 0111. 188 While B send LDP Mapping to A, it includes a F-BM 0111. Say that A 189 got a Peer F-BM 0111, and then A form a Downstream F-BM 0111. 191 This memo describes how every nodes in a P2MP tree get Peer F-BM from 192 every downstream LSR, form a Downstream F-BM by OR'ing all it's 193 Downstream Peer F-BM, and send a Mapping to it's upstream node using 194 the Downstream F-BM. 196 3.3. Signaling the P2MP BIER 198 The procedure for signalling the P2MP BIER is performed hop-by-hop by 199 each LSR L along an P2MP LSP for a given P2MP FEC. The steps 200 are as follows: 202 1. First, L computes its Downstream F-BM for P2MP FEC: 204 If L is a leaf for P2MP FEC, L sets the F-BM with it's 205 BFRID's BitPosition to 1. 207 Otherwise (L is not a Leaf), L computes the Downstream F-BM by OR'ing 208 all it's downstream Node's F-BM, as described above. 210 2. For each LDP neighbor of L to which L decides to send a Mapping 211 for FEC F, L attaches an BIER TLV with the F-BM that it computed for 212 this P2MP FEC. 214 3. When a new BIER TLV is received for P2MP FEC from a 215 downstream LSR or the set of downstream LSRs, L returns to step 1. 216 If the newly computed Downstream F-BM is unchanged, L SHOULD NOT 217 advertise new information to its upstream neighbor. Otherwise, L 218 readvertises its Mappings to its upstream neighbor with an updated 219 BIER TLV. 221 This behavior is standard for attributes such as path vector, hop 222 count, and MTU, and the same rules apply, as specified in [RFC5036]. 224 If the Downstream F-BM changes, L MAY readvertise the new F-BM 225 immediately, or hold down the readvertisement for a while. 227 3.4. The P2MP BIER LSP Identifier 229 [RFC6388] defined the P2MP FEC Element, which include a LDP MP Opaque 230 Value Element. It also defined a Generic LSP Identifier as the LDP 231 MP Opaque Value Element, with a TLV of Type 1. This document defined 232 a new type of LDP MP Opaque Value Element, called the P2MP BIER LSP 233 Identifier. 235 The encoding for the P2MP BIER LSP Identifer is as follows: 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Type | Length |ID(High 8bits) | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | ID(Low 24bits) |Reserve|BS Len | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 |Set Identifier | 245 +-+-+-+-+-+-+-+-+ 246 Type: TBD. Need to be less than 255. 247 Length: 6 248 ID: A 32-bit integer, same as RFC6388. 249 BS Len: Bit String Length 250 Set Identifier: as defined in RFC8279. 252 Figure 2: P2MP BIER LSP Identifer 254 3.5. BIER TLV 256 The BIER TLV encodes information on the F-BM for an LSP, from the 257 advertising LSR to the egress(es) over all valid paths. 259 The encoding for the BIER TLV is as follows: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 |1|1| BIER TLV (TBD) | Length | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Reserved |BS Len |Set Identifier | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | F-BM (first 32 bits) ~ 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 ~ ~ 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 ~ F-BM (last 32 bits) | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Type: TBD. 275 Length: Length 276 BSL: Bit String Length 277 Set Identifier: as defined in RFC8279. 278 F-BM: Forwarding Bit Mask 280 Figure 3: BIER TLV 282 3.6. Make Before Break (MBB) 284 The Make Before Break (MBB) mechanism for mLDP P2MP defined in 285 RFC6388 also applies. 287 4. Capability and Error handling 289 The extensions defined in this document utilize the existing LDP 290 error handling defined in [RFC5036]. If an LSR receives an error 291 notification from a peer for a session, it terminates the LDP session 292 by closing the TCP transport connection for the session and 293 discarding all multi-topology label mappings learned via the session. 295 An LSR should respond with an LDP MP Status in LDP Notification 296 Messages when it receives an LDP Label Mapping message with a P2MP 297 FEC element specifying an BIER TLV that is not locally known or not 298 supported. The LSR MUST also discard the entire message before 299 sending the Notification message. 301 4.1. BIER Capability 303 A new optional capability parameter TLV, RMR Capability, is defined. 304 Following is the format of the RMR Capability Parameter: 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 |U|F| BIER Capability (IANA) | Length (= 2) | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 |S| Reserved |P|D|I|R| Rsv | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 BIER Capability TLV Format 314 U: set to 1. Ignore, if not known. 315 F: Set to 0. Do not forward. 316 S: MUST be set to 1 to advertise the BIER TLV. 317 P: The node has BIER P-Capability. 318 D: The node has BIER D-Capability. 319 I: The node Ignore the BIER Header except the Label. 320 R: The node Require a packet without BIER Header except the Label. 322 Figure 4: BIER Capability 324 The BIER Capability TLV MUST be advertised in the LDP Initialization 325 message. If the peer has not advertised the BIER capability, then 326 label messages including a BIER TLV MUST NOT be sent to the peer. 328 If an LSR has not advertised that it is BIER capable, its LDP peers 329 MUST NOT send it messages that include BIER TLV. If an LSR receives 330 a Label Mapping message with an BIER TLV from downstream LSR-D and 331 its upstream LSR-U has not advertised that it is BIER capable, the 332 LSR MUST send an BIER notification immediately to LSR-D. If this 333 happens, an P2MP BIER LSP will not be established, a normal P2MP LSP 334 will not be established either. 336 P-Capability indicate a complete BIER function, which includes 337 P-Capability and D-Capability. If a node support P-Capability, then 338 it support the whole BIER function, which means it support both 339 P-capability and D-capability. 341 D-Capability indicate a subset of BIER function, to Disposition some 342 length of a packet from some offset. For example, from BIER Label 343 and a whole ( BIER Header Length ) , or from the position after BIER 344 Label and a length of ( BIER Header Length - BIER Label Length ) . If 345 a node don't support P-Capability, it may still support D-Capability. 346 If a node don't support D-capability, it must not support 347 P-Capability. 349 If a Node doesn't have P-Capability, then P flag MUST be cleared. 350 Whether the node will be a Branch or BUD or Leaf, the I flag SHOULD 351 be set. 353 if a node doesn't have D-Capability, then P and D flag MUST be 354 cleared. If the node will be a BUD or Leaf then R flag SHOULD be 355 set. if the node will be a Branch then R flag MAY not be set. 357 if a node doesn't have P-Capability but does have D-Capability, then 358 D flag SHOULD be set, but R flag MAY be set or not be set. 360 4.2. BIER Status 362 A new optional LDP MP Status Value Element (RFC6388), BIER Status, is 363 defined. Following is the format of the BIER Status: 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | BIER Type = 1 | Length = 1 | Status Code | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 The BIER Status is a type of the LDP MP Status Value Element 371 LDP MP Status Value Element TLV Type(RFC6388): 372 Type 0: Reserved 373 Type TBD: BIER Status 374 Status Code: 375 1 = BIER TLV not supported 376 2 = Leaf or Bud don't have D-capability, must set R flag 377 3 = Branch or Bud don't have P-capability, must set I flag 378 4 = Node must set R flag when Upstream has R flag 379 5 = Node must clear R flag when any of downstream not have R flag 381 Figure 5: BIER Status TLV 383 4.3. Check Capability and Use Status for Error Handling 385 In order to deploy P2MP BIER on a network with some legacy nodes, 386 which may not support P-capability or D-capability, some Capability 387 flags need to be checked and notification messages may be generated. 389 If all edge nodes support D-capability, but some nodes don't support 390 P-capability and they set a I flag as required, then deployment of 391 P2MP BIER is fine, and a BIER packet can walk from Root to all 392 Leaf(s) without any change except the BIER Label. 394 If an LSR support P-capability, and it's upstream node also support 395 P-capability, and when the LSR receives a Label Mapping message with 396 an BIER TLV and R flag set from downstream LSR-D, the LSR will accept 397 such Label Mapping message. If receives a Label Mapping wiht an BIER 398 TLV and R flag cleaned another downstream LSR-D', the LSR will accept 399 too. 401 If an LSR receives a Label Mapping message with an BIER TLV from 402 downstream LSR-D with a R flag, and its upstream LSR-U has no 403 P-capability, the LSR MUST send an BIER notification immediately to 404 LSR-D. If this happens, an P2MP BIER LSP will not be established, a 405 normal P2MP LSP will not be established either. 407 When an LSR receives a Label Mapping message, it need to do some 408 check before process and build P2MP BIER forwarding table. Such 409 check includes: 411 1) Check if the node's P-capability and D-capability conflict with 412 it's I flag and R flag. 414 The following table list the whole check matrix. 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | NODE's | NODE's | Check | | 418 | Role | PDIR-flag | Result | Rule | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Leaf | [PDxx] | OK | (*) Comment 1 | 421 | Leaf | [-Dxx] | OK | | 422 | Leaf | [--xR] | OK | Rule 1 | 423 | Leaf | [--x-] | ERR | Rule 1 | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Branch | [PDxx] | OK | (*) Comment 1 | 426 | Branch | [-DIx] | OK | Rule 2 | 427 | Branch | [-D-x] | ERR | Rule 2 | 428 | Branch | [--Ix] | OK | (*) Comment 2 | 429 | Branch | [---x] | ERR | Rule 2 | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | BUD | [PDxx] | OK | (*) Comment 1 | 432 | BUD | [-DIx] | OK | Rule 2 | 433 | BUD | [-D-x] | ERR | Rule 2 | 434 | BUD | [--IR] | OK | | 435 | BUD | [--I-] | ERR | Rule 1 | 436 | BUD | [---R] | ERR | Rule 2 | 437 | BUD | [----] | ERR | Rule 1 & 2 | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 (*) Comment 1: In some cases, set a R flag is useful 440 (*) Comment 2: In some cases, Clear R flag on a Branch node is useful 441 Rule 1: Leaf don't have D-capability, must set R flag 442 Rule 2: Branch don't have P-capability, must set I flag 444 Figure 6: BIER Self Check Matrix 446 2) Check the node's R flag, the node's upstream R flag, the node's 447 downstream R flag. 449 The following table list the whole check martrix about the R flag of 450 node, the upstream node, the downstream nodes. 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | NODE's | Upstream |Downstream | Check | | 454 | PDIR-flag | PDIR-flag | PDIR-flag | Result | Rule | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | [XXX-] | [XXX-] | Any | Success | | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | [XXX-] | [XXXR] | Any | Fail | Rule A | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | [XXXR] | [XXXX] | [XXX-] | Fail | Rule B | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | [XXXR] | [XXXX] | [XXXR] | Success | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Rule A: Node must set R flag when Upstream has R flag 465 Rule B: Node must clear R flag when any of downstream not have R flag 467 Figure 7: BIER upstream and downstream check 469 When the above two checks fail, a notification message with a reason 470 code is sent to the downstream node which send the Label Mapping 471 message. 473 5. IANA Considerations 475 Allocation is expected from IANA for a new type codepoints for "P2MP 476 BIER LSP Identifier" from the "LDP MP Opaque Value Element basic 477 type" registry of the "Label Distribution Protocol (LDP) Parameters" 478 registry. 480 Allocation is expected from IANA for a new type codepoints for "BIER 481 TLV" from the "TLV Type Name Space" registry of the "Label 482 Distribution Protocol (LDP) Parameters" registry. 484 Allocation is expected from IANA for a new type codepoints for "BIER 485 capability TLV" from the "TLV Type Name Space" registry of the "Label 486 Distribution Protocol (LDP) Parameters" registry. 488 Allocation is expected from IANA for a new type codepoints for "BIER 489 Status" from the "LDP MP Status Value Element type" registry of the 490 "Label Distribution Protocol (LDP) Parameters" registry. 492 6. Security Considerations 494 TBD 496 7. Acknowledgements 498 TBD 500 8. References 502 8.1. Normative References 504 [I-D.ietf-bier-mvpn] 505 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 506 Przygienda, "Multicast VPN Using BIER", draft-ietf-bier- 507 mvpn-11 (work in progress), March 2018. 509 [I-D.xie-bier-mvpn-mpls-p2mp] 510 Xie, J., McBride, M., Chen, M., and L. Geng, "Multicast 511 VPN Using MPLS P2MP and BIER", draft-xie-bier-mvpn-mpls- 512 p2mp-02 (work in progress), July 2018. 514 [RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit 515 Signalling Extensions for the Label Distribution 516 Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005, 517 . 519 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 520 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 521 October 2007, . 523 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. 524 Le Roux, "LDP Capabilities", RFC 5561, 525 DOI 10.17487/RFC5561, July 2009, 526 . 528 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 529 Thomas, "Label Distribution Protocol Extensions for Point- 530 to-Multipoint and Multipoint-to-Multipoint Label Switched 531 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 532 . 534 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 535 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 536 Explicit Replication (BIER)", RFC 8279, 537 DOI 10.17487/RFC8279, November 2017, 538 . 540 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 541 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 542 for Bit Index Explicit Replication (BIER) in MPLS and Non- 543 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 544 2018, . 546 8.2. Informative References 548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels", BCP 14, RFC 2119, 550 DOI 10.17487/RFC2119, March 1997, 551 . 553 Authors' Addresses 555 Jingrong Xie 556 Huawei Technologies 557 Q15 Huawei Campus, No.156 Beiqing Rd. 558 Beijing 100095 559 China 561 Email: xiejingrong@huawei.com 563 Mach Chen 564 Huawei 566 Email: mach.chen@huawei.com 568 Robin Li 569 Huawei 571 Email: lizhenbin@huawei.com