idnits 2.17.1 draft-hb-idr-sr-p2mp-policy-05.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 3 instances of too long lines in the document, the longest one being 31 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (6 April 2022) is 751 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: 'RFC3209' is mentioned on line 716, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Bidgoli, Ed. 3 Internet-Draft Nokia 4 Intended status: Standards Track D. Voyer 5 Expires: 8 October 2022 Bell Canada 6 A. Stone 7 Nokia 8 R. Parekh 9 S. Krier 10 S. Agrewal 11 Cisco System, Inc. 12 6 April 2022 14 Advertising p2mp policies in BGP 15 draft-hb-idr-sr-p2mp-policy-05 17 Abstract 19 SR P2MP policies are set of policies that enable architecture for 20 P2MP service delivery. 22 A P2MP policy consists of candidate paths that connects the Root of 23 the Tree to a set of Leaves. The P2MP policy is composed of 24 replication segments. A replication segment is a forwarding 25 instruction for a candidate path which is downloaded to the Root, 26 transit nodes and the leaves. 28 This document specifies a new BGP SAFI with a new NLRI in order to 29 advertise P2MP policy from a controller to a set of nodes. 31 This document introduces three new route types within this NLRI, one 32 for P2MP policy and its candidate paths that need to be programmed on 33 the Root node, one for the replication segment incoming SID which 34 uniquely will identify the cross connect and another for each 35 outgoing interface that the packets get replicated to. The last two 36 route types are forwarding instructions that needs to be programmed 37 on the Root, and optionally on Transit and Leaf nodes. 39 It should be noted that this document does not specify how the Root 40 and the Leaves are discovered on the controller, it only describes 41 how the P2MP Policy and Replication Segments are programmed from the 42 controller to the nodes. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on 8 October 2022. 61 Copyright Notice 63 Copyright (c) 2022 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 68 license-info) in effect on the date of publication of this document. 69 Please review these documents carefully, as they describe your rights 70 and restrictions with respect to this document. Code Components 71 extracted from this document must include Revised BSD License text as 72 described in Section 4.e of the Trust Legal Provisions and are 73 provided without warranty as described in the Revised BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Conventions used in this document . . . . . . . . . . . . . . 4 79 3. P2MP Policy and Replication Segment Encoding . . . . . . . . 4 80 3.1. P2MP Policy SAFI and NLRI . . . . . . . . . . . . . . . . 4 81 3.1.1. P2MP Policy Route - Route Type TBD1 . . . . . . . . . 5 82 3.1.2. Replication segment Route Binding SID- Route type TBD 83 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 84 3.1.3. Replication segment Route OIF- Route type TBD 3 . . . 8 85 3.2. Tunnel Encapsulation Attribute . . . . . . . . . . . . . 9 86 3.2.1. SR P2MP policy encoding . . . . . . . . . . . . . . . 9 87 3.2.2. Replication segment Binding SID encoding . . . . . . 10 88 3.2.3. Replication segment OIF encoding . . . . . . . . . . 10 89 3.3. P2MP Policy Sub-TLVs . . . . . . . . . . . . . . . . . . 11 90 3.3.1. preference Sub-TLV . . . . . . . . . . . . . . . . . 11 91 3.3.2. leaf-list Sub-TLV . . . . . . . . . . . . . . . . . . 11 92 3.3.3. path-instance Sub-TLV . . . . . . . . . . . . . . . . 12 93 3.3.3.1. active instance-id Sub-TLV . . . . . . . . . . . 12 94 3.3.3.2. instance-id Sub-TLV . . . . . . . . . . . . . . . 13 95 3.4. Replication segment Sub-TLVs . . . . . . . . . . . . . . 13 96 3.4.1. Segment list Sub-TLV . . . . . . . . . . . . . . . . 14 97 3.4.2. Weight sub-tlv . . . . . . . . . . . . . . . . . . . 14 98 3.4.3. Protection sub-tlv . . . . . . . . . . . . . . . . . 14 99 3.4.4. Segment Sub-TLV . . . . . . . . . . . . . . . . . . . 15 100 4. P2MP Policy Operation . . . . . . . . . . . . . . . . . . . . 15 101 4.1. Configuration and advertisement of P2MP Policies . . . . 16 102 4.2. Reception of an P2MP Policy NLRI . . . . . . . . . . . . 16 103 4.3. Global Optimization for P2MP LSPs . . . . . . . . . . . . 16 104 5. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 17 105 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 106 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 107 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 108 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 109 8.2. Informative References . . . . . . . . . . . . . . . . . 17 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 112 1. Introduction 114 The draft [draft-ietf-pim-sr-p2mp-policy] defines a variant of the SR 115 Policy [draft-ietf-spring-segment-routing-policy] for constructing a 116 P2MP segment to support multicast service delivery. 118 A Point-to-Multipoint (P2MP) Policy contains a set of candidate paths 119 and identifies a Root node and a set of Leaf nodes in a Segment 120 Routing Domain. The draft also defines a Replication segment, which 121 corresponds to the state of a P2MP segment on a particular node. The 122 Replication segment is the forwarding instruction for a P2MP LSP at 123 the Root, Transit and Leaf nodes. 125 For a P2MP segment, a controller may be used to compute a tree from a 126 Root node to a set of Leaf nodes, optionally via a set of replication 127 nodes. A packet is replicated at the root node and optionally on 128 Replication nodes towards each Leaf node. 130 We define two types of a P2MP segment: Ingress Replication (aka 131 Spray) and Downstream Replication (aka TreeSID). 133 A Point-to-Multipoint service delivery could be via Ingress 134 Replication (aka Spray in some SR context), i.e., the root unicasts 135 individual copies of traffic to each leaf. The corresponding P2MP 136 segment consists of replication segments only for the root and the 137 leaves. 139 A Point-to-Multipoint service delivery could also be via Downstream 140 Replication (aka TreeSID in some SR context), i.e., the root and some 141 downstream replication nodes replicate the traffic along the way as 142 it traverses closer to the leaves. 144 It should be noted that two replication nodes can be connected 145 directly, or they can be connected via unicast SR segment or a 146 segment list. 148 The leaves and the root of a p2mp policy can be discovered via the 149 multicast protocols or procedures like NG-MVPN [RFC6513] or manually 150 configured on the PCC (CLI) or the PCE. 152 Based on the discovered root and leaves, the controller builds a P2MP 153 policy and advertise it to the head-end router (i.e. the root of the 154 P2MP Tree). The advertisement uses BGP extensions defined in this 155 document. The controller also calculates the tree path and builds 156 the replication segments on each segment of the tree, Root, Transit 157 and Leaf nodes and downloads the forwarding instructions to the nodes 158 via BGP extensions defined in this document. 160 SR p2mp policy is a variant of the SR policy and as such it reuses 161 the concept of a candidate path. This draft reuses some of the 162 concepts and TLVs mentioned in 163 [draft-ietf-idr-segment-routing-te-policy] 165 A candidate path with in the P2MP policy can contain multiple path- 166 instances. A path-instance can be viewed as a P2MP LSP. For 167 candidate path global optimization purposes, two or more path- 168 instances can be used to execute make before break procedures. 170 Each path-instance is a P2MP LSP as such each path-instance needs a 171 set of replication segments to construct its forwarding instructions. 173 2. Conventions used in this document 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in [RFC2119] 179 3. P2MP Policy and Replication Segment Encoding 181 3.1. P2MP Policy SAFI and NLRI 183 This document defines a new BGP NLRI, called the P2MP-POLICY NLRI. 185 A new SAFI is defined: the SR P2MP Policy SAFI, (Codepoint tbd 186 assigned by IANA). The following is the format of the P2MP-POLICY 187 NLRI: 189 +-----------------------------------+ 190 | route type | 1 octet 191 +-----------------------------------+ 192 | length | 1 octet 193 +-----------------------------------+ 194 | route type specific (variable) | 195 +-----------------------------------+ 197 * The Route type field defines the encoding of the rest of the P2MP- 198 POLICY NLRI. 200 * The length field indicates the length in octets of the route type 201 specific data, excluding route type and length 203 * This document defines the following route types: 205 - P2MP Policy route: TBD1, this is the actually P2MP policy on 206 the root which contains the candidate paths, its prefrence and 207 path instances. 209 - Replication Segment Binding SID: TBD2, this is part of the 210 replication segment and it is used for programming the incoming 211 SID used to identify a P2MP cross connect. 213 - Replication Segment OIF: TBD3, this is a single Outgoing 214 Interface for the P2MP cross connect. It also contains the 215 outgoing SID. 217 The NLRI containing the SR P2MP Policy is carried in a BGP UPDATE 218 message [RFC4271] using BGP multiprotocol extensions [RFC4760] with 219 an AFI of 1 or 2 (IPv4 or IPv6) and with a SAFI of "TBD" (assigned by 220 IANA from the "Subsequent Address Family Identifiers (SAFI) 221 Parameters" registry). 223 All other recommendations of 224 [draft-ietf-idr-segment-routing-te-policy] section SR Policy SAFI and 225 NLRI, should be taken into account for P2MP policy. 227 3.1.1. P2MP Policy Route - Route Type TBD1 228 +-----------------------------------+ 229 | Root-ID Length | 1 octets 230 +-----------------------------------+ 231 ~ Root-ID ~ 4 or 16 octets (ipv4/ipv6) 232 +-----------------------------------+ 233 | Tree-ID | 4 octets 234 +-----------------------------------+ 235 | Distinguisher | 4 octets 236 +-----------------------------------+ 238 * Root-ID: IPv4/IPv6 address of the head-end (Root) of the p2mp 239 tree, based on AFI. 241 * Tree-ID: a unique 4 octets identifier of the p2mp tree on the 242 head- end (root)router. 244 * Distinguisher: 4-octets value uniquely identifying the policy in 245 the context of tuple. The 246 distinguisher has no semantic value and is solely used by the SR 247 P2MP Policy originator to make unique (from an NLRI perspective) 248 multiple occurrences of the same SR P2MP Policy. 250 3.1.2. Replication segment Route Binding SID- Route type TBD 2 252 There can be two type of replication segment, shared and non-shared. 253 A shared replication segment can carry multiple MVPN services or it 254 can be used for Facility Fast reroute protecting multiple P2MP trees. 255 A non-shared tree is used when the label field of the PMSI Tunnel 256 Attribute (PTA) is set to 0 as per 257 [draft-ietf-bess-mvpn-evpn-sr-p2mp]. The Binding SID route type 258 Programs the incoming replication SID on the replication node. Since 259 a replication cross connect has a single incoming replication SID 260 with a set of Outgoing Interfaces, this route type can be used to 261 download the replication SID once for the cross connect. 263 +-----------------------------------+ 264 | Root-ID Length | 1 octets 265 +-----------------------------------+ 266 ~ Root-ID ~ 4 or 16 octets (ipv4/ipv6) 267 +-----------------------------------+ 268 | Tree-ID | 4 octets 269 +-----------------------------------+ 270 | Distinguisher | 4 octets 271 +-----------------------------------+ 272 | instance-ID | 2 octets 273 +-----------------------------------+ 274 | Node-ID Length | 1 octets 275 +-----------------------------------+ 276 ~ Node-ID ~ 4 or 16 octets 277 +-----------------------------------+ 278 | Replication SID Length | 1 octets 279 +-----------------------------------+ 280 ~ Replication SID ~ 4 or 16 octets 281 +-----------------------------------+ 283 * Root-ID: IPv4/IPv6 address of the head-end (Root) of the p2mp tree 284 based on AFI. 286 * Tree-ID: a unique 4 octets identifier of the p2mp tree on the 287 head- end router (Root) 289 * instance-id, identifies the path-instance with in the p2mp- 290 policy. Each candidate path can have one, two or more path- 291 instance. Path-instance is used for global optimization of the 292 candidate path via make before break procedures. Instance-ID can 293 be used 295 * Distinguisher: 4-octets value uniquely identifying the policy in 296 the context of tuple. The distinguisher has no 297 semantic value and is solely used by the SR P2MP Policy originator 298 to make unique (from an NLRI perspective) multiple occurrences of 299 the same SR P2MP Policy. 301 * Node-ID: This Node's IPv4/IPv6 address 303 * Replication SID: the incoming replication SID used to identify 304 this replication point (MPLS or SRv6). Note the replication SID 305 is not part of the NLRI key. 307 3.1.3. Replication segment Route OIF- Route type TBD 3 309 This route type is used to identify and program each out going 310 interface individually for a replication cross connect. Downloading 311 each OIF individually ensures easier modification and programming and 312 will keep the programming of each OIF in par with 313 [draft-ietf-idr-segment-routing-te-policy] . Note: this route type 314 can be used for shared and non-shared replication segment as it was 315 explained in previous sections. 317 +-----------------------------------+ 318 | Root-ID Length | 1 octets 319 +-----------------------------------+ 320 ~ Root-ID ~ 4 or 16 octets (ipv4/ipv6) 321 +-----------------------------------+ 322 | Tree-ID | 4 octets 323 +-----------------------------------+ 324 | Distinguisher | 4 octets 325 +-----------------------------------+ 326 | instance-ID | 2 octets 327 +-----------------------------------+ 328 | Node-ID Length | 1 octets 329 +-----------------------------------+ 330 ~ Node-ID ~ 4 or 16 octets 331 +-----------------------------------+ 332 | Downstream-Node Length | 1 octets 333 +-----------------------------------+ 334 ~ Downstream-Node ~ 4 or 16 octets 335 +-----------------------------------+ 336 | Outgoing-TreeSID Length | 1 octets 337 +-----------------------------------+ 338 ~ Outgoing-TreeSID ~ 4 or 16 octets 339 +-----------------------------------+ 341 * Root-ID: IPv4/IPv6 address of the head-end (Root) of the p2mp tree 342 based on AFI. 344 * Tree-ID: a unique 4 octets identifier of the p2mp tree on the 345 head- end router (Root) 347 * instance-id, identifies the path-instance with in the p2mp- 348 policy. Each candidate path can have one, two or more path- 349 instance. Path-instance is used for global optimization of the 350 candidate path via make before break procedures. Instance-ID can 351 be used 353 * Distinguisher: 4-octets value uniquely identifying the policy in 354 the context of tuple. The distinguisher has no 355 semantic value and is solely used by the SR P2MP Policy originator 356 to make unique (from an NLRI perspective) multiple occurrences of 357 the same SR P2MP Policy. 359 * Node-ID: Node's IPv4/IPv6 address 361 * Downstream Node: Downstream Node Identifier 363 * Outgoing TreeSID: The outgoing SID for this branch (MPLS or SRv6). 364 Note the outgoing-TreeSID is not part of the NLRI Key. 366 3.2. Tunnel Encapsulation Attribute 368 The content of this new NLRI is encoded in the tunnel Encapsulation 369 Attribute originally defined in [RFC9012] using two new Tunnel-Type 370 TLV (codepoint is TBD, assigned by IANA from the "BGP Tunnel 371 Encapsulation Attribute Tunnel Types" registry) one for P2MP Policy 372 and another for Replication segment. 374 3.2.1. SR P2MP policy encoding 376 SR P2MP Policy SAFI NLRI: 377 Attributes: 378 Tunnel Encaps Attribute (23) 379 Tunnel Type: (TBD, P2MP-Policy) 380 Preference 381 Policy Name 382 Policy Candidate Path Name 383 leaf-list (optional) 384 remote-end point 385 remote-end point 386 ... 387 path-instance 388 active-instance-id 389 instance-id 390 instance-id 391 ... 393 * Relevant only at the Root. 395 * SR P2MP-POLICY NLRI and P2MP Policy route type. 397 * Tunnel Encapsulation Attribute is defined in [RFC9012] 398 * Tunnel-Type is set to P2MP-Policy Tunnel-Type TBD (assigned by 399 IANA from the "BGP Tunnel Encapsulation Attribute Tunnel Types" 400 registry). 402 * Policy Name, Policy Candidate Path Name are defined in 403 [draft-ietf-idr-segment-routing-te-policy] 405 * Preference, leaf-list, remote-end point and path- instance, 406 instance-ids are defined in this document. 408 * Additional sub-TLVs may be defined in the future. 410 3.2.2. Replication segment Binding SID encoding 412 replication segment Binding SID SAFI NLRI: 413 416 This route type has no additional sub-TLVs, and it is only meant to 417 download the incoming SID for the replication cross connect. 419 3.2.3. Replication segment OIF encoding 421 replication segment SAFI NLRI: 423 Attributes: 424 Tunnel Encaps Attribute (23) 425 Tunnel Type: (TBD Replication-Segment-oif) 426 segment-list 427 weight (optional) 428 protection (optional, must be present when protection flag is enabled for downstream-nodes) 429 segment 430 segment 431 ... 432 segment-list 433 weight (optional) 434 protection (optional, must be present when protection flag is enabled for downstream-nodes) 435 segment 436 segment 437 ... 438 segment-list (protection segment list) 439 protection (protecting the first segment list, can't have weight sub-tlv) 440 segment 441 segment 442 ... 443 ... 444 ... 446 * SR P2MP-POLICY NLRI and non-shared tree Replication segment route 447 type or shared tree Replication segment route type. 449 * Tunnel Encapsulation Attribute is defined in [RFC9012]. 451 * Tunnel-Type is set to Replication Segment OIF Tunnel Type, TBD 452 (assigned by IANA from the "BGP Tunnel Encapsulation Attribute 453 Tunnel Types" registry). 455 * segment-list are defined in this document. 457 * Additional sub-TLVs may be defined in the future. 459 3.3. P2MP Policy Sub-TLVs 461 EACH P2MP policy NLRI represents a candidate path for a P2MP policy. 462 A P2MP policy can have multiple candidate paths and would need 463 multiple P2MP policy NRLI to download all the candidate paths. 465 3.3.1. preference Sub-TLV 467 As defined in preference Sub-TLV section in 468 [draft-ietf-idr-segment-routing-te-policy] the candidate path with 469 highest preference is the active candidate path. 471 3.3.2. leaf-list Sub-TLV 473 The leaf list sub-tlv identifies a set of leaves for the tree. Each 474 leaf is a remote endpoint as defined in [RFC9012] The leaf-list sub- 475 tlv is optional. The PCE can choose to download the leaf list every 476 time it is configured or learns a new leaf. If the PCE chooses to 477 download this optional sub-tlv it should download the entire set of 478 the end-points every time the endpoint list has been modified. The 479 leaf list has informational value only hence why it is optonal and it 480 is not required for the root PE to operate. However, it must be 481 noted that in some cases the end-points list can become very large 482 with 100s of leaves. 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Type | Length | RESERVED | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 // sub-TLVs // 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 * Type: TBD, 1 octet 493 * Length: 2 octets, the total length (not including the Type and 494 Length fields) of the sub-TLVs encoded within the leaf-list sub- 495 TLV. 497 * RESERVED: 1 octet of reserved bits. SHOULD be unset on 498 transmission and MUST be ignored on receipt. 500 * sub-TLVs: One or more remote endpoint sub-TLVs. Note the remote 501 endpoint object is defined in [RFC9012] 503 3.3.3. path-instance Sub-TLV 505 The path instance sub-tlv contains a set of instance-ids (P2MP LSPs). 506 These LSPs can be used for MBB procedure under a candidate path. 507 Each LSP Instance-id has a unique id (4 octets) with in the , in other word it is unique per . The PCE SHOULD always download all instance-ids to the node. 510 The active instance is identified via the active instance-id sub-tlv. 512 The P2MP LSP and its replication segments should be configured from 513 root to the leaves first before the PCE switches that active 514 instance-id to this new instance. 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Type | Length | RESERVED | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 // Sub-TLVs // 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 * Type: TBD, 1 octet 526 * Length: 2 octets, the total length (not including the Type and 527 Length fields) of the sub-TLVs encoded within the Segment List 528 sub-TLV. 530 * RESERVED: 1 octet of reserved bits. SHOULD be unset on 531 transmission and MUST be ignored on receipt 533 * sub-TLVs: * active instance-id * one or more instance-id 535 3.3.3.1. active instance-id Sub-TLV 537 The Active instance-id is used to identify the P2MP LSP which should 538 be active amongst the collection of instances. 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Type | Length | RESERVED | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | active instance-id | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 * Type: TBD. 550 * Length: the total length (not including the Type and Length 551 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 553 * RESERVED: 1 octet of reserved bits. SHOULD be unset on 554 transmission and MUST be ignored on receipt. 556 * active instant-id: The identifier of the active instance-id 558 3.3.3.2. instance-id Sub-TLV 560 Multiple Instance-ids can be programmed for a candidate path. 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Type | Length | RESERVED | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | instance-id | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 * Type: TBD 572 * Length: the total length (not including the Type and Length 573 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 575 * RESERVED: 1 octet of reserved bits. SHOULD be unset on 576 transmission and MUST be ignored on receipt. 578 * instan-id: a 32 bit unique identifier. The instance-id is unique 579 with in the context of the 581 3.4. Replication segment Sub-TLVs 582 3.4.1. Segment list Sub-TLV 584 The segment list Sub-TLV is defined in 585 [draft-ietf-spring-segment-routing-policy]. The segment-list Sub-TLV 586 contains one or more segment Sub-TLVs. Two replication segments can 587 be directly connected via a replication sid or can be connected via a 588 unicast segment list and a replication sid. In the later case the 589 replication sid needs to be at the bottom of the unicast segment 590 list. 592 3.4.2. Weight sub-tlv 594 The Weight sub-TLV is optional and is as defined in 595 [draft-ietf-idr-segment-routing-te-policy]. With in the downstream 596 node sub-tlv, there can be one or more segment list used for ECMP. 597 In this case the weight sub-tlv can provide weighted ECMP. 599 3.4.3. Protection sub-tlv 601 Protection sub-tlv is optional, if FRR is desired for the downstream 602 node this sub-tlv can be used to identify the protection segment 603 list. To identify protection segment list this sub-tlv provides a 604 segment list identifier. If protection is desired under the endpoint 605 all the segment lists should have this sub-tlv. A protection segment 606 list can not have a weight sub-tlv and it can not participate in 607 ECMP. That said a segment list that is being protected can have a 608 weight sub-tlv and participate in ECMP. 610 In general protection segment list is used only if replication 611 segments are directly connected and there is no unicast segment list 612 connecting two replication segment. If there is a unicast 613 replication segment connecting the two replication sid, then the 614 unicast protection mechanism can be exercise and there is no need for 615 this protection sub-tlv, hence why this sub-tlv is optional. 617 0 1 2 3 618 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 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Type | Length | Flags |P| RESERVED | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | segment list id | protection segment list id | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 * Type : tbd, 1 octet. 627 * Length: 8 628 * Flag: 1 octet, the P bit is set when this segment list is 629 protected by another segment list for the downstream node 631 * segment list id: the segment list id 633 * protection segment list id: the segment list id that is being used 634 as protection. 636 3.4.4. Segment Sub-TLV 638 The segment sub-Tlv is identified in 639 [draft-ietf-idr-segment-routing-te-policy]. As it was mentioned 640 before two replication segments can be connected directly to each 641 other or via a segment list. If they are connected directly to each 642 other then the segment list can be constructed via: 644 * If the replication segment is steered via IPv4 or IPv6 nexthops or 645 interface then the segment type E or G can be used with the new R 646 flag set. 648 * If the replication segment is steered via a SR Unicast node or 649 adjacency SID then segment type A can be used with the new R flag 650 set. Unicast SR segment types can also be configured for 651 steering. 653 If they are connected via SR domain then the segment list can contain 654 multiple different types of SIDs, such as Node, Adjacency or Binding 655 SIDe. In this case the replication sid is at the bottom of the stack 656 and of type A with the R flag set. The SR node/adjacency or binding 657 sids steer the packet through a SR domain until it reaches another 658 replication segment. where the bottom of the stack replication sid 659 identifies the forwarding information on that replication segment. 661 It should be noted that the segment sub-TLV is only used to program 662 the unicast SR Segment or outgoing interface for the replication SID 663 outgoing interface. The outgoing tree SID it self is programmed in 664 the appropriate route type. 666 4. P2MP Policy Operation 668 Inline with [draft-ietf-idr-segment-routing-te-policy] the consumer 669 of an P2MP Policy is not the BGP process. The BGP process is used 670 for distributing the P2MP policy NLRI and its route-types but its 671 installation and use is outside the scope of BGP. The detail for 672 P2MP Policy can be found in [draft-ietf-pim-sr-p2mp-policy] 674 4.1. Configuration and advertisement of P2MP Policies 676 The controller usually is connected to the receivers via a route 677 reflector. As such one or more route-target SHOULD be attached to 678 the advertisement of P2MP Policy NLRI and its route-type. Each route 679 target identifies one head-end (root nodes) for P2MP Policy route or 680 one or more head-end, transit and leaf nodes for the Non- Shared/ 681 Shared Tree Replication Segment route, for the advertised P2MP 682 Policy. 684 4.2. Reception of an P2MP Policy NLRI 686 When a BGP speaker receives an P2MP Policy NLRI the following rules 687 apply: 689 * The P2MP Policy update MUST have either the NO_ADVERTISE community 690 or at least one route-target extended community in IPv4-address 691 format. If a router supporting this document receives an P2MP 692 Policy update with no route-target extended communities and no 693 NO_ADVERTISE community, the update MUST NOT be processed. 694 Furthermore, it SHOULD be considered to be malformed, and the 695 "treat-as-withdraw" strategy of [RFC7606] is applied. 697 * If one or more route-targets are present, then at least one route- 698 target MUST match one of the BGP Identifiers of the receiver in 699 order for the update to be considered usable. The BGP Identifier 700 is defined in [RFC4271] as a 4 octet IPv4 address. Therefore the 701 route- target extended community MUST be of the same format. 703 * If one or more route-targets are present and no one matches any of 704 the local BGP Identifiers, then, while the P2MP Policy NLRI is 705 acceptable, it is not usable on the receiver node. 707 4.3. Global Optimization for P2MP LSPs 709 When a P2MP LSP needs to be optimized for any reason (i.e. it is 710 taking on an FRR Path or new routers are added to the network) a 711 global optimization is possible. Note that optimization works per 712 candidate path. Each candidate path is capable of global 713 optimization. To do so each candidate path contains two or more 714 path- instances. Each path instance is a P2MP LSP, each P2MP LSP is 715 identified via a path-instance-id (equivalent to an lsp-id 716 [RFC3209]). After calculating an optimized P2MP LSP path the PCE 717 will program the candidate path with a 2nd path instance and its set 718 of replication segments for this path-instance on the root, transit 719 and leaf nodes. After the optimized LSP replication segments are 720 downloaded a MBB procedure is performed and the previous instance of 721 the path instance is deleted and removed from head-end node and its 722 corresponding replication segments from head-end, transit and leaves. 724 5. IANA Consideration 726 * A new SAFI is defined: the SR P2MP Policy SAFI, (Codepoint tbd 727 assigned by IANA) 729 * 3 new Route type field defines the encoding of the rest of the 730 P2MP- POLICY SAFI 732 - P2MP Policy Route 734 - Replication Segment Binding Sid 736 - Replication Segment OIF 738 * Two new Tunnel type to be assigned by IANA 740 - P2MP-Policy Tunnel-Type 742 - Replication Segment OIF Tunnel Type 744 6. Security Considerations 746 TBD 748 7. Acknowledgments 750 8. References 752 8.1. Normative References 754 [RFC2119] "S. Bradner "Key Words for use in RFCs to Indicate 755 Requirement levels"", October 2019. 757 8.2. Informative References 759 [draft-ietf-bess-mvpn-evpn-sr-p2mp] 760 "R. Parekh, C. Filsfils, A.V. Venkateswaran, H. Bidgoli, 761 D. Voyer, Z. Zhang "Multicast and Ethernet VPN with 762 Segment Routing P2MP"". 764 [draft-ietf-idr-segment-routing-te-policy] 765 "s. Previdi, C. Filsfils, K. Talaulikar, P. Mattes, D. 766 Jain, S. Lin "Advertise Segment Routing Policies in BGP"". 768 [draft-ietf-pim-sr-p2mp-policy] 769 "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang, 770 "draft-ietf-pim-sr-p2mp-policy"", October 2019. 772 [draft-ietf-spring-segment-routing-policy] 773 "C. Filsfils, K. Talaulikar, D. Voyer, A. Bogdanov, P. 774 Mattes "Segment Routing Policy Architecture"". 776 [RFC4271] "Y. Rekhter, T. Li, S. Hares "A Border Gateway Protocol 4 777 (BGP-4)"". 779 [RFC4760] "T. Bates, R. Chandra, D. Katz, Y. Rekhter "Multiprotocol 780 Extensions for BGP-4"". 782 [RFC6513] "E. Rosen, R. Aggarwal "Multicast in MPLS/BGP IP VPNs"". 784 [RFC7606] "e. Chen, J. Scudder, P. Mohapatra, K. Patel "Revised 785 Error handling for BGP UPDATE Messages"". 787 [RFC9012] "K. Patel, G. Van de Velde, S. Sangli, J. Scudder "The BGP 788 Tunnel Encapsulation Attribute"". 790 Authors' Addresses 792 Hooman Bidgoli (editor) 793 Nokia 794 Ottawa 795 Canada 796 Email: hooman.bidgoli@nokia.com 798 Daniel Voyer 799 Bell Canada 800 Montreal 801 Canada 802 Email: daniel.yover@bell.ca 804 Andrew Stone 805 Nokia 806 Ottawa 807 Canada 808 Email: andrew.stone@nokia.com 809 Rishabh Parekh 810 Cisco System, Inc. 811 San Jose, 812 United States of America 813 Email: riparekh@cisco.com 815 Serge Krier 816 Cisco System, Inc. 817 Rixensart 818 Belgium 819 Email: sekrier@cisco.com 821 Swadesh Agrewal 822 Cisco System, Inc. 823 San Jose, 824 United States of America 825 Email: swaagraw@cisco.com