[pim] Ketan Talaulikar's Discuss on draft-ietf-pim-sr-p2mp-p olicy-18: (with DISCUSS and COMMENT)
Ketan Talaulikar via Datatracker <[email protected]>
| Newsgroups | gmane.ietf.pim |
|---|---|
| Message-ID | <175567318700.742197.15453893452344525789@dt-datatracker-d8bcd59c-frtgg> |
Ketan Talaulikar has entered the following ballot position for draft-ietf-pim-sr-p2mp-policy-18: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to the authors and the WG for your work on this document. Note: My review was done on v17 of the document and while v18 does touch upon some of the same areas/aspects brought in this review, I will request the authors to please cross-check. While the proposal is quite straightforward, it took me a few passes to grasp the the information model of the different constructs introduced in this document and their interrelationship. Perhaps it is because I am comparing it with RFC9256 that specified the constructs for SR Policy. I will attempt to describe the model based on my reading of the document, and would appreciate if the authors can correct/clarify any errors in my understanding. Please note some discussions points that I've brought up as part of this description so as to provide a better context. An SR P2MP Policy is a construct that represents a (set of?) P2MP trees in a SR domain that can be used for delivery of P2MP service (i.e., multicast traffic). Each SR P2MP Policy is identified by <Root, Tree-ID>. Note: Tree-ID doesn't identify a P2MP tree so seems like an odd choice for the term but it is too late to change this? An SR P2MP Policy can have one or more CPs where each provides constraints and optimization objective for the computation of a specific tree topology from root to leaves. Each CP is identified by <Protocol Origin, Originator, Discriminator> which is same as in the case of a SR Policy CP. Please see my comment on making this explicit. Each CP that is valid (i.e., for which a tree can be computed) has at least one P2MP tree instance associated with it. There can be more than one instance in cases like make-before-break (MBB). Within a CP, each P2MP tree instance is identified by an Instance-ID. At any point, only one CP is active and this is selected based on the same tie-breaking logic as for SR Policy CPs. All the constructs until this point are instantiated only on the root node. -- discuss #1: The document text (see below) seems to indicate that it is only the replication segment that is instantiated on the root node while the SR P2MP Policy construct is something on the controller. I believe, that is not the case, and please clarify with explicit text saying that the SR P2MP Policy is instantiated on the root node. As an example, unless instantiated on it, the root may not be able to perform monitoring/OAM on the tree corresponding to the active CP and switchover (without controller action) to a backup CP on failure (this is what is described in section 4.5.2?). section 2.2. says "An SR P2MP Policy is provisioned on a controller (see Section 4). The controller computes the P2MP tree instances of Candidate Paths of the policy and instantiates the necessary Replication segments at the Root, Replication and Leaf nodes of the trees. " -- Now, we switch to RFC9524 that specified Replication Segment which is identified as <replication node id, replication-id>. Note that per RFC9524 the replication-id is a variable length field and is not actually specified in that document. This document actually specifies the replication-id to be <Root, Tree-ID, Instance-ID>. -- discuss #2 : The text in 2.3 that conveys this is not very clear (please see the comments section for suggestions). It also makes me wonder if this document should "update" RFC9524? -- The replication segment thus represents a unique per P2MP tree context at each root, intermediate and leaf nodes of a specific P2MP tree within the context of an SR P2MP Policy CP in the network. -- discuss #3: This makes the section 3.2 of shared replication segments somewhat confusing. That section seems to say that replication segment MAY be shared across different P2MP tree instances and then says shared replication segment MUST NOT be associated with an SR P2MP tree in v17. In v18, this text is modified but the explanation is still not clear on how they are used for the P2MP tree. -- The instantiation of these per P2MP tree replication segment constructs on the root, intermediate and leaf nodes in the computed tree setup the forwarding context in the network. Now, the terminology section says that the terms 'P2MP tree instance' and 'P2MP tree' are used interchangeably. -- discuss #4: Why can't the same consistent term 'P2MP tree' be used throughout the document? Is there a subtle difference with the use of "instance" here? -- Then we come to section 3 which specifies the P2MP tree construct in a way that is disconnected with the SR P2MP Policy construct. Is it because the SR P2MP Policy construct is something that only exists on the controller (see discuss#1 above) ? Then the replication segment and its replication SID constructs from RFC9524 are introduced within the P2MP Tree context. -- discuss #5: The replication SID associated with the replication segment at the root node is specified as the tree SID. This maps it to a specific P2MP tree under a specific CP under a specific SR P2MP Policy. It is not clear if there are multiple tree SIDs associated with a single CP (one per P2MP tree?) or if each CP has only one tree SID. It is also not clear if the same tree SID can be used by all CPs of the same SR P2MP Policy. -- One of the challenges that I faced during the review of this document is the attempts at establishing equivalency between SR P2MP Policy and SR Policy. I found this to be problematic (please also see in the comments section for more details). -- discuss #6: Section 2.4 introduces the term Binding SID for SR P2MP Policy but does not specify what it is. It says Tree-SID of the active CP SHOULD be used as the BSID, but does not say what happens if that is not the case? Is there a need to introduce BSID here and is it not sufficient to only use the Tree-SID always in the context of SR P2MP Policy? -- -- discuss #7: Sections 4.1, talks about allocation of Tree SID. However, it does specify whether allocation is from the SRGB, SRLB, dynamic range, or any of them (along with any recommendations). Same goes for the replication SIDs at intermediate and leaf nodes. Please also note a detailed comment below about section 4.1 and need for some text to indicate how these SIDs are managed across multiple nodes and how conflicts/errors (e.g., due to unavailability) are handled. I would expect that this impacts the order in which a controller needs to provision and setup (as also update) the P2MP trees across the nodes - perhaps starting from the leaves and building the tree until the root? -- -- discuss #8: Section 4.5.2 says that a disjoint backup tree instance can be used to provide end-to-end path protection. I assume it means end-to-end tree protection? It is also necessary to clarify how this is done in the constructs introduced in this document. I assume this is done by having a backup CP that has constraints to ensure disjoint-ness with the primary/active CP? If so, please clarify. -- -- discuss #9: The document does cover the provisioning of the SR P2MP Policy construct along with replication segment(s) directly on the root node and of the corresponding replication segments on the intermediate & leaf nodes via CLI/NETCONF/YANG. However, It is also silent on explicit candidate paths. Is it not possible that (what is called as) a controller in this document is simply a provisioning platform that does no path computation but allows an operator to setup static trees? In other words, I find the tight coupling of the concepts of path (or rather tree in this case) computation and provisioning/signaling to the network to be limiting. -- ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please also find below some comments provided inline in the idnits format of the v17 of this document. On all editorial and minor comments, I will leave it to the authors discretion. On the major ones, I would appreciate responses and clarifications. Please look for <EoRv17> at the end of this review and if it is not there, then likely the email has gotten truncated by your client (please refer to the mailing list in that case). 13 Segment Routing Point-to-Multipoint Policy 14 draft-ietf-pim-sr-p2mp-policy-17 <minor-editorial> Please look for all occurences of "policy" and ensure that the term SR P2MP Policy (with consistent capitalization) is used throughout the document. For other uses of the word "policy" the lowercase can be used (e.g., local policy). This will save a lot of time and effort when the RFC Editor processes this document ... from my own experience :-) <minor-editorial> Candidate Path - another term where consistency of use needs to be fixed. I suggest using all lowercase to match RFC9256. There are also other terms like "root node", "leaf node", "replication segment", etc. where consistency in capitalization will help down the line. 16 Abstract 18 Point-to-Multipoint (P2MP) policy enables creation of P2MP trees for 19 efficient multi-point packet delivery in a Segment Routing (SR) 20 domain. A SR P2MP Policy consists of Candidate Paths (CP) which 21 define the topology of P2MP tree instances of the Candidate Paths. A 22 P2MP tree instance is instantiated by a set of Replication segments. <minor> Suggest to drop/skip the last 2 sentences from the abstract. They are imprecise and leaving them out will not take anything from the abstract - only make it better. 109 1. Introduction 111 A Multi-point service delivery can be realized with P2MP (Point-to- 112 Multipoint) trees in a Segment Routing domain [RFC8402]. A P2MP tree 113 spans from a Root node to a set of Leaf nodes via intermediate 114 Replication nodes. It consists of a Replication segment [RFC9524] at 115 the root node, stitched to one or more Replication segments at Leaf 116 nodes and intermediate Replication nodes. A Bud node [RFC9524] is a 117 node that is both a Replication node and a Leaf node. Any mention of 118 "Leaf node(s)" in this document should be considered as referring to 119 "Leaf or Bud node(s)". 121 A Segment Routing P2MP Policy defines the Root and Leaf nodes of a 122 P2MP tree. It has one or more Candidate Paths (CP) with optional 123 constraints and/or optimization objectives. 125 A controller computes P2MP tree instances of a SR P2MP Policy, from 126 the Root to Leaf nodes, of a Candidate Path using the constraints and 127 objectives specified in the Candidate Path. Once computed, the 128 controller instantiates a P2MP tree instance in the SR domain by 129 signaling Replication segments to the Root, Replication and Leaf 130 nodes. A Path Computation Element (PCE) [RFC4655] is one example of 131 such a controller. 133 The Replication segments of a P2MP tree can be instantiated for SR- 134 MPLS [RFC8660] and SRv6 [RFC8986] data planes, enabling efficient 135 packet replication within an SR domain. <minor-editorial> Let me share some suggestions for improving the introduction section for better readability. It could just provide an overview or introduction of the topics/concepts the document is covering and leave the details for the body of the document. Alternately, you could consider providing a high-level information model of the constructs specified in the document (please feel to leverage the text from the DISCUSS portion, if that helps). 137 1.1. Terminology 139 This section defines terms used frequently in this document. Refer 140 to Terminology section of [RFC9524] for definition of Replication 141 segment and other terms associated with it. 143 SR P2MP Policy: A SR P2MP Policy is a mechanism to construct P2MP 144 trees in a SR domain by specifying a Root and Leaf nodes. <minor> SR P2MP Policy is not a mechanism (also goes for other similar terms). It can be called a construct, or a framework or such perhaps? 146 Candidate Path: A Candidate Path of SR P2MP Policy defines 147 topological or resource constraints and optimization objectives that 148 are used to construct P2MP Tree instances. 150 P2MP Tree Instance: A P2MP tree instance in a SR domain is 151 constructed by stitching Replication segments between Root and Leaf 152 nodes of a SR P2MP Policy. A P2MP tree belongs to a Candidate Path 153 and its topology is determined by constraints and optimization 154 objective of the Candidate Path. This document uses terms P2MP tree 155 instance and P2MP tree interchangeably. <minor-editorial> Please consider introducing other terms such as Replication Segment, Tree SID, root/intermediate/leaf nodes, etc. as well in this section. 157 2. SR P2MP Policy 159 An SR P2MP Policy is used to instantiate P2MP trees between a Root 160 and Leaf nodes in an SR domain. It is similar to SR Policy <major> Except for the part that SR P2MP Policy also has multiple CPs just like SR Policy and uses the same tiebreaking for selection of the active CP, I don't see any similarity between the two constructs. My concern is that drawing such equivalency may be more harmful than helpful for a reader that is familiar with SR Policy but new to this document. I feel it is a bad idea to keep comparing/constrasting the two. Also see further comments that are related to this point. 175 * Tree-ID: A 32-bit unsigned integer that uniquely identifies the 176 P2MP Policy in the context of the Root node. This is equivalent 177 to the Color of SR Policy identifier tuple. <major> Since Tree-ID is specified here as a locally unique/significant context on the root node alone, I can't see how it can be equivalent to the Color of SR Policy that identifies the "intent" and is not local to the headend node. See use of Color ExtCom for BGP service routes to perform steering over SR policies across the network. I don't understand why this document should even attempt to do an equivalency between SR Policy and SR P2MP Policy constructs when they are like apples and oranges. 179 Note, SR P2MP Policy identification tuple does not have a member 180 equivalent to Endpoint of SR Policy identifier tuple since SR P2MP 181 Policies result in P2MP trees to a varying set of endpoints (Leaf 182 nodes). <minor> Perhaps "P2MP tree branches to a varying set of endpoints" ? 194 An SR P2MP Policy is provisioned on a controller (see Section 4). 195 The controller computes the P2MP tree instances of Candidate Paths of 196 the policy and instantiates the necessary Replication segments at the 197 Root, Replication and Leaf nodes of the trees. The Root and Tree-ID 198 of the SR P2MP Policy are mapped to Replication-ID element of the 199 Replication segment identifier [RFC9524]. <minor> The above paragraph is not very helpful at this place. These things are described in more detail further in the document. I would suggest to keep these sections where the constructs are described as crisp as possible. 201 2.3. Candidate Paths and P2MP Tree Instances 203 An SR P2MP Policy has one or more CPs. Identification of a CP in 204 context of the P2MP Policy is as specified in Section 2.9 of 205 [RFC9256]. A CP may include topological and/or resource constraints <major> Identification of CP is in section 2.6 of RFC9256 and it would be helpful to list those identifiers in this document as well. Also, are the semantics of those identifiers the same as in RFC9256 - if so, please clarify the same. 206 and optimization objectives which influence the computation of P2MP 207 tree. The Root node selects the active Candidate Path based on the 208 tie breaking rules defined in[RFC9256]. <major> Please clarify that it is based on section 2.9 of RFC9256 210 A Candidate Path has zero or more P2MP tree instances. A P2MP tree 211 instance is identified by an Instance-ID. This is an unsigned 16-bit 212 number which is unique in context of the SR P2MP Policy of the 213 Candidate Path. <major> Here, please try to explain briefly why zero or more than one. It would help the reader to bring forward (or put forward reference) to the points about MBB. 215 The Replication segments used to instantiate a P2MP tree instance are 216 identified by the tuple: <Root, Tree-ID, Instance-ID, Node-ID>, where 217 Root, Tree-ID of SR P2MP Policy and Instance-ID of the instance map 218 to Replication-ID of Replication segment and Node-ID is as defined in 219 [RFC9524]. <major> RFC9525 specifies that replication segments are identified by <replication-id, node-id> and that cannot be changed by this document. What this document does is that it is expanding the replication-id to be <Root, Tree-ID, Instance-ID>. Is my understanding correct? If so, please clarify this very precisely. 225 2.4. Steering traffic into a SR P2MP policy 227 The Tree-SID, as described in Section 3, serves as the data plane 228 identifier of a P2MP tree instance. It is instantiated in the data 229 plane at the Root node, intermediate Replication nodes, and Leaf 230 nodes of the P2MP tree instance. The Tree-SID of the active instance 231 of the active Candidate Path SHOULD be used as the Binding SID of the 232 SR P2MP Policy. <minor-editorial> Please consider inserting a separate section before this one where the Tree SID is specified instead of within this section. Or consider moving this topic in a new top-level section between the current sections 3 and 4 where the Tree SID can be specified along with the steering aspects. 259 3.1. Tree-SID and Replication segments 261 The Replication SID associated with the Replication segment at the 262 Root node is referred to as the Tree-SID. The Tree-SID SHOULD also 263 serve as the Replication-SID for the Replication segments at 264 intermediate Replication nodes and Leaf nodes. However, the <major> Perhaps "It is RECOMMENDED that the Tree-SID is also used as the Replication-SID ..." ? Also, it would be helpful to clarify why this is recommended - e.g., it simplifies debuging/troubleshooting/operations? 265 Replication segments at intermediate Replication nodes and Leaf nodes 266 MAY use Replication-SIDs that differ from the Tree-SID. <major> For SR-MPLS, the same global Tree-SID label can be used at each replication point. However, I would assume that for SRv6 it may be same function that used in all replications points but the locator parts would be specific to each intermediate/leaf nodes? Please clarify. 293 A P2MP tree can associated with one or more multi-point services on 294 the Root and Leaf nodes. In SR-MPLS deployments, if it is known a 295 priori that multi-point services mapped to a SR-MPLS P2MP tree can be 296 uniquely identified within the SR domain, a controller MAY opt not to <minor> perhaps "can be uniquely identified using their service labels"? This is clarified later on, but not clear in that sentence. 297 instantiate Replication segments at Leaf nodes. In such cases, 298 Replication Nodes upstream of the Leaf nodes effectively implement 299 Penultimate-Hop Popping (PHP) behavior by removing the Tree-SID from 300 the packet before forwarding it. A multi-point service context 301 allocated from an upstream assigned label or Domain-wide Common Block 302 (DCB), as specified in [RFC9573], is an example of a globally unique 303 context that facilitates this optimization. 333 4. Using a controller to build a P2MP Tree 335 A controller is provisioned with SR P2MP Policy and its Candidate 336 Paths to compute and instantiate P2MP trees in an SR domain. Once 337 computed, the controller instantiates the Replication segments that 338 compose the P2MP tree in the SR domain nodes using signalling 339 protocols such as PCEP, BGP, NetConf, etc. The procedures for 340 provisioning a controller and the instantiation of Replication 341 segments in an SR domain are outside the scope of this document. <minor> An informative reference to draft-ietf-pce-sr-p2mp-policy would be very helpful. I am not sure why it is necessary to reference BGP here and if just taking PCEP as an example of a signaling protocol would not be sufficient. Note that NETCONF is not a signaling protocol. But of course we need to cover NETCONF/YANG even if there is no reference to provide to a model as yet. 343 4.1. SR P2MP Policy Provisioning on a controller 345 An entity (an operator, a network node or a machine) provisions a SR 346 P2MP Policy on a controller by specifying the addresses of the Root, <minor-editorial> Perhaps "A SR P2MP Policy is provisioned on a controller by specifying ..." ? 347 set of Leaf nodes Candidate Paths. The procedures and mechanisms for 348 provisioning a controller are outside the scope of this document. 350 Candidate Path constraints MAY include link color affinity, 351 bandwidth, disjointness across link, node, or Shared Risk Link Group 352 (SRLG) [RFC4202], delay bound, link loss, flexible algorithm etc., 353 and optimization objectives based on IGP or TE metric or link 354 latency. Other constraints and optimization objectives MAY be used 355 for P2MP tree computation. <major> RFC9256 didn't get into these details as these are anyway out of scope. This document could follow the same approach and perhaps refer to https://datatracker.ietf.org/doc/html/draft-filsfils-spring-sr-policy-considerations-09#section-3 or alternately provide some references for all those TE constructs and not just the SRLG one. See https://www.rfc-editor.org/rfc/rfc9256.html#section-5.2 357 The Tree SID of a P2MP Tree instance of a Candidate Path of a SR P2MP 358 Policy can be either dynamically assigned by the controller or 359 statically assigned by entity provisioning the SR P2MP Policy. <major> This still does not cover how the controller provisioned Tree-SID conflicts (or unavailability) on the routers are handled. At a minimum, the text can say that this could happen and what would be result of such errors? 389 4.4. Instantiating P2MP tree on nodes 391 Once a controller computes a P2MP tree instance for a CP of a SR P2MP 392 Policy, it needs to instantiate the tree on the relevant network 393 nodes via Replication segments. The controller can use various 394 mechanisms to program the Replication segments as described below. 395 Some examples of these mechanisms are PCEP, BGP and NetConf. The <minor> the above sentence is repeated from section 4 401 4.5.1. Local Protection 403 A network link, node or path on the instance of a P2MP tree can be 404 protected using SR policies computed by a controller. The backup SR 405 policies are programmed in data plane in order to minimize traffic 406 loss when the protected link/node fails. <major> Please clarify and specify in detail how this works. I am assuming the SR Policy will be somehow fixed up into one of the replication branches? Are there any considerations on the encapsulation? 408 It is also possible to use node local Loop-Free Alternate [RFC5286] 409 protection and Micro-Loop [RFC5715] prevention mechanisms to protect 410 link/nodes of P2MP tree. <minor> Since either LSM or unicast SRv6 SID address are used, wouldn't TI-LFA and microloop avoidance be available for the traffic while traversing between intermediate/leaf nodes? 429 An SR domain needs protection from outside attackers as described in 430 [RFC8754]. <major> Did you mean SRv6 domain? or else the reference should be to RFC8402 to cover both SR-MPLS and SRv6. 432 Failure to protect the SR MPLS domain by correctly provisioning MPLS 433 support per interface permits attackers from outside the domain to 434 send packets to receivers of the Multi-point services that use the SR 435 P2MP trees provisioned within the domain. 437 Failure to protect the SRv6 domain with inbound Infrastructure Access 438 Control Lists (IACLs) on external interfaces, combined with failure 439 to implement BCP 38 [RFC2827] or apply IACLs on nodes provisioning 440 SIDs, permits attackers from outside the SR domain to send packets to 441 the receivers of Multi-point services that use the SR P2MP trees 442 provisioned within the domain. <major> References to RFC8754 and its security consideration is required here. Perhaps also to the security considerations or RFC8986? <EoRv17> _______________________________________________ pim mailing list -- [email protected] To unsubscribe send an email to [email protected]