idnits 2.17.1 draft-hb-idr-sr-p2mp-policy-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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 43 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 date (6 October 2021) is 926 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 719, but not defined Summary: 1 error (**), 0 flaws (~~), 2 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 V. Voyer 5 Expires: 9 April 2022 Bell Canada 6 A. Stone 7 Nokia 8 R. Parekh 9 Cisco System 10 S. Krier 11 A. Venkateswaran 12 Cisco System, Inc. 13 6 October 2021 15 Advertising p2mp policies in BGP 16 draft-hb-idr-sr-p2mp-policy-03 18 Abstract 20 SR P2MP policies are set of policies that enable architecture for 21 P2MP service delivery. 23 A P2MP policy consists of candidate paths that connects the Root of 24 the Tree to a set of Leaves. The P2MP policy is composed of 25 replication segments. A replication segment is a forwarding 26 instruction for a candidate path which is downloaded to the Root, 27 transit nodes and the leaves. 29 This document specifies a new BGP SAFI with a new NLRI in order to 30 advertise P2MP policy from a controller to a set of nodes. 32 This document introduces three new route types within this NLRI, one 33 for P2MP policy and its candidate paths that need to be programmed on 34 the Root node, one for the replication segment incoming SID which 35 uniquely will identify the cross connect and another for each 36 outgoing interface that the packets get replicated to. The last two 37 route types are forwarding instructions that needs to be programmed 38 on the Root, and optionally on Transit and Leaf nodes. 40 It should be noted that this document does not specify how the Root 41 and the Leaves are discovered on the controller, it only describes 42 how the P2MP Policy and Replication Segments are programmed from the 43 controller to the nodes. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at https://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on 9 April 2022. 62 Copyright Notice 64 Copyright (c) 2021 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 69 license-info) in effect on the date of publication of this document. 70 Please review these documents carefully, as they describe your rights 71 and restrictions with respect to this document. Code Components 72 extracted from this document must include Simplified BSD License text 73 as described in Section 4.e of the Trust Legal Provisions and are 74 provided without warranty as described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 2. Conventions used in this document . . . . . . . . . . . . . . 4 80 3. P2MP Policy and Replication Segment Encoding . . . . . . . . 4 81 3.1. P2MP Policy SAFI and NLRI . . . . . . . . . . . . . . . . 4 82 3.1.1. P2MP Policy Route - Route Type TBD1 . . . . . . . . . 5 83 3.1.2. Replication segment Route Binding SID- Route type TBD 84 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 85 3.1.3. Replication segment Route OIF- Route type TBD 3 . . . 8 86 3.2. Tunnel Encapsulation Attribute . . . . . . . . . . . . . 9 87 3.2.1. SR P2MP policy encoding . . . . . . . . . . . . . . . 9 88 3.2.2. Replication segment Binding SID encoding . . . . . . 10 89 3.2.3. Replication segment OIF encoding . . . . . . . . . . 10 90 3.3. P2MP Policy Sub-TLVs . . . . . . . . . . . . . . . . . . 11 91 3.3.1. preference Sub-TLV . . . . . . . . . . . . . . . . . 11 92 3.3.2. leaf-list Sub-TLV . . . . . . . . . . . . . . . . . . 11 93 3.3.3. path-instance Sub-TLV . . . . . . . . . . . . . . . . 12 94 3.3.3.1. active instance-id Sub-TLV . . . . . . . . . . . 12 95 3.3.3.2. instance-id Sub-TLV . . . . . . . . . . . . . . . 13 96 3.4. Replication segment Sub-TLVs . . . . . . . . . . . . . . 13 97 3.4.1. Segment list Sub-TLV . . . . . . . . . . . . . . . . 14 98 3.4.2. Weight sub-tlv . . . . . . . . . . . . . . . . . . . 14 99 3.4.3. Protection sub-tlv . . . . . . . . . . . . . . . . . 14 100 3.4.4. Segment Sub-TLV . . . . . . . . . . . . . . . . . . . 15 101 4. P2MP Policy Operation . . . . . . . . . . . . . . . . . . . . 15 102 4.1. Configuration and advertisement of P2MP Policies . . . . 16 103 4.2. Reception of an P2MP Policy NLRI . . . . . . . . . . . . 16 104 4.3. Global Optimization for P2MP LSPs . . . . . . . . . . . . 17 105 5. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 17 106 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 107 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 108 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 109 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 110 8.2. Informative References . . . . . . . . . . . . . . . . . 18 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 113 1. Introduction 115 The draft [draft-ietf-pim-sr-p2mp-policy] defines a variant of the SR 116 Policy [draft-ietf-spring-segment-routing-policy] for constructing a 117 P2MP segment to support multicast service delivery. 119 A Point-to-Multipoint (P2MP) Policy contains a set of candidate paths 120 and identifies a Root node and a set of Leaf nodes in a Segment 121 Routing Domain. The draft also defines a Replication segment, which 122 corresponds to the state of a P2MP segment on a particular node. The 123 Replication segment is the forwarding instruction for a P2MP LSP at 124 the Root, Transit and Leaf nodes. 126 For a P2MP segment, a controller may be used to compute a tree from a 127 Root node to a set of Leaf nodes, optionally via a set of replication 128 nodes. A packet is replicated at the root node and optionally on 129 Replication nodes towards each Leaf node. 131 We define two types of a P2MP segment: Ingress Replication (aka 132 Spray) and Downstream Replication (aka TreeSID). 134 A Point-to-Multipoint service delivery could be via Ingress 135 Replication (aka Spray in some SR context), i.e., the root unicasts 136 individual copies of traffic to each leaf. The corresponding P2MP 137 segment consists of replication segments only for the root and the 138 leaves. 140 A Point-to-Multipoint service delivery could also be via Downstream 141 Replication (aka TreeSID in some SR context), i.e., the root and some 142 downstream replication nodes replicate the traffic along the way as 143 it traverses closer to the leaves. 145 It should be noted that two replication nodes can be connected 146 directly, or they can be connected via unicast SR segment or a 147 segment list. 149 The leaves and the root of a p2mp policy can be discovered via the 150 multicast protocols or procedures like NG-MVPN [RFC6513] or manually 151 configured on the PCC (CLI) or the PCE. 153 Based on the discovered root and leaves, the controller builds a P2MP 154 policy and advertise it to the head-end router (i.e. the root of the 155 P2MP Tree). The advertisement uses BGP extensions defined in this 156 document. The controller also calculates the tree path and builds 157 the replication segments on each segment of the tree, Root, Transit 158 and Leaf nodes and downloads the forwarding instructions to the nodes 159 via BGP extensions defined in this document. 161 SR p2mp policy is a variant of the SR policy and as such it reuses 162 the concept of a candidate path. This draft reuses some of the 163 concepts and TLVs mentioned in 164 [draft-ietf-idr-segment-routing-te-policy] 166 A candidate path with in the P2MP policy can contain multiple path- 167 instances. A path-instance can be viewed as a P2MP LSP. For 168 candidate path global optimization purposes, two or more path- 169 instances can be used to execute make before break procedures. 171 Each path-instance is a P2MP LSP as such each path-instance needs a 172 set of replication segments to construct its forwarding instructions. 174 2. Conventions used in this document 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in RFC 2119 [RFC2119]. 180 3. P2MP Policy and Replication Segment Encoding 182 3.1. P2MP Policy SAFI and NLRI 184 This document defines a new BGP NLRI, called the P2MP-POLICY NLRI. 186 A new SAFI is defined: the SR P2MP Policy SAFI, (Codepoint tbd 187 assigned by IANA). The following is the format of the P2MP-POLICY 188 NLRI: 190 +-----------------------------------+ 191 | route type | 1 octet 192 +-----------------------------------+ 193 | length | 1 octet 194 +-----------------------------------+ 195 | route type specific (variable) | 196 +-----------------------------------+ 198 * The Route type field defines the encoding of the rest of the P2MP- 199 POLICY NLRI. 201 * The length field indicates the length in octets of the route type 202 specific data, excluding route type and length 204 * This document defines the following route types: 206 - P2MP Policy route: TBD1, this is the actually P2MP policy on 207 the root which contains the candidate paths, its prefrence and 208 path instances. 210 - Replication Segment Binding SID: TBD2, this is part of the 211 replication segment and it is used for programming the incoming 212 SID used to identify a P2MP cross connect. 214 - Replication Segment OIF: TBD3, this is a single Outgoing 215 Interface for the P2MP cross connect. It also contains the 216 outgoing SID. 218 The NLRI containing the SR P2MP Policy is carried in a BGP UPDATE 219 message [RFC4271] using BGP multiprotocol extensions [RFC4760] with 220 an AFI of 1 or 2 (IPv4 or IPv6) and with a SAFI of "TBD" (assigned by 221 IANA from the "Subsequent Address Family Identifiers (SAFI) 222 Parameters" registry). 224 All other recommendations of 225 [draft-ietf-idr-segment-routing-te-policy] section SR Policy SAFI and 226 NLRI, should be taken into account for P2MP policy. 228 3.1.1. P2MP Policy Route - Route Type TBD1 229 +-----------------------------------+ 230 | Root-ID Length | 1 octets 231 +-----------------------------------+ 232 ~ Root-ID ~ 4 or 16 octets (ipv4/ipv6) 233 +-----------------------------------+ 234 | Tree-ID | 4 octets 235 +-----------------------------------+ 236 | Distinguisher | 4 octets 237 +-----------------------------------+ 239 * Root-ID: IPv4/IPv6 address of the head-end (Root) of the p2mp 240 tree, based on AFI. 242 * Tree-ID: a unique 4 octets identifier of the p2mp tree on the 243 head- end (root)router. 245 * Distinguisher: 4-octets value uniquely identifying the policy in 246 the context of tuple. The 247 distinguisher has no semantic value and is solely used by the SR 248 P2MP Policy originator to make unique (from an NLRI perspective) 249 multiple occurrences of the same SR P2MP Policy. 251 3.1.2. Replication segment Route Binding SID- Route type TBD 2 253 There can be two type of replication segment, shared and non-shared. 254 A shared replication segment can carry multiple MVPN services or it 255 can be used for Facility Fast reroute protecting multiple P2MP trees. 256 A non-shared tree is used when the label field of the PMSI Tunnel 257 Attribute (PTA) is set to 0 as per 258 [draft-ietf-bess-mvpn-evpn-sr-p2mp]. The Binding SID route type 259 Programs the incoming replication SID on the replication node. Since 260 a replication cross connect has a single incoming replication SID 261 with a set of Outgoing Interfaces, this route type can be used to 262 download the replication SID once for the cross connect. 264 +-----------------------------------+ 265 | Root-ID Length | 1 octets 266 +-----------------------------------+ 267 ~ Root-ID ~ 4 or 16 octets (ipv4/ipv6) 268 +-----------------------------------+ 269 | Tree-ID | 4 octets 270 +-----------------------------------+ 271 | Distinguisher | 2 octets 272 +-----------------------------------+ 273 | instance-ID | 4 octets 274 +-----------------------------------+ 275 | Node-ID Length | 1 octets 276 +-----------------------------------+ 277 ~ Node-ID ~ 4 or 16 octets 278 +-----------------------------------+ 279 | Replication SID Length | 1 octets 280 +-----------------------------------+ 281 ~ Replication SID ~ 4 or 16 octets 282 +-----------------------------------+ 284 * Root-ID: IPv4/IPv6 address of the head-end (Root) of the p2mp tree 285 based on AFI. 287 * Tree-ID: a unique 4 octets identifier of the p2mp tree on the 288 head- end router (Root) 290 * instance-id, identifies the path-instance with in the p2mp- 291 policy. Each candidate path can have one, two or more path- 292 instance. Path-instance is used for global optimization of the 293 candidate path via make before break procedures. Instance-ID can 294 be used 296 * Distinguisher: 4-octets value uniquely identifying the policy in 297 the context of tuple. The distinguisher has no 298 semantic value and is solely used by the SR P2MP Policy originator 299 to make unique (from an NLRI perspective) multiple occurrences of 300 the same SR P2MP Policy. 302 * Node-ID: This Node's IPv4/IPv6 address 304 * Replication SID: the incoming replication SID used to identify 305 this replication point (MPLS or SRv6). Note the replication SID 306 is not part of the NLRI key. 308 3.1.3. Replication segment Route OIF- Route type TBD 3 310 This route type is used to identify and program each out going 311 interface individually for a replication cross connect. Downloading 312 each OIF individually ensures easier modification and programming and 313 will keep the programming of each OIF in par with 314 [draft-ietf-idr-segment-routing-te-policy] . Note: this route type 315 can be used for shared and non-shared replication segment as it was 316 explained in previous sections. 318 +-----------------------------------+ 319 | Root-ID Length | 1 octets 320 +-----------------------------------+ 321 ~ Root-ID ~ 4 or 16 octets (ipv4/ipv6) 322 +-----------------------------------+ 323 | Tree-ID | 4 octets 324 +-----------------------------------+ 325 | Distinguisher | 2 octets 326 +-----------------------------------+ 327 | instance-ID | 4 octets 328 +-----------------------------------+ 329 | Node-ID Length | 1 octets 330 +-----------------------------------+ 331 ~ Node-ID ~ 4 or 16 octets 332 +-----------------------------------+ 333 | Downstream-Node Length | 1 octets 334 +-----------------------------------+ 335 ~ Downstream-Node ~ 4 or 16 octets 336 +-----------------------------------+ 337 | Outgoing-TreeSID Length | 1 octets 338 +-----------------------------------+ 339 ~ Outgoing-TreeSID ~ 4 or 16 octets 340 +-----------------------------------+ 342 * Root-ID: IPv4/IPv6 address of the head-end (Root) of the p2mp tree 343 based on AFI. 345 * Tree-ID: a unique 4 octets identifier of the p2mp tree on the 346 head- end router (Root) 348 * instance-id, identifies the path-instance with in the p2mp- 349 policy. Each candidate path can have one, two or more path- 350 instance. Path-instance is used for global optimization of the 351 candidate path via make before break procedures. Instance-ID can 352 be used 354 * Distinguisher: 4-octets value uniquely identifying the policy in 355 the context of tuple. The distinguisher has no 356 semantic value and is solely used by the SR P2MP Policy originator 357 to make unique (from an NLRI perspective) multiple occurrences of 358 the same SR P2MP Policy. 360 * Node-ID: Node's IPv4/IPv6 address 362 * Downstream Node: Downstream Node Identifier 364 * Outgoing TreeSID: The outgoing SID for this branch (MPLS or SRv6). 365 Note the outgoing-TreeSID is not part of the NLRI Key. 367 3.2. Tunnel Encapsulation Attribute 369 The content of this new NLRI is encoded in the tunnel Encapsulation 370 Attribute originally defined in [ietf-idr-tunnel-encaps] using two 371 new Tunnel-Type TLV (codepoint is TBD, assigned by IANA from the "BGP 372 Tunnel Encapsulation Attribute Tunnel Types" registry) one for P2MP 373 Policy and another for Replication segment. 375 3.2.1. SR P2MP policy encoding 377 SR P2MP Policy SAFI NLRI: 378 Attributes: 379 Tunnel Encaps Attribute (23) 380 Tunnel Type: (TBD, P2MP-Policy) 381 Preference 382 Policy Name 383 Policy Candidate Path Name 384 leaf-list (optional) 385 remote-end point 386 remote-end point 387 ... 388 path-instance 389 active-instance-id 390 instance-id 391 instance-id 392 ... 394 * Relevant only at the Root. 396 * SR P2MP-POLICY NLRI and P2MP Policy route type. 398 * Tunnel Encapsulation Attribute is defined in 399 [ietf-idr-tunnel-encaps] 401 * Tunnel-Type is set to P2MP-Policy Tunnel-Type TBD (assigned by 402 IANA from the "BGP Tunnel Encapsulation Attribute Tunnel Types" 403 registry). 405 * Policy Name, Policy Candidate Path Name are defined in 406 [draft-ietf-idr-segment-routing-te-policy] 408 * Preference, leaf-list, remote-end point and path- instance, 409 instance-ids are defined in this document. 411 * Additional sub-TLVs may be defined in the future. 413 3.2.2. Replication segment Binding SID encoding 415 replication segment Binding SID SAFI NLRI: 418 This route type has no additional sub-TLVs, and it is only meant to 419 download the incoming SID for the replication cross connect. 421 3.2.3. Replication segment OIF encoding 423 replication segment SAFI NLRI: 425 Attributes: 426 Tunnel Encaps Attribute (23) 427 Tunnel Type: (TBD Replication-Segment-oif) 428 segment-list 429 weight (optional) 430 protection (optional, must be present when protection flag is enabled for downstream-nodes) 431 segment 432 segment 433 ... 434 segment-list 435 weight (optional) 436 protection (optional, must be present when protection flag is enabled for downstream-nodes) 437 segment 438 segment 439 ... 440 segment-list (protection segment list) 441 protection (protecting the first segment list, can't have weight sub-tlv) 442 segment 443 segment 444 ... 445 ... 446 ... 448 * SR P2MP-POLICY NLRI and non-shared tree Replication segment route 449 type or shared tree Replication segment route type. 451 * Tunnel Encapsulation Attribute is defined in 452 [ietf-idr-tunnel-encaps]. 454 * Tunnel-Type is set to Replication Segment OIF Tunnel Type, TBD 455 (assigned by IANA from the "BGP Tunnel Encapsulation Attribute 456 Tunnel Types" registry). 458 * segment-list are defined in this document. 460 * Additional sub-TLVs may be defined in the future. 462 3.3. P2MP Policy Sub-TLVs 464 EACH P2MP policy NLRI represents a candidate path for a P2MP policy. 465 A P2MP policy can have multiple candidate paths and would need 466 multiple P2MP policy NRLI to download all the candidate paths. 468 3.3.1. preference Sub-TLV 470 As defined in preference Sub-TLV section in 471 [draft-ietf-idr-segment-routing-te-policy] the candidate path with 472 highest preference is the active candidate path. 474 3.3.2. leaf-list Sub-TLV 476 The leaf list sub-tlv identifies a set of leaves for the tree. Each 477 leaf is a remote endpoint as defined in [ietf-idr-tunnel-encaps] The 478 leaf-list sub-tlv is optional. The PCE can choose to download the 479 leaf list every time it is configured or learns a new leaf. If the 480 PCE chooses to download this optional sub-tlv it should download the 481 entire set of the end-points every time the endpoint list has been 482 modified. The leaf list has informational value only hence why it is 483 optonal and it is not required for the root PE to operate. However, 484 it must be noted that in some cases the end-points list can become 485 very large with 100s of leaves. 487 0 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Type | Length | RESERVED | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 // sub-TLVs // 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 * Type: TBD, 1 octet 496 * Length: 2 octets, the total length (not including the Type and 497 Length fields) of the sub-TLVs encoded within the leaf-list sub- 498 TLV. 500 * RESERVED: 1 octet of reserved bits. SHOULD be unset on 501 transmission and MUST be ignored on receipt. 503 * sub-TLVs: One or more remote endpoint sub-TLVs. Note the remote 504 endpoint object is defined in [ietf-idr-tunnel-encaps] 506 3.3.3. path-instance Sub-TLV 508 The path instance sub-tlv contains a set of instance-ids (P2MP LSPs). 509 These LSPs can be used for MBB procedure under a candidate path. 510 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. 513 The active instance is identified via the active instance-id sub-tlv. 515 The P2MP LSP and its replication segments should be configured from 516 root to the leaves first before the PCE switches that active 517 instance-id to this new instance. 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Type | Length | RESERVED | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 // Sub-TLVs // 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 * Type: TBD, 1 octet 529 * Length: 2 octets, the total length (not including the Type and 530 Length fields) of the sub-TLVs encoded within the Segment List 531 sub-TLV. 533 * RESERVED: 1 octet of reserved bits. SHOULD be unset on 534 transmission and MUST be ignored on receipt 536 * sub-TLVs: * active instance-id * one or more instance-id 538 3.3.3.1. active instance-id Sub-TLV 540 The Active instance-id is used to identify the P2MP LSP which should 541 be active amongst the collection of instances. 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Type | Length | RESERVED | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | active instance-id | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 * Type: TBD. 553 * Length: the total length (not including the Type and Length 554 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 556 * RESERVED: 1 octet of reserved bits. SHOULD be unset on 557 transmission and MUST be ignored on receipt. 559 * active instant-id: The identifier of the active instance-id 561 3.3.3.2. instance-id Sub-TLV 563 Multiple Instance-ids can be programmed for a candidate path. 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Type | Length | RESERVED | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | instance-id | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 * Type: TBD 575 * Length: the total length (not including the Type and Length 576 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 578 * RESERVED: 1 octet of reserved bits. SHOULD be unset on 579 transmission and MUST be ignored on receipt. 581 * instan-id: a 32 bit unique identifier. The instance-id is unique 582 with in the context of the 584 3.4. Replication segment Sub-TLVs 585 3.4.1. Segment list Sub-TLV 587 The segment list Sub-TLV is defined in 588 [ietf-spring-segment-routing-policy]. The segment-list Sub-TLV 589 contains one or more segment Sub-TLVs. Two replication segments can 590 be directly connected via a replication sid or can be connected via a 591 unicast segment list and a replication sid. In the later case the 592 replication sid needs to be at the bottom of the unicast segment 593 list. 595 3.4.2. Weight sub-tlv 597 The Weight sub-TLV is optional and is as defined in 598 [draft-ietf-idr-segment-routing-te-policy]. With in the downstream 599 node sub-tlv, there can be one or more segment list used for ECMP. 600 In this case the weight sub-tlv can provide weighted ECMP. 602 3.4.3. Protection sub-tlv 604 Protection sub-tlv is optional, if FRR is desired for the downstream 605 node this sub-tlv can be used to identify the protection segment 606 list. To identify protection segment list this sub-tlv provides a 607 segment list identifier. If protection is desired under the endpoint 608 all the segment lists should have this sub-tlv. A protection segment 609 list can not have a weight sub-tlv and it can not participate in 610 ECMP. That said a segment list that is being protected can have a 611 weight sub-tlv and participate in ECMP. 613 In general protection segment list is used only if replication 614 segments are directly connected and there is no unicast segment list 615 connecting two replication segment. If there is a unicast 616 replication segment connecting the two replication sid, then the 617 unicast protection mechanism can be exercise and there is no need for 618 this protection sub-tlv, hence why this sub-tlv is optional. 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Type | Length | Flags |P| RESERVED | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | segment list id | protection segment list id | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 * Type : tbd, 1 octet. 630 * Length: 8 631 * Flag: 1 octet, the P bit is set when this segment list is 632 protected by another segment list for the downstream node 634 * segment list id: the segment list id 636 * protection segment list id: the segment list id that is being used 637 as protection. 639 3.4.4. Segment Sub-TLV 641 The segment sub-Tlv is identified in 642 [draft-ietf-idr-segment-routing-te-policy]. As it was mentioned 643 before two replication segments can be connected directly to each 644 other or via a segment list. If they are connected directly to each 645 other then the segment list can be constructed via: 647 * If the replication segment is steered via IPv4 or IPv6 nexthops or 648 interface then the segment type E or G can be used with the new R 649 flag set. 651 * If the replication segment is steered via a SR Unicast node or 652 adjacency SID then segment type A can be used with the new R flag 653 set. Unicast SR segment types can also be configured for 654 steering. 656 If they are connected via SR domain then the segment list can contain 657 multiple different types of SIDs, such as Node, Adjacency or Binding 658 SIDe. In this case the replication sid is at the bottom of the stack 659 and of type A with the R flag set. The SR node/adjacency or binding 660 sids steer the packet through a SR domain until it reaches another 661 replication segment. where the bottom of the stack replication sid 662 identifies the forwarding information on that replication segment. 664 It should be noted that the segment sub-TLV is only used to program 665 the unicast SR Segment or outgoing interface for the replication SID 666 outgoing interface. The outgoing tree SID it self is programmed in 667 the appropriate route type. 669 4. P2MP Policy Operation 671 Inline with [draft-ietf-idr-segment-routing-te-policy] the consumer 672 of an P2MP Policy is not the BGP process. The BGP process is used 673 for distributing the P2MP policy NLRI and its route-types but its 674 installation and use is outside the scope of BGP. The detail for 675 P2MP Policy can be found in [draft-ietf-pim-sr-p2mp-policy] 677 4.1. Configuration and advertisement of P2MP Policies 679 The controller usually is connected to the receivers via a route 680 reflector. As such one or more route-target SHOULD be attached to 681 the advertisement of P2MP Policy NLRI and its route-type. Each route 682 target identifies one head-end (root nodes) for P2MP Policy route or 683 one or more head-end, transit and leaf nodes for the Non- Shared/ 684 Shared Tree Replication Segment route, for the advertised P2MP 685 Policy. 687 4.2. Reception of an P2MP Policy NLRI 689 When a BGP speaker receives an P2MP Policy NLRI the following rules 690 apply: 692 * The P2MP Policy update MUST have either the NO_ADVERTISE community 693 or at least one route-target extended community in IPv4-address 694 format. If a router supporting this document receives an P2MP 695 Policy update with no route-target extended communities and no 696 NO_ADVERTISE community, the update MUST NOT be processed. 697 Furthermore, it SHOULD be considered to be malformed, and the 698 "treat-as-withdraw" strategy of [RFC7606] is applied. 700 * If one or more route-targets are present, then at least one route- 701 target MUST match one of the BGP Identifiers of the receiver in 702 order for the update to be considered usable. The BGP Identifier 703 is defined in [RFC4271] as a 4 octet IPv4 address. Therefore the 704 route- target extended community MUST be of the same format. 706 * If one or more route-targets are present and no one matches any of 707 the local BGP Identifiers, then, while the P2MP Policy NLRI is 708 acceptable, it is not usable on the receiver node. 710 4.3. Global Optimization for P2MP LSPs 712 When a P2MP LSP needs to be optimized for any reason (i.e. it is 713 taking on an FRR Path or new routers are added to the network) a 714 global optimization is possible. Note that optimization works per 715 candidate path. Each candidate path is capable of global 716 optimization. To do so each candidate path contains two or more 717 path- instances. Each path instance is a P2MP LSP, each P2MP LSP is 718 identified via a path-instance-id (equivalent to an lsp-id 719 [RFC3209]). After calculating an optimized P2MP LSP path the PCE 720 will program the candidate path with a 2nd path instance and its set 721 of replication segments for this path-instance on the root, transit 722 and leaf nodes. After the optimized LSP replication segments are 723 downloaded a MBB procedure is performed and the previous instance of 724 the path instance is deleted and removed from head-end node and its 725 corresponding replication segments from head-end, transit and leaves. 727 5. IANA Consideration 729 * A new SAFI is defined: the SR P2MP Policy SAFI, (Codepoint tbd 730 assigned by IANA) 732 * 2 new Route type field defines the encoding of the rest of the 733 P2MP- POLICY SAFI 735 - P2MP Policy Route 737 - Replication Segment Binding Sid 739 - Replication Segment OIF 741 * Two new Tunnel type to be assigned by IANA 743 6. Security Considerations 745 TBD 747 7. Acknowledgments 749 8. References 751 8.1. Normative References 753 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 754 Requirement Levels", BCP 14, RFC 2119, 755 DOI 10.17487/RFC2119, March 1997, 756 . 758 8.2. Informative References 760 [draft-ietf-bess-mvpn-evpn-sr-p2mp] 761 "". 763 [draft-ietf-idr-segment-routing-te-policy] 764 "". 766 [draft-ietf-pim-sr-p2mp-policy] 767 "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang, 768 "draft-ietf-pim-sr-p2mp-policy"", October 2019. 770 [draft-ietf-spring-segment-routing-policy] 771 "". 773 [draft-ietf-spring-sr-replication-segment] 774 "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang, 775 "draft-ietf-pim-sr-p2mp-policy "", July 2020. 777 [ietf-idr-tunnel-encaps] 778 "". 780 [ietf-spring-segment-routing-policy] 781 "". 783 [RFC4271] "". 785 [RFC4760] "". 787 [RFC6513] "". 789 [RFC7606] "". 791 Authors' Addresses 793 Hooman Bidgoli (editor) 794 Nokia 795 Ottawa 796 Canada 798 Email: hooman.bidgoli@nokia.com 800 Daniel Voyer 801 Bell Canada 802 Montreal 803 Canada 804 Email: daniel.yover@bell.ca 806 Andrew Stone 807 Nokia 808 Ottawa 809 Canada 811 Email: andrew.stone@nokia.com 813 Rishabh Parekh 814 Cisco System 815 San Jose, 816 United States of America 818 Email: riparekh@cisco.com 820 Serge Krier 821 Cisco System, Inc. 822 Rixensart 823 Belgium 825 Email: sekrier@cisco.com 827 Arvind Venkateswaran 828 Cisco System, Inc. 829 Ottawa 830 Canada 832 Email: arvvenka@cisco.com