idnits 2.17.1 draft-xie-pim-bier-extension-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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC6807]), 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 (March 5, 2018) is 2237 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: 'PIM-REG' is mentioned on line 310, but not defined == Unused Reference: 'I-D.ietf-bier-mvpn' is defined on line 366, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-bier-mvpn-10 == Outdated reference: A later version (-02) exists of draft-xie-bier-mvpn-mpls-p2mp-00 ** Downref: Normative reference to an Experimental RFC: RFC 6807 Summary: 3 errors (**), 0 flaws (~~), 5 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 Y. Liu 4 Intended status: Standards Track M. McBride 5 Expires: September 6, 2018 Huawei Technologies 6 March 5, 2018 8 PIM Extensions for P2MP-based BIER 9 draft-xie-pim-bier-extension-00 11 Abstract 13 Bit Index Explicit Replication (BIER) is a new architecture that 14 provides optimal multicast forwarding without requiring intermediate 15 routers to maintain any per-flow state by using a multicast-specific 16 BIER header. PIM is a well-known multicast-specific routing protocol 17 which is widely deployed either in a VRF context or in a Non-VRF 18 context. This document describes PIM extensions to signal a P2MP 19 Tree with BIER information, which is called a P2MP based BIER in 20 [I.D.xie-bier-mvpn-mpls-p2mp]. PIM is required to alloc Label to 21 build a P2MP tree hop-by-hop, and build a P2MP based BIER forwarding 22 table further. This requires a BitMask being carried as a PIM Join 23 Attribute by downstream node to upstream node hop-by-hop, and the 24 behavior is like precedures as specified in [RFC6807]. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 6, 2018. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. PIM Signaling a P2MP BIER tree . . . . . . . . . . . . . . . 3 69 3.1. Example of signaling the P2MP-BIER . . . . . . . . . . . 3 70 3.2. BIER-Supported Hello Option . . . . . . . . . . . . . . . 5 71 3.3. New BIER F-BM Join Attribute Format . . . . . . . . . . . 6 72 4. How to Use BIER F-BM Join Attribute . . . . . . . . . . . . . 7 73 5. Capability and Error Handling . . . . . . . . . . . . . . . . 8 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 79 9.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 Bit Index Explicit Replication (BIER) is a new architecture that 85 provides optimal multicast forwarding without requiring intermediate 86 routers to maintain any per-flow state by using a multicast-specific 87 BIER header. PIM defined in [RFC7761] is a well-known multicast- 88 specific routing protocol which is widely deployed either in a VRF 89 context or in a Non-VRF context. This document describes PIM 90 extensions to signal a P2MP Tree with BIER information, which is 91 called a P2MP based BIER in [I-D.xie-bier-mvpn-mpls-p2mp], in which 92 PIM is required to alloc Label to build a P2MP tree hop-by-hop, and 93 build a P2MP based BIER forwarding table further. This requires a 94 BitMask being carried as a PIM Join Attribute by downstream node to 95 upstream node hop-by-hop, and the behavior is like precedures as 96 specified in [RFC6807]. 98 This document defines support for MPLS encapsulation as specified in 99 [RFC8296]. Support for other encapsulation types is outside the 100 scope of this document. The use of multiple encapsulation types is 101 outside the scope of this document. 103 2. Terminology 105 Readers of this document are assumed to be familiar with the 106 terminology and concepts of the documents listed as Normative 107 References. For convenience, some of the more frequently used terms 108 and new terms list below. 110 o BFR: BIER Forwarding Router 112 o BFR-ID: BIER Forwarding Router IDentify. 114 o P2MP: Point to Multi-point 116 o P2MP based BIER: BIER using P2MP as topology 118 o F-BM: Forwarding Bit Mask 120 o BSL: Bit String Length, that is 64, 128, 256, etc (per [RFC8279]). 122 3. PIM Signaling a P2MP BIER tree 124 3.1. Example of signaling the P2MP-BIER 126 Consider LSRs A - F, interconnected as follows: 128 ( A ) ------------ ( B ) ------------ ( C ) ------------ ( D ) 129 (Root) \ \ 1 (0:0001) 130 \ \ 131 ( E ) ( F ) 132 3 (0:0100) 2 (0:0010) 134 Figure 1: P2MP-based BIER Topology 136 Say that the node D has a BFR-id 1, F has a BFR-id 2, and E has a 137 BFR-id 3, and we use a Bit String Length 4 (which is not valid per 138 [RFC8296]) as an example. 140 Consider a target PIM tree identified by , for 141 which A is the Root, and say that D,E,F are all the Leafs of this PIM 142 tree. 144 When D join the PIM tree, it alloc a Label, and bring this label with 145 a F-BM of 0001 in a PIM Join attribute, and send it to the upstream 146 node C. 148 When F join the PIM tree, it alloc a Label, and bring this label with 149 a F-BM of 0010 in a PIM Join attribute, and send it to the upstream 150 node C. 152 When E join the PIM tree, it alloc a Label, and bring this label with 153 a F-BM of 0100 in a PIM Join attribute, and send it to the upstream 154 node B. 156 When C get the PIM join messages from D and F, then C will establish 157 a PIM state (S,G) and one or many downstream states, C also establish 158 a PIM upstream state and send PIM Join to its upstream neighbor B, 159 with a new allocated Label and a F-BM of 0011. 161 When B get the PIM join messages from E and C, then B will establish 162 a PIM state (S,G) and one or many downstreams, B also establish a PIM 163 upstream state and send PIM Join to it's upstream neighbor A, with a 164 new allocated Label and a F-BM of 0111. 166 When A get the PIM join message from B, A will establish a PIM state 167 (S,G) and the downstream(s). 169 Each node of the PIM tree will establish a routing state of PIM 170 (S,G), and a forwarding state of P2MP based BIER. Here we list the 171 forwarding state of P2MP based BIER on every node. 173 A: 175 NHLFE (TreeID, OutInterface, OutLabel, 176 F-BM=0111) 178 B: 180 ILM(inLabel, action, 181 flag=CheckBS|Branch, BSL) 183 NHLFE (TreeID, OutInterface, OutLabel, 184 F-BM=0011) 186 NHLFE (TreeID, OutInterface, OutLabel, 187 F-BM=0100) 189 C: 191 ILM(inLabel, action, 192 flag=CheckBS|Branch, BSL) 194 NHLFE (TreeID, OutInterface, OutLabel, 195 F-BM=0001) 197 NHLFE (TreeID, OutInterface, OutLabel, 198 F-BM=0100) 200 E: 202 ILM(inLabel, action, 203 flag=CheckBS|Leaf, BSL) 205 LEAF(TreeID, F-BM=0100, Flag=PopBIERincluding) 207 D: 209 ILM(inLabel, action, 210 flag=CheckBS|Leaf, BSL) 212 LEAF(TreeID, F-BM=0001, Flag=PopBIERincluding) 214 F: 216 ILM(inLabel, action, 217 flag=CheckBS|Leaf, BSL) 219 LEAF(TreeID, F-BM=0010, Flag=PopBIERincluding) 221 3.2. BIER-Supported Hello Option 223 A PIM router indicates that it supports the mechanism specified in 224 this document by including the BIER-Signal-Supported Hello option in 225 its PIM Hello message. Note that it also needs to include the Join 226 Attribute Hello option as specified in [RFC5384]. The format of the 227 BIER-Signal-Supported Hello option is defined to be: 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | OptionType | OptionLength | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 |P|D|I|R| Reserved | Reserved | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 P: The node has BIER P-Capability. 237 D: The node has BIER D-Capability. 238 I: The node Ignore the BIER Header except the Label. 239 R: The node Require a packet without BIER Header except the Label. 241 Figure 2: BIER-Supported Hello Option 243 OptionType = TBD, OptionLength = 4. 245 P-Capability indicate a complete BIER function, which includes 246 P-Capability and D-Capability. If a node support P-Capability, then 247 it support the whole BIER function, which means it support both 248 P-capability and D-capability. 250 D-Capability indicate a subset of BIER function, to Disposit BIER 251 Header of a packet including or excluding the BIER Label. If a node 252 doesn't support P-Capability, it may still support D-Capability. If 253 a node don't support D-capability, it is supposed not to support 254 P-Capability. 256 If a Node doesn't have P-Capability, then P flag MUST be cleared. 257 Whether the node will be a Branch or BUD or Leaf, the I flag SHOULD 258 be set. 260 If a node doesn't have D-Capability, then P and D flag MUST be 261 cleared. If the node will be a BUD or Leaf then R flag SHOULD be 262 set. if the node will be a Branch then R flag MAY not be set. 264 If a node doesn't have P-Capability but does have D-Capability, then 265 D flag SHOULD be set, but R flag MAY be set or not be set. 267 3.3. New BIER F-BM Join Attribute Format 269 When a PIM router supports this mechanism and has determined from a 270 received Hello that the neighbor supports this mechanism, and also 271 that all the neighbors on the interface support the use of join 272 attributes, it will send Join/Prune messages that MAY include a BIER 273 F-BM Join Attribute. The mechanism to process a PIM Join Attribute 274 is described in [RFC5384]. The format of the new attribute is 275 specified in the following. 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 |F|E| Attr_Type | Length |Reserve|BS Len |Set Identifier | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | F-BM (first 32 bits) ~ 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 ~ ~ 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 ~ F-BM (last 32 bits) | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Figure 3: BIER F-BM Join Attribute 291 F bit: 0 (Non-Transitive Attribute). 293 E bit: As specified by [RFC5384]. 295 Attr_Type: TBD. 297 Length: The minimum length is 10, that is a 2 octets BSL and a 298 minimum of 8 octets ( 64 bits ). 300 BS Len: Bit String Length, that is the Length of F-BM 302 Set Identifier: As defined in [RFC8279]. 304 F-BM: As defined in [RFC8279]. 306 4. How to Use BIER F-BM Join Attribute 308 A router supporting this mechanism MUST, unless administratively 309 disabled, include the PIM Join Attribute option in its PIM Hellos. 310 See [RFC5384] and "PIM-Hello Options" on [PIM-REG] for details. 312 It is RECOMMENDED that implementations allow for administrative 313 control of whether to make use of this mechanism. Implementations 314 MAY also allow further control of what information to store and send 315 upstream, by configuring whether the node require a packet without 316 BIER header. 318 It is important to note that when a node's downstream F-BM OR'ing 319 result changed, it SHOULD trigger a new Join message with an updated 320 BIER F-BM Join Attribute. 322 When a router removes a link from an oif-list, it needs to be able to 323 reevaluate the BIER F-BM that it will advertise upstream. This 324 happens when an oif-list entry is timed out or a Prune is received. 326 It is RECOMMENDED that the Join Attribute defined in this document be 327 used only for entries in the join-list part of the Join/Prune 328 message. If the attribute is used in the prune-list, an 329 implementation MUST ignore it and process the Prune as if the 330 attribute were not present. 332 It is also RECOMMENDED that join suppression be disabled on a LAN 333 when BIER F-BM is used. 335 It is RECOMMENDED that, when triggered Join/Prune messages are sent 336 by a downstream router, the BIER F-BM information not be included in 337 the message. This way, when convergence is important, avoiding the 338 processing time to build an BIER F-BM record in a downstream router 339 and processing time to parse the message in the upstream router will 340 help reduce convergence time. If an upstream router receives a Join/ 341 Prune message with no BIER F-BM data, it SHOULD NOT interpret the 342 message as a trigger to clear or reset the BIER F-BM data it has 343 cached. 345 5. Capability and Error Handling 347 TBD. 349 6. IANA Considerations 351 Allocation is expected from IANA for codepoints from the "PIM-Hello 352 Options" registry and the "PIM Join Attribute Types" registry. 354 7. Security Considerations 356 TBD 358 8. Acknowledgements 360 TBD 362 9. References 364 9.1. Normative References 366 [I-D.ietf-bier-mvpn] 367 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 368 Przygienda, "Multicast VPN Using BIER", draft-ietf-bier- 369 mvpn-10 (work in progress), February 2018. 371 [I-D.xie-bier-mvpn-mpls-p2mp] 372 Xie, J., "Multicast VPN Using MPLS P2MP and BIER", draft- 373 xie-bier-mvpn-mpls-p2mp-00 (work in progress), October 374 2017. 376 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 377 Independent Multicast (PIM) Join Attribute Format", 378 RFC 5384, DOI 10.17487/RFC5384, November 2008, 379 . 381 [RFC6807] Farinacci, D., Shepherd, G., Venaas, S., and Y. Cai, 382 "Population Count Extensions to Protocol Independent 383 Multicast (PIM)", RFC 6807, DOI 10.17487/RFC6807, December 384 2012, . 386 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 387 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 388 Multicast - Sparse Mode (PIM-SM): Protocol Specification 389 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 390 2016, . 392 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 393 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 394 Explicit Replication (BIER)", RFC 8279, 395 DOI 10.17487/RFC8279, November 2017, 396 . 398 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 399 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 400 for Bit Index Explicit Replication (BIER) in MPLS and Non- 401 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 402 2018, . 404 9.2. Informative References 406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 407 Requirement Levels", BCP 14, RFC 2119, 408 DOI 10.17487/RFC2119, March 1997, 409 . 411 Authors' Addresses 412 Jingrong Xie 413 Huawei Technologies 414 Q15 Huawei Campus, No.156 Beiqing Rd. 415 Beijing 100095 416 China 418 Email: xiejingrong@huawei.com 420 Yisong Liu 421 Huawei Technologies 423 Email: liuyisong@huawei.com 425 Mike McBride 426 Huawei Technologies 428 Email: mmcbride7@gmail.com