idnits 2.17.1 draft-hb-idr-sr-p2mp-policy-02.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 (June 04, 2021) is 1057 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 715, 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: December 6, 2021 Bell Canada 6 A. Stone 7 Nokia 8 R. Parekh 9 Cisco System 10 S. Krier 11 A. Venkateswaran 12 Cisco System, Inc. 13 June 04, 2021 15 Advertising p2mp policies in BGP 16 draft-hb-idr-sr-p2mp-policy-02 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 two 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 and another for the replication segment and forwarding 35 instructions that needs to be programmed on the Root, and optionally 36 on Transit and Leaf nodes. 38 It should be noted that this document does not specify how the Root 39 and the Leaves are discovered on the controller, it only describes 40 how the P2MP Policy and Replication Segments are programmed from the 41 controller to the nodes. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at https://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on December 6, 2021. 60 Copyright Notice 62 Copyright (c) 2021 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (https://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified 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 - Route type TBD 2 . . . . 6 83 3.2. Tunnel Encapsulation Attribute . . . . . . . . . . . . . 7 84 3.2.1. SR P2MP policy encoding . . . . . . . . . . . . . . . 7 85 3.2.2. Replication segment encoding . . . . . . . . . . . . 8 86 3.3. P2MP Policy Sub-TLVs . . . . . . . . . . . . . . . . . . 9 87 3.3.1. preference Sub-TLV . . . . . . . . . . . . . . . . . 9 88 3.3.2. leaf-list Sub-TLV . . . . . . . . . . . . . . . . . . 9 89 3.3.3. path-instance Sub-TLV . . . . . . . . . . . . . . . . 10 90 3.3.3.1. active instance-id Sub-TLV . . . . . . . . . . . 10 91 3.3.3.2. instance-id Sub-TLV . . . . . . . . . . . . . . . 11 92 3.4. Replication segment Sub-TLVs . . . . . . . . . . . . . . 11 93 3.4.1. Replication SID (Binding SID) . . . . . . . . . . . . 11 94 3.4.2. Down stream nodes Sub-TLV . . . . . . . . . . . . . . 12 95 3.4.3. Segment list Sub-TLV . . . . . . . . . . . . . . . . 13 96 3.4.4. Weight sub-tlv . . . . . . . . . . . . . . . . . . . 13 97 3.4.5. Protection sub-tlv . . . . . . . . . . . . . . . . . 13 98 3.4.6. Segment Sub-TLV . . . . . . . . . . . . . . . . . . . 14 99 4. P2MP Policy Operation . . . . . . . . . . . . . . . . . . . . 15 100 4.1. Configuration and advertisement of P2MP Policies . . . . 15 101 4.2. Reception of an P2MP Policy NLRI . . . . . . . . . . . . 15 102 4.3. Global Optimization for P2MP LSPs . . . . . . . . . . . . 16 103 5. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 16 104 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 105 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 106 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 107 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 108 8.2. Informative References . . . . . . . . . . . . . . . . . 17 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 111 1. Introduction 113 The draft [draft-ietf-pim-sr-p2mp-policy] defines a variant of the SR 114 Policy [draft-ietf-spring-segment-routing-policy] for constructing a 115 P2MP segment to support multicast service delivery. 117 A Point-to-Multipoint (P2MP) Policy contains a set of candidate paths 118 and identifies a Root node and a set of Leaf nodes in a Segment 119 Routing Domain. The draft also defines a Replication segment, which 120 corresponds to the state of a P2MP segment on a particular node. The 121 Replication segment is the forwarding instruction for a P2MP LSP at 122 the Root, Transit and Leaf nodes. 124 For a P2MP segment, a controller may be used to compute a tree from a 125 Root node to a set of Leaf nodes, optionally via a set of replication 126 nodes. A packet is replicated at the root node and optionally on 127 Replication nodes towards each Leaf node. 129 We define two types of a P2MP segment: Ingress Replication (aka 130 Spray) and Downstream Replication (aka TreeSID). 132 A Point-to-Multipoint service delivery could be via Ingress 133 Replication (aka Spray in some SR context), i.e., the root unicasts 134 individual copies of traffic to each leaf. The corresponding P2MP 135 segment consists of replication segments only for the root and the 136 leaves. 138 A Point-to-Multipoint service delivery could also be via Downstream 139 Replication (aka TreeSID in some SR context), i.e., the root and some 140 downstream replication nodes replicate the traffic along the way as 141 it traverses closer to the leaves. 143 It should be noted that two replication nodes can be connected 144 directly, or they can be connected via unicast SR segment or a 145 segment list. 147 The leaves and the root of a p2mp policy can be discovered via the 148 multicast protocols or procedures like NG-MVPN [RFC6513] or manually 149 configured on the PCC (CLI) or the PCE. 151 Based on the discovered root and leaves, the controller builds a P2MP 152 policy and advertise it to the head-end router (i.e. the root of the 153 P2MP Tree). The advertisement uses BGP extensions defined in this 154 document. The controller also calculates the tree path and builds 155 the replication segments on each segment of the tree, Root, Transit 156 and Leaf nodes and downloads the forwarding instructions to the nodes 157 via BGP extensions defined in this document. 159 SR p2mp policy is a variant of the SR policy and as such it reuses 160 the concept of a candidate path. This draft reuses some of the 161 concepts and TLVs mentioned in 162 [draft-ietf-idr-segment-routing-te-policy] 164 A candidate path with in the P2MP policy can contain multiple path- 165 instances. A path-instance can be viewed as a P2MP LSP. For 166 candidate path global optimization purposes, two or more path- 167 instances can be used to execute make before break procedures. 169 Each path-instance is a P2MP LSP as such each path-instance needs a 170 set of replication segments to construct its forwarding instructions. 172 2. Conventions used in this document 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC 2119 [RFC2119]. 178 3. P2MP Policy and Replication Segment Encoding 180 3.1. P2MP Policy SAFI and NLRI 182 This document defines a new BGP NLRI, called the P2MP-POLICY NLRI. 184 A new SAFI is defined: the SR P2MP Policy SAFI, (Codepoint tbd 185 assigned by IANA). The following is the format of the P2MP-POLICY 186 NLRI: 188 +-----------------------------------+ 189 | route type | 1 octet 190 +-----------------------------------+ 191 | length | 1 octet 192 +-----------------------------------+ 193 | route type specific (variable) | 194 +-----------------------------------+ 196 o The Route type field defines the encoding of the rest of the P2MP- 197 POLICY NLRI. 199 o The length field indicates the length in octets of the route type 200 specific data, excluding route type and length 202 o This document defines the following route types: 204 * P2MP Policy route: TBD1 206 * Replication Segment: TBD2 208 The NLRI containing the SR P2MP Policy is carried in a BGP UPDATE 209 message [RFC4271] using BGP multiprotocol extensions [RFC4760] with 210 an AFI of 1 or 2 (IPv4 or IPv6) and with a SAFI of "TBD" (assigned by 211 IANA from the "Subsequent Address Family Identifiers (SAFI) 212 Parameters" registry). 214 All other recommendations of 215 [draft-ietf-idr-segment-routing-te-policy] section SR Policy SAFI and 216 NLRI, should be taken into account for P2MP policy. 218 3.1.1. P2MP Policy Route - Route Type TBD1 220 +-----------------------------------+ 221 ~ Root-ID ~ 4 or 16 octets (ipv4/ipv6) 222 +-----------------------------------+ 223 | Tree-ID | 4 octets 224 +-----------------------------------+ 225 | Distinguisher | 4 octets 226 +-----------------------------------+ 228 o Root-ID: IPv4/IPv6 address of the head-end (Root) of the p2mp 229 tree, based on AFI. 231 o Tree-ID: a unique 4 octets identifier of the p2mp tree on the 232 head- end (root)router. 234 o Distinguisher: 4-octets value uniquely identifying the policy in 235 the context of tuple. The 236 distinguisher has no semantic value and is solely used by the SR 237 P2MP Policy originator to make unique (from an NLRI perspective) 238 multiple occurrences of the same SR P2MP Policy. 240 3.1.2. Replication segment Route - Route type TBD 2 242 There can be two type of replication segment, shared and non-shared. 243 A shared replication segment can carry multiple MVPN services or it 244 can be used for Facility Fast reroute protecting multiple P2MP trees. 245 A non-shared tree is used when the label field of the PMSI Tunnel 246 Attribute (PTA) is set to 0 as per 247 [draft-ietf-bess-mvpn-evpn-sr-p2mp]. The following route type can be 248 encoded as per [draft-ietf-idr-segment-routing-te-policy] for shared 249 and non-shared replication segment. 251 +-----------------------------------+ 252 ~ Root-ID ~ 4 or 16 octets (ipv4/ipv6) 253 +-----------------------------------+ 254 | Tree-ID | 4 octets 255 +-----------------------------------+ 256 | instance-ID | 2 octets 257 +-----------------------------------+ 258 | Distinguisher | 4 octets 259 +-----------------------------------+ 260 | Node-ID | 2 octets 261 +-----------------------------------+ 263 o Root-ID: IPv4/IPv6 address of the head-end (Root) of the p2mp tree 264 based on AFI. 266 o Tree-ID: a unique 4 octets identifier of the p2mp tree on the 267 head- end router (Root) 269 o instance-id, identifies the path-instance with in the p2mp- 270 policy. Each candidate path can have one, two or more path- 271 instance. Path-instance is used for global optimization of the 272 candidate path via make before break procedures. Instance-ID can 273 be used 275 o Distinguisher: 4-octets value uniquely identifying the policy in 276 the context of tuple. The distinguisher has no 277 semantic value and is solely used by the SR P2MP Policy originator 278 to make unique (from an NLRI perspective) multiple occurrences of 279 the same SR P2MP Policy. 281 o Node-ID: Node's IPv4/IPv6 address 283 3.2. Tunnel Encapsulation Attribute 285 The content of this new NLRI is encoded in the tunnel Encapsulation 286 Attribute originally defined in [ietf-idr-tunnel-encaps] using two 287 new Tunnel-Type TLV (codepoint is TBD, assigned by IANA from the "BGP 288 Tunnel Encapsulation Attribute Tunnel Types" registry) one for P2MP 289 Policy and another for Replication segment. 291 3.2.1. SR P2MP policy encoding 293 SR P2MP Policy SAFI NLRI: 294 Attributes: 295 Tunnel Encaps Attribute (23) 296 Tunnel Type: (TBD, P2MP-Policy) 297 Preference 298 Policy Name 299 Policy Candidate Path Name 300 leaf-list (optional) 301 remote-end point 302 remote-end point 303 ... 304 path-instance 305 active-instance-id 306 instance-id 307 instance-id 308 ... 310 o Relevant only at the Root. 312 o SR P2MP-POLICY NLRI and P2MP Policy route type. 314 o Tunnel Encapsulation Attribute is defined in 315 [ietf-idr-tunnel-encaps] 317 o Tunnel-Type is set to P2MP-Policy Tunnel-Type TBD (assigned by 318 IANA from the "BGP Tunnel Encapsulation Attribute Tunnel Types" 319 registry). 321 o Policy Name, Policy Candidate Path Name are defined in 322 [draft-ietf-idr-segment-routing-te-policy] 324 o Preference, leaf-list, remote-end point and path- instance, 325 instance-ids are defined in this document. 327 o Additional sub-TLVs may be defined in the future. 329 3.2.2. Replication segment encoding 331 replication segment SAFI NLRI: 333 Attributes: 334 Tunnel Encaps Attribute (23) 335 Tunnel Type: (TBD Replication-Segment) 336 replication-sid (equivalent to Binding Sid) 337 SRv6 replication-sid (equivalent to SRv6 Binding SID) 338 downstream-nodes (can be protection enabled via a flag) 339 segment-list 340 weight (optional) 341 protection (optional, must be present when protection flag is enabled for downstream-nodes) 342 segment 343 segment 344 ... 345 segment-list 346 weight (optional) 347 protection (optional, must be present when protection flag is enabled for downstream-nodes) 348 segment 349 segment 350 ... 351 segment-list (protection segment list) 352 protection (protecting the first segment list, can't have weight sub-tlv) 353 segment 354 segment 355 ... 356 ... 357 ... 359 o SR P2MP-POLICY NLRI and non-shared tree Replication segment route 360 type or shared tree Replication segment route type. 362 o Tunnel Encapsulation Attribute is defined in 363 [ietf-idr-tunnel-encaps]. 365 o Tunnel-Type is set to Replication Segment Tunnel Type, TBD 366 (assigned by IANA from the "BGP Tunnel Encapsulation Attribute 367 Tunnel Types" registry). 369 o tree-identifier, replication-sid (binding sid), SRv6 replication- 370 sid, downstream-nodes and segment-list are defined in this 371 document. 373 o Additional sub-TLVs may be defined in the future. 375 3.3. P2MP Policy Sub-TLVs 377 EACH P2MP policy NLRI represents a candidate path for a P2MP policy. 378 A P2MP policy can have multiple candidate paths and would need 379 multiple P2MP policy NRLI to download all the candidate paths. 381 3.3.1. preference Sub-TLV 383 As defined in preference Sub-TLV section in 384 [draft-ietf-idr-segment-routing-te-policy] the candidate path with 385 highest preference is the active candidate path. 387 3.3.2. leaf-list Sub-TLV 389 The leaf list sub-tlv identifies a set of leaves for the tree. Each 390 leaf is a remote endpoint as defined in [ietf-idr-tunnel-encaps] The 391 leaf-list sub-tlv is optional. The PCE can choose to download the 392 leaf list every time it is configured or learns a new leaf. If the 393 PCE chooses to download this optional sub-tlv it should download the 394 entire set of the end-points every time the endpoint list has been 395 modified. The leaf list has informational value only hence why it is 396 optonal and it is not required for the root PE to operate. However, 397 it must be noted that in some cases the end-points list can become 398 very large with 100s of leaves. 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Type | Length | RESERVED | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 // sub-TLVs // 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 o Type: TBD, 1 octet 410 o Length: 2 octets, the total length (not including the Type and 411 Length fields) of the sub-TLVs encoded within the leaf-list sub- 412 TLV. 414 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 415 transmission and MUST be ignored on receipt. 417 o sub-TLVs: One or more remote endpoint sub-TLVs. Note the remote 418 endpoint object is defined in [ietf-idr-tunnel-encaps] 420 3.3.3. path-instance Sub-TLV 422 The path instance sub-tlv contains a set of instance-ids (P2MP LSPs). 423 These LSPs can be used for MBB procedure under a candidate path. 424 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. 427 The active instance is identified via the active instance-id sub-tlv. 429 The P2MP LSP and its replication segments should be configured from 430 root to the leaves first before the PCE switches that active 431 instance-id to this new instance. 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type | Length | RESERVED | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 // Sub-TLVs // 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 o Type: TBD, 1 octet 443 o Length: 2 octets, the total length (not including the Type and 444 Length fields) of the sub-TLVs encoded within the Segment List 445 sub-TLV. 447 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 448 transmission and MUST be ignored on receipt 450 o sub-TLVs: * active instance-id * one or more instance-id 452 3.3.3.1. active instance-id Sub-TLV 454 The Active instance-id is used to identify the P2MP LSP which should 455 be active amongst the collection of instances. 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Type | Length | RESERVED | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | active instance-id | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 o Type: TBD. 467 o Length: the total length (not including the Type and Length 468 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 470 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 471 transmission and MUST be ignored on receipt. 473 o active instant-id: The identifier of the active instance-id 475 3.3.3.2. instance-id Sub-TLV 477 Multiple Instance-ids can be programmed for a candidate path. 479 0 1 2 3 480 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 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Type | Length | RESERVED | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | instance-id | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 o Type: TBD 489 o Length: the total length (not including the Type and Length 490 fields) of the sub-TLVs encoded within the Segment List sub-TLV. 492 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 493 transmission and MUST be ignored on receipt. 495 o instan-id: a 32 bit unique identifier. The instance-id is unique 496 with in the context of the 498 3.4. Replication segment Sub-TLVs 500 3.4.1. Replication SID (Binding SID) 502 The Replication SID is form of a Binding SID as it is defined in 503 [draft-ietf-idr-segment-routing-te-policy]. The definition of 504 replication sid with in P2MP Policy is defined in 505 [draft-ietf-spring-sr-replication-segment]. On the transit and leaf 506 node the replication SID can be used to identify the replication 507 segment and the forwarding information at the node. However on the 508 head-end node (Root), the replication segment acts as a Binding SID 509 to direct the traffic into the P2MP Tree. It should be noted that 510 two replication SIDs can be directly connected or connected via a 511 unicast SR segment list, in this case the replication sid needs to be 512 at the bottom of sid. 514 The sr-te-policy binding sid and SRv6 binding sid sub-tlvs are used 515 for replication sid. This draft defines a new flag for replication 516 sid at transit and leaf node 518 0 1 2 3 4 5 6 7 519 +-+-+-+-+-+-+-+-+ 520 |S|I|R| | 521 +-+-+-+-+-+-+-+-+ 523 R-FLAG: is Replication SID. Replication SID can be used to define 524 the forwarding information of the transit or leaf nodes. 526 3.4.2. Down stream nodes Sub-TLV 528 The down-stream nodes sub-tlv is the list of down stream nodes that 529 the arriving packet needs to be replicated to. As an example an 530 arriving packet that needs to be replicated to downstream node A and 531 node B will have two down stream node TLVs. Each down stream node 532 sub-tlv could have a single segment list or multiple segment list. 533 Multiple segment list can be used for ECMP or fast reroute. In the 534 case of the fast reroute the downstream node flag needs to set the P 535 bit to explicitly indicate the this downstream node is protected and 536 the protection sub-tlv needs to be included with every segment list. 538 0 1 2 3 539 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 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Type | Length | Flags |P| RESERVED | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 ~ downstream node id ~ 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 // sub-TLVs // 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 o Type: TBD. 550 o Length: the total length (not including the Type and Length 551 fields) of the sub-TLVs encoded within the down-stream nodes sub- 552 TLV. 554 o RESERVED: 1 octet of reserved bits. SHOULD be unset on 555 transmission and MUST be ignored on receipt. 557 o flags p: this down stream node has protected segment list. 559 o downstream node id: an id to uniquely identify the downstream node 560 for this sub-tlv, as an example the loopback IPv4/IPv6 of the 561 node. 563 o sub-TLVs: One or more segment list sub-TLVs. As an example there 564 can be Two segment list for ECMP or FRR. 566 3.4.3. Segment list Sub-TLV 568 The segment list Sub-TLV is defined in 569 [ietf-spring-segment-routing-policy]. The segment-list Sub-TLV 570 contains one or more segment Sub-TLVs. Two replication segments can 571 be directly connected via a replication sid or can be connected via a 572 unicast segment list and a replication sid. In the later case the 573 replication sid needs to be at the bottom of the unicast segment 574 list. 576 3.4.4. Weight sub-tlv 578 The Weight sub-TLV is optional and is as defined in 579 [draft-ietf-idr-segment-routing-te-policy]. With in the downstream 580 node sub-tlv, there can be one or more segment list used for ECMP. 581 In this case the weight sub-tlv can provide weighted ECMP. 583 3.4.5. Protection sub-tlv 585 Protection sub-tlv is optional, if FRR is desired for the downstream 586 node this sub-tlv can be used to identify the protection segment 587 list. To identify protection segment list this sub-tlv provides a 588 segment list identifier. If protection is desired under the endpoint 589 all the segment lists should have this sub-tlv. A protection segment 590 list can not have a weight sub-tlv and it can not participate in 591 ECMP. That said a segment list that is being protected can have a 592 weight sub-tlv and participate in ECMP. 594 In general protection segment list is used only if replication 595 segments are directly connected and there is no unicast segment list 596 connecting two replication segment. If there is a unicast 597 replication segment connecting the two replication sid, then the 598 unicast protection mechanism can be exercise and there is no need for 599 this protection sub-tlv, hence why this sub-tlv is optional. 601 0 1 2 3 602 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 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Type | Length | Flags |P| RESERVED | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | segment list id | protection segment list id | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 o Type : tbd, 1 octet. 611 o Length: 8 613 o Flag: 1 octet, the P bit is set when this segment list is 614 protected by another segment list for the downstream node 616 o segment list id: the segment list id 618 o protection segment list id: the segment list id that is being used 619 as protection. 621 3.4.6. Segment Sub-TLV 623 The segment sub-Tlv is identified in 624 [draft-ietf-idr-segment-routing-te-policy]. As it was mentioned 625 before two replication segments can be connected directly to each 626 other or via a segment list. If they are connected directly to each 627 other then the segment list can be constructed via: 629 o If the replication segment is steered via IPv4 or IPv6 nexthops or 630 interface then the segment type E or G can be used with the new R 631 flag set. 633 o If the replication segment is steered via a SR Unicast node or 634 adjacency SID then segment type A can be used with the new R flag 635 set. Unicast SR segment types can also be configured for 636 steering. 638 If they are connected via SR domain then the segment list can contain 639 multiple different types of SIDs, such as Node, Adjacency or Binding 640 SIDe. In this case the replication sid is at the bottom of the stack 641 and of type A with the R flag set. The SR node/adjacency or binding 642 sids steer the packet through a SR domain until it reaches another 643 replication segment. where the bottom of the stack replication sid 644 identifies the forwarding information on that replication segment. 646 A replication segment can use the same type of segment types defined 647 in [draft-ietf-idr-segment-routing-te-policy]. To identify a 648 replication segment explicitly a new flag is defined. 650 0 1 2 3 4 5 6 7 651 +-+-+-+-+-+-+-+-+ 652 |V|A|R| | 653 +-+-+-+-+-+-+-+-+ 655 Where R-Flag is set for a segment Sub-TLV that identifies a 656 Replication Segment. It should be noted that in a segment list only 657 the last segment can have the R flag set. Multiple replication 658 segments can not be stacked on top of each other. That said there 659 can be special cases for Link Protection where a bypass tunnel is 660 build via a shared replication segment. As an example when the PCE 661 downloads a bypass tunnel for link protection that is only 662 constructed via shared replication segments to protect a group of 663 non-shared replication segments. 665 4. P2MP Policy Operation 667 Inline with [draft-ietf-idr-segment-routing-te-policy] the consumer 668 of an P2MP Policy is not the BGP process. The BGP process is used 669 for distributing the P2MP policy NLRI and its route-types but its 670 installation and use is outside the scope of BGP. The detail for 671 P2MP Policy can be found in [draft-ietf-pim-sr-p2mp-policy] 673 4.1. Configuration and advertisement of P2MP Policies 675 The controller usually is connected to the receivers via a route 676 reflector. As such one or more route-target SHOULD be attached to 677 the advertisement of P2MP Policy NLRI and its route-type. Each route 678 target identifies one head-end (root nodes) for P2MP Policy route or 679 one or more head-end, transit and leaf nodes for the Non- Shared/ 680 Shared Tree Replication Segment route, for the advertised P2MP 681 Policy. 683 4.2. Reception of an P2MP Policy NLRI 685 When a BGP speaker receives an P2MP Policy NLRI the following rules 686 apply: 688 o The P2MP Policy update MUST have either the NO_ADVERTISE community 689 or at least one route-target extended community in IPv4-address 690 format. If a router supporting this document receives an P2MP 691 Policy update with no route-target extended communities and no 692 NO_ADVERTISE community, the update MUST NOT be processed. 693 Furthermore, it SHOULD be considered to be malformed, and the 694 "treat-as-withdraw" strategy of [RFC7606] is applied. 696 o If one or more route-targets are present, then at least one route- 697 target MUST match one of the BGP Identifiers of the receiver in 698 order for the update to be considered usable. The BGP Identifier 699 is defined in [RFC4271] as a 4 octet IPv4 address. Therefore the 700 route- target extended community MUST be of the same format. 702 o If one or more route-targets are present and no one matches any of 703 the local BGP Identifiers, then, while the P2MP Policy NLRI is 704 acceptable, it is not usable on the receiver node. 706 4.3. Global Optimization for P2MP LSPs 708 When a P2MP LSP needs to be optimized for any reason (i.e. it is 709 taking on an FRR Path or new routers are added to the network) a 710 global optimization is possible. Note that optimization works per 711 candidate path. Each candidate path is capable of global 712 optimization. To do so each candidate path contains two or more 713 path- instances. Each path instance is a P2MP LSP, each P2MP LSP is 714 identified via a path-instance-id (equivalent to an lsp-id 715 [RFC3209]). After calculating an optimized P2MP LSP path the PCE 716 will program the candidate path with a 2nd path instance and its set 717 of replication segments for this path-instance on the root, transit 718 and leaf nodes. After the optimized LSP replication segments are 719 downloaded a MBB procedure is performed and the previous instance of 720 the path instance is deleted and removed from head-end node and its 721 corresponding replication segments from head-end, transit and leaves. 723 5. IANA Consideration 725 o A new SAFI is defined: the SR P2MP Policy SAFI, (Codepoint tbd 726 assigned by IANA) 728 o 2 new Route type field defines the encoding of the rest of the 729 P2MP- POLICY SAFI 731 * P2MP Policy Route 733 * Replication Segment 735 o Two new Tunnel type to be assigned by IANA 737 6. Security Considerations 739 TBD 741 7. Acknowledgments 743 8. References 745 8.1. Normative References 747 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 748 Requirement Levels", BCP 14, RFC 2119, 749 DOI 10.17487/RFC2119, March 1997, 750 . 752 8.2. Informative References 754 [draft-ietf-bess-mvpn-evpn-sr-p2mp] 755 . 757 [draft-ietf-idr-segment-routing-te-policy] 758 . 760 [draft-ietf-pim-sr-p2mp-policy] 761 "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang, 762 "draft-ietf-pim-sr-p2mp-policy"", October 2019. 764 [draft-ietf-spring-segment-routing-policy] 765 . 767 [draft-ietf-spring-sr-replication-segment] 768 "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang, 769 "draft-ietf-pim-sr-p2mp-policy "", July 2020. 771 [ietf-idr-tunnel-encaps] 772 . 774 [ietf-spring-segment-routing-policy] 775 . 777 [RFC4271] . 779 [RFC4760] . 781 [RFC6513] . 783 [RFC7606] . 785 Authors' Addresses 787 Hooman Bidgoli (editor) 788 Nokia 789 Ottawa 790 Canada 792 Email: hooman.bidgoli@nokia.com 793 Daniel Voyer 794 Bell Canada 795 Montreal 796 Canada 798 Email: daniel.yover@bell.ca 800 Andrew Stone 801 Nokia 802 Ottawa 803 Canada 805 Email: andrew.stone@nokia.com 807 Rishabh Parekh 808 Cisco System 809 San Jose 810 USA 812 Email: riparekh@cisco.com 814 Serge Krier 815 Cisco System, Inc. 816 Rixensart 817 Belgium 819 Email: sekrier@cisco.com 821 Arvind Venkateswaran 822 Cisco System, Inc. 823 Ottawa 824 Canada 826 Email: arvvenka@cisco.com