idnits 2.17.00 (12 Aug 2021) /tmp/idnits30971/draft-chen-idr-bier-te-path-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (19 December 2021) is 146 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) -- Looks like a reference, but probably isn't: '1' on line 145 -- Looks like a reference, but probably isn't: '65535' on line 145 == Unused Reference: 'RFC5226' is defined on line 588, but no explicit reference was found in the text == Unused Reference: 'RFC5575' is defined on line 593, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-11 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Chen 3 Internet-Draft M. McBride 4 Intended status: Standards Track Futurewei 5 Expires: 22 June 2022 R. Chen 6 ZTE Corporation 7 G. Mishra 8 Verizon Inc. 9 A. Wang 10 China Telecom 11 Y. Liu 12 China Mobile 13 Y. Fan 14 Casa Systems 15 B. Khasanov 16 Yandex LLC 17 L. Liu 18 Fujitsu 19 X. Liu 20 Volta Networks 21 19 December 2021 23 BGP for BIER-TE Path 24 draft-chen-idr-bier-te-path-03 26 Abstract 28 This document describes extensions to Border Gateway Protocol (BGP) 29 for distributing a Bit Index Explicit Replication Traffic/Tree 30 Engineering (BIER-TE) path. A new Tunnel Type for BIER-TE path is 31 defined to encode the information about a BIER-TE path. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in [RFC2119] [RFC8174] 38 when, and only when, they appear in all capitals, as shown here. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on 22 June 2022. 57 Copyright Notice 59 Copyright (c) 2021 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 64 license-info) in effect on the date of publication of this document. 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. Code Components 67 extracted from this document must include Revised BSD License text as 68 described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Revised BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Overview of BGP for BIER-TE Path . . . . . . . . . . . . . . 4 76 2.1. Example BIER-TE Topology with BGP . . . . . . . . . . . . 4 77 2.2. Distributing Path to Ingress . . . . . . . . . . . . . . 5 78 3. Extensions to BGP . . . . . . . . . . . . . . . . . . . . . . 6 79 3.1. New SAFI and NLRI . . . . . . . . . . . . . . . . . . . . 6 80 3.2. New Tunnel Type for BIER-TE . . . . . . . . . . . . . . . 7 81 3.3. Path BitPositions Sub-TLV . . . . . . . . . . . . . . . . 8 82 3.4. Path Name Sub-TLV . . . . . . . . . . . . . . . . . . . . 9 83 3.5. Traffic Description Sub-TLVs . . . . . . . . . . . . . . 10 84 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 85 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 87 6.1. Existing Registry: SAFI Parameters . . . . . . . . . . . 11 88 6.2. Existing Registry: BGP TEA Tunnel Types . . . . . . . . . 12 89 6.3. Existing Registry: BGP TEA sub-TLVs . . . . . . . . . . . 12 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 92 7.2. Informative References . . . . . . . . . . . . . . . . . 13 93 Appendix A. Extensions to PMSI_TUNNEL Attribute . . . . . . . . 13 94 A.1. New Tunnel Type for BIER-TE . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 97 1. Introduction 99 [I-D.ietf-bier-te-arch] introduces Bit Index Explicit Replication 100 (BIER) Tree Engineering (BIER-TE). It is an architecture for per- 101 packet stateless explicit point to multipoint (P2MP) multicast path/ 102 tree, which is called BIER-TE path, and based on the BIER 103 architecture defined in [RFC8279]. 105 A Bit-Forwarding Router (BFR) in a BIER-TE domain has a BIER-TE Bit 106 Index Forwarding Table (BIFT). A BIER-TE BIFT on a BFR comprises a 107 forwarding entry for a BitPosition (BP) assigned to each of the 108 adjacencies of the BFR. If the BP represents a forward connected 109 adjacency, the forwarding entry for the BP forwards the multicast 110 packet with the BP to the directly connected BFR neighbor of the 111 adjacency. If the BP represents a BFER (i.e., egress node) or say a 112 local decap adjacency, the forwarding entry for the BP decapsulates 113 the multicast packet with the BP and passes a copy of the payload of 114 the packet to the packet's NextProto within the BFR. 116 A Bit-Forwarding Ingress Router (BFIR) in a BIER-TE domain receives 117 the information or instructions about which multicast flows/packets 118 are mapped to which BIER-TE paths that are represented by 119 BitPositions or say BitStrings. After receiving the information or 120 instructions, the ingress node/router encapsulates the multicast 121 packets with the BitPositions for the corresponding BIER-TE paths, 122 replicates and forwards the packets with the BitPositions along the 123 BIER-TE paths. 125 This document proposes some procedures and extensions to BGP for 126 distributing a BIER-TE path to the Bit-Forwarding Ingress Router 127 (BFIR) of the path. It specifies a way of encoding the information 128 about a BIER-TE path in a BGP UPDATE message, which can be 129 distributed to the BFIR of the path. 131 1.1. Terminologies 133 The following terminologies are used in this document. 135 BIER: Bit Index Explicit Replication. 137 BIER-TE: BIER Tree Engineering. 139 BFR: Bit-Forwarding Router. 141 BFIR: Bit-Forwarding Ingress Router. 143 BFER: Bit-Forwarding Egress Router. 145 BFR-id: BFR Identifier. It is a number in the range [1,65535]. 147 BFR-NBR: BFR Neighbor. 149 BFR-prefix: An IP address (either IPv4 or IPv6) of a BFR. 151 BIRT: Bit Index Routing Table. It is a table that maps from the 152 BFR-id (in a particular sub-domain) of a BFER to the BFR-prefix 153 of that BFER, and to the BFR-NBR on the path to that BFER. 155 BIFT: Bit Index Forwarding Table. 157 P-tunnel: A multicast tunnel through the network of one or more SPs. 159 PMSI: Provider Multicast Service Interface. PMSI is an abstraction 160 that represents a multicast service for carrying packets. A 161 PMSI is instantiated via one or more P-tunnels. 163 I-PMSI A-D Route: Inclusive PMSI Auto-Discovery route. 165 S-PMSI A-D route: Selective PMSI Auto-Discovery route. 167 x-PMSI A-D route: A route that is either an I-PMSI A-D route or an 168 S-PMSI A-D route. 170 2. Overview of BGP for BIER-TE Path 172 This section briefs the BGP for BIER-TE path and illustrates some 173 details through a simple example BIER-TE topology. 175 2.1. Example BIER-TE Topology with BGP 177 An example BIER-TE domain topology using SDN controller with a BGP to 178 distribute BIER-TE path is shown in Figure 1. There are 8 nodes/BFRs 179 A, B, C, D, E, F, G and H in the domain. Nodes/BFRs A, H, E, F and D 180 are BFIRs (i.e., ingress nodes) or BFERs (i.e., egress nodes). The 181 controller has a BGP session with each of the edge nodes in the 182 domain, including BFIRs (i.e., ingress nodes A, H, E, F and D), and 183 each of the non edge nodes in the domain (i.e., nodes B, C and G). 184 Note that some of connections and the BGP on each edge node are not 185 shown in the figure. 187 +------------------------------------+ 188 | SND controller with BGP | 189 +------------------------------------+ 190 / ... \ \ 191 / \ \ 192 / 4' \ 17' 18' \ 193 / /-----------( G )----------( H ) 194 / / 19'\_______ 12'/4 195 / / _______)____/ 196 / / / (_____ 197 / /3' / \ 198 / 1' 2' / 5' 6' /11' 13' 20'\ 199 (CE) --- ( A )--------( B )------------( C )------------( D ) 200 5 \7' \15' 14' 1 201 \ \ 202 \8' 9' 10' \16' 203 ( E )------------( F ) 204 3 2 206 Figure 1: Example BIER-TE Topology with Controller 208 Nodes/BFRs D, F, E, H and A are BFERs (or BFIRs) and have local decap 209 adjacency BitPositions 1, 2, 3, 4, and 5 respectively. 211 The BitPositions for the forward connected adjacencies are 212 represented by i', where i is from 1 to 20. 214 2.2. Distributing Path to Ingress 216 This section describes how the SDN controller distributes a BIER-TE 217 path to its ingress node. 219 There are two scenarios for distributing the BIER-TE path 220 information. In the first scenario, the ingress node is directly 221 connected to the controller. The path information should not be 222 propagated beyond the ingress node. In the second scenario, the 223 ingress node is not directly connected to the controller. The path 224 information should be propagated throughout the domain until it 225 reaches the ingress node. 227 Suppose that node A in Figure 1 wants to have a BIER-TE path from 228 ingress node A to egress nodes H and F. The path satisfies a set of 229 constraints. The controller obtains the request from an application 230 or user configuration. It finds a BIER-TE path satisfying the 231 constraints and distributes the path to ingress node A. 233 If A is directly connected to the controller (e.g., as the example 234 network in Figure 1), then the controller sends A the information 235 about the path in a Update message in one of two ways. In one way, 236 the controller sends each of its BGP peers, including the BGP peer 237 running on node A, a Update message about the explicit path, with a 238 route target matching the BGP identifier of ingress node A, and 239 NO_ADVERTISE community. Ingress node A accepts this message from the 240 controller and installs a forwarding entry for the BIER-TE path, but 241 will not advertise it to any peer. All the other peers do not accept 242 the message. 244 In another way, the controller sends A a Update message directly 245 through the local session between them, but does not send the message 246 to any other peers. The message contains the information about the 247 path, a route target matching the BGP identifier of ingress node A 248 and the NO_ADVERTISE community. Ingress node A accepts this message 249 from the controller and installs a forwarding entry for the BIER-TE 250 path, but will not advertise it. 252 If A is not directly connected to the controller, then the controller 253 distributes the information about the explicit path to the ingress 254 node A across the network. To achieve this, the controller 255 advertises a BGP Update message to all its BGP peers, where the 256 message contains the information about the path, a route target 257 matching the BGP identifier of ingress node A, but does not have 258 NO_ADVERTISE community. Each of the BGP peers advertises the 259 received Update to its BGP neighbors according to normal BGP 260 propagation rules. Eventually, ingress node A accepts this message 261 and installs a forwarding entry for the BIER-TE path, which imports 262 the packets to be transported by the path into the path. 264 3. Extensions to BGP 266 This section defines a new Tunnel Type (or say TLV) for BIER-TE path/ 267 tunnel under Tunnel Encapsulation Attribute and a new SAFI. This new 268 SAFI and the existing AFI for IPv4/IPv6 pair uses a new NLRI for 269 indicating a BIER-TE Path. 271 3.1. New SAFI and NLRI 273 A new SAFI, called BIER-TE path SAFI, is defined. Its codepoint 274 (TBD1) is to be assigned by IANA. This new SAFI and the existing AFI 275 for IPv4/IPv6 pair uses a new NLRI, which is defined as follows: 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 | NLRI Length | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Distinguisher (4 octets) | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Tunnel Identifier (11/23 octets) ~ 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 2: NLRI Format 289 Where: 291 NLRI Length: 1 octet represents the length of NLRI. If the Length 292 is anything other than 15 or 27, the NLRI is corrupt and the 293 enclosing UPDATE message MUST be ignored. 295 Distinguisher: 4 octet value uniquely identifies the content/BIER-TE 296 path. 298 Tunnel Identifier: 11/23 octet value contains: 300 * sub-domain-id (1 octet): It is id of the sub domain through 301 which the BIER-TE tunnel crosses. 303 * BFR-id (2 octets): It is the BFR-id of the BFIR of the BIER-TE 304 tunnel. 306 * Tunnel-ID (4 octets): It is a number uniquely identifying a 307 BIER-TE tunnel within the BFIR and sub domain. 309 * BFR-prefix (4/16 octets): It is a BFR-prefix of the BFIR of the 310 BIER-TE tunnel. It occupies 4 octets for IPv4 and 16 octets 311 for IPv6. 313 3.2. New Tunnel Type for BIER-TE 315 A new Tunnel Type (or say TLV), called BIER-TE Path or Tunnel, is 316 defined under Tunnel Encapsulation Attribute in [RFC9012]. Its 317 codepoint is to be assigned by IANA. This new TLV with a number of 318 new sub-TLVs encodes the information about a BIER-TE path. 320 The structure encoding the information about a BIER-TE path is shown 321 below. 323 Attributes: 324 Tunnel Encaps Attribute (23) 325 Tunnel Type (TBD2): BIER-TE Path 326 Path BitPositions sub-TLV 327 Path Name sub-TLV 328 Traffic Description sub-TLV 330 Where: 332 * Tunnel Type (TBD2) is to be assigned by IANA. 334 * Path BitPositions sub-TLV encodes the bit positions of the BIER-TE 335 path. 337 * Path Name sub-TLV encodes the name of a BIER-TE path. 339 * Traffic Description sub-TLV encodes the multicast traffic that is 340 transported by the BIER-TE path. 342 3.3. Path BitPositions Sub-TLV 344 The bit positions of a BIER-TE path are encoded in a Path 345 BitPositions sub-TLV. The format of the sub-TLV is illustrated 346 below. 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Type (TBD3) | Length (variable) | Reserved | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | SI-Len | BitStringLen | sub-domain-id | MT-ID | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | BIFT-id-1 | RSV | SI-1 | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | BitString-1 ~ 358 | ~ 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 : : 361 : : 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | BIFT-id-n | RSV | SI-n | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | BitString-n ~ 366 | ~ 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 Figure 3: Path BitPositions Sub-TLV Format 371 Type: Its value (TBD3) is to be assigned by IANA. 373 Length: It is variable. 375 Reserved/RSV: MUST be set to zero by the sender and MUST be ignored 376 by the receiver. 378 SI-Len (SI Length) - 8 bits: The length in bits of the SI field. 380 BitStringLen (Bit String Length) - 8 bits: The length in bits of the 381 BitString field according to [RFC8296]. If k is the length of the 382 BitString, the value of BitStringLen is log2(k)-5. For example, 383 BitStringLen = 1 indicates k = 64, BitStringLen = 7 indicates k = 384 4096. 386 sub-domain-id: Unique value identifying the BIER sub-domain within 387 the BIER domain. 389 MT-ID: Multi-Topology ID identifying the topology that is associated 390 with the BIER sub-domain. 392 tuple: Each tuple (i = 1, 2, ..., n) represents/encodes a set of bit 394 positions on the BIER-TE path with a BIFT ID. All the tuples in 395 the sub-TLV represent/encode the BIER-TE path (i.e., all the bit 396 positions of the BIER-TE path). 398 3.4. Path Name Sub-TLV 400 The name of a BIER-TE path is encoded in a Path Name sub-TLV. The 401 format of the sub-TLV is illustrated below. 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Type (TBD4) | Length (variable) | Reserved | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 // Path Name String // 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Figure 4: Path Name Sub-TLV Format 413 Type: Its value (TBD4) is to be assigned by IANA. 415 Length: It is variable. 417 Reserved: MUST be set to zero by the sender and MUST be ignored by 418 the receiver. 420 Path Name String: It represents/encodes the name of the BIER-TE path 421 in a string of chars. 423 3.5. Traffic Description Sub-TLVs 425 A Traffic Description Sub-TLV describes the traffic to be imported 426 into a BIER-TE path. Two Traffic Description Sub-TLVs are defined. 427 They are multicast traffic sub-TLVs for IPv4 and IPv6. 429 The multicast traffic sub-TLVs for IPv4 and IPv6 are shown in 430 Figure 5 and Figure 6 respectively. 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Type (TBD5) | Length | Reserved | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Reserved |S|G| Src Mask Len | Grp Mask Len | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Source Address (up to 4 bytes) ~ 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Group Multicast Address (up to 4 bytes) ~ 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Figure 5: Multicast Traffic for IPv4 Sub-TLV 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Type (TBD6) | Length | RESERVED | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Reserved |S|G| Src Mask Len | Grp Mask Len | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Source Address ~ 454 ~ (up to 16 bytes) ~ 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Group multicast Address ~ 457 ~ (up to 16 bytes) ~ 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 Figure 6: Multicast Traffic for IPv6 Sub-TLV 462 The address fields and address mask lengths of the two Multicast 463 Traffic sub-TLVs contain source and group prefixes for matching 464 against packets noting that the two address fields are up to 32 bits 465 for an IPv4 Multicast Traffic and up to 128 bits for an IPv6 466 Multicast Traffic. 468 The Reserved field MUST be set to zero and ignored on receipt. 470 Two bit flags (S and G) are defined to describe the multicast 471 wildcarding in use. If the S bit is set, then source wildcarding is 472 in use and the values in the Source Mask Length and Source Address 473 fields MUST be ignored. If the G bit is set, then group wildcarding 474 is in use and the values in the Group Mask Length and Group multicast 475 Address fields MUST be ignored. The G bit MUST NOT be set unless the 476 S bit is also set: if a Multicast Traffic sub-TLV is received with S 477 bit = 0 and G bit = 1 the receiver MUST respond with an error 478 (Malformed Multicast Traffic). 480 The three multicast mappings may be achieved as follows: 482 (S, G): S bit = 0, G bit = 0, the Source Address and Group multicast 483 Address prefixes are both used to define the multicast traffic. 485 (*, G): S bit = 1, G bit = 0, the Group multicast Address prefix is 486 used to define the multicast traffic, but the Source Address 487 prefix is ignored. 489 (*, *): S bit = 1, G bit = 1, the Source Address and Group multicast 490 Address prefixes are both ignored. 492 4. Security Considerations 494 Protocol extensions defined in this document do not affect the BGP 495 security other than those as discussed in the Security Considerations 496 section of [RFC9012]. 498 5. Acknowledgements 500 The authors of this document would like to thank Tony Przygienda, 501 Susan Hares, and Jeffrey Zhang for their comments. 503 6. IANA Considerations 505 6.1. Existing Registry: SAFI Parameters 507 This document requests assigning a new SAFI in the registry 508 "Subsequent Address Family Identifiers (SAFI) Parameters" as follows: 510 +=======================+=========================+=============+ 511 | Code Point | Description | Reference | 512 +=======================+=========================+=============+ 513 | TBD1(179 suggested) | BIER-TE Policy SAFI |This document| 514 +=======================+=========================+=============+ 516 6.2. Existing Registry: BGP TEA Tunnel Types 518 This document requests assigning a new Tunnel-Type in the registry 519 "BGP Tunnel Encapsulation Attribute Tunnel Types" as follows: 521 +=======================+=========================+=============+ 522 | Code Point | Description | Reference | 523 +=======================+=========================+=============+ 524 | TBD2(16 suggested) | BIER-TE Tunnel/Path |This document| 525 +=======================+=========================+=============+ 527 6.3. Existing Registry: BGP TEA sub-TLVs 529 This document requests assigning a few of new sub-TLVs in the 530 registry "BGP Tunnel Encapsulation Attribute sub-TLVs" as follows: 532 +=======================+=========================+=============+ 533 | Code Point | Description | Reference | 534 +=======================+=========================+=============+ 535 | TBD3(16 suggested) | Path BitPositions |This document| 536 +=======================+=========================+=============+ 537 | TBD4(17 suggested) | Path Name |This document| 538 +=======================+=========================+=============+ 539 | TBD5(18 suggested) | IPv4 Multicast Traffic |This document| 540 +=======================+=========================+=============+ 541 | TBD6(19 suggested) | IPv6 Multicast Traffic |This document| 542 +=======================+=========================+=============+ 544 7. References 546 7.1. Normative 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 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 554 Encodings and Procedures for Multicast in MPLS/BGP IP 555 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 556 . 558 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 559 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 560 May 2017, . 562 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 563 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 564 Explicit Replication (BIER)", RFC 8279, 565 DOI 10.17487/RFC8279, November 2017, 566 . 568 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 569 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 570 for Bit Index Explicit Replication (BIER) in MPLS and Non- 571 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 572 2018, . 574 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 575 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 576 DOI 10.17487/RFC9012, April 2021, 577 . 579 7.2. Informative References 581 [I-D.ietf-bier-te-arch] 582 Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering 583 for Bit Index Explicit Replication (BIER-TE)", Work in 584 Progress, Internet-Draft, draft-ietf-bier-te-arch-11, 15 585 November 2021, . 588 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 589 IANA Considerations Section in RFCs", RFC 5226, 590 DOI 10.17487/RFC5226, May 2008, 591 . 593 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 594 and D. McPherson, "Dissemination of Flow Specification 595 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 596 . 598 Appendix A. Extensions to PMSI_TUNNEL Attribute 600 This section defines a new Tunnel Type (or TLV) for BIER-TE path/ 601 tunnel under the PMSI_TUNNEL Attribute (PTA) defined in [RFC6514]. 602 It describes a couple of new sub-TLVs encoding the information about 603 a BIER-TE path. 605 A.1. New Tunnel Type for BIER-TE 607 The PMSI Tunnel attribute carried by an x-PMSI A-D route identifies 608 P-tunnel for PMSI. For the PTA with Tunnel Type BIER-TE, the PTA is 609 constructed by the SDN controller and distributed to the ingress node 610 of the BIER-TE tunnel. 612 The format of the PMSI_TUNNEL Attribute with the new Tunnel Type 613 (TBD) for BIER-TE is shown in Figure 7. 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Attr Flags | Attr Type(22) | Length(1/2 byte) ~ 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Flag |TunnelType(TBD)| MPLS Label | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | MPLS Label | Tunnel Identifier (11/23 bytes) | 623 +-+-+-+-+-+-+-+-+ + 624 | ~ 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | sub-TLVs ~ 627 ~ ~ 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Figure 7: PTA with Tunnel Type for BIER-TE 632 For BIER-TE tunnel/path, the fields in the PTA are set as follows: 634 o Tunnel Type: It is set to be TBD, indicating BIER-TE tunnel. 636 o Tunnel Identifier: It contains: sub-domain-id of 1 byte, BIER-TE 637 tunnel BFIR's BFR-id of 2 bytes, Tunnel-ID of 4 bytes, and 638 BIER-TE tunnel BFIR's BFR-prefix of 4/16 bytes for IPv4/IPv6. 640 o sub-TLVs: It contains a Path BitPositions sub-TLV encoding an 641 explicit BIER-TE path. It may include a Path Name sub-TLV for 642 the name of the BIER-TE path. 644 o Others: The other fields are set according to [RFC6514]. 646 Authors' Addresses 647 Huaimo Chen 648 Futurewei 649 Boston, MA, 650 United States of America 652 Email: huaimo.chen@futurewei.com 654 Mike McBride 655 Futurewei 657 Email: michael.mcbride@futurewei.com 659 Ran Chen 660 ZTE Corporation 662 Email: chen.ran@zte.com.cn 664 Gyan S. Mishra 665 Verizon Inc. 666 13101 Columbia Pike 667 Silver Spring, MD 20904 668 United States of America 670 Phone: 301 502-1347 671 Email: gyan.s.mishra@verizon.com 673 Aijun Wang 674 China Telecom 675 Beiqijia Town, Changping District 676 Beijing 677 102209 678 China 680 Email: wangaj3@chinatelecom.cn 682 Yisong Liu 683 China Mobile 685 Email: liuyisong@chinamobile.com 686 Yanhe Fan 687 Casa Systems 688 United States of America 690 Email: yfan@casa-systems.com 692 Boris Khasanov 693 Yandex LLC 694 Moscow 696 Email: bhassanov@yahoo.com 698 Lei Liu 699 Fujitsu 700 United States of America 702 Email: liulei.kddi@gmail.com 704 Xufeng Liu 705 Volta Networks 706 McLean, VA 707 United States of America 709 Email: xufeng.liu.ietf@gmail.com