[pim] Re: Ketan Talaulikar's Discuss on draft-ietf-pim-sr- p2mp-policy-18: (with DISCUSS and COMMENT)
Rishabh Parekh <[email protected]>
| Newsgroups | gmane.ietf.pim |
|---|---|
| Message-ID | <CABjMoXZppOhHsHTr8qPA9mm+udcQ+VpyHVjjZmaGMJ7Wawf+mg@mail.gmail.com> |
Ketan, Thanks for a thorough review. Responses inline. Rishabh. On Wed, Aug 20, 2025 at 12:00 AM Ketan Talaulikar via Datatracker < [email protected]> wrote: > Ketan Talaulikar has entered the following ballot position for > draft-ietf-pim-sr-p2mp-policy-18: Discuss > > > ---------------------------------------------------------------------- > 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? > [RP] Yes, unfortunately Tree-ID is a historical artifact from the very early versions of the document. "P2MP-ID" or something else might be more appropriate, but I think it is too late to change this since dependent documents in BESS and PCE WGs use this term. > > 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. > [RP] Instance-ID is unique in the context of SR P2MP Policy, not its parent CP. This is because Root, Tree-ID and Instance-ID are in the identifiers of Replication segments (and the signalling protocols), whereas CP ID is not. > 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. > [RP] SR P2MP Policy and CPs are only instantiated on the Root, but tree instances are instantiated at Root, intermediate and Leaf nodes. > > -- > 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. " > -- > [RP] You are correct. SR P2MP Policy, and CPs are instantiated on Root node and controller (and also signalled). Is the following modification acceptable? "An SR P2MP Policy and its Candidate Paths are provisioned on a controller and the Root node. These are signalled from the controller to the Root node and vice versa. The controller computes the P2MP tree instances of Candidate Paths of the policy and instantiates ....." > > 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? > -- > [RP] From the comments on Section 2.2, I agree the text about <Root, Tree-ID> mapping to Replication-id in Section 2.2 is not required because Section 2.3 specified the Replication ID maps to <Root, Tree-ID, Instance-ID>. I am going to remove this from Section 2.2. I am going to address your major comment on Section 2.3 here since it is relevant to this discussion. I am not sure what you mean by "update RFC 9524", but Section 2 of that RFC explicitly allows Replication-ID to be extended and modified precisely for this (and future) cases (see excerpt below). "Replication-ID is a variable-length field. In the simplest case, it can be a 32-bit number, but it can be extended or modified as required based on the specific use of a Replication segment. This is out of scope for this document." Below is a proposed change for the text in Section 2.3 to make it clear the replication-id is "modified" to be <Root, Tree-ID, Instance-ID>". Please let me know if it addresses this discussion and the related comments. P2MP tree instances are instantiated using Replication segments. The Replication-ID field of a Replication segment identifier can be modified as per Section 2 of [RFC9524]. This document modifies the Replication-ID of a Replication segment as follows. The Replication segments used to instantiate a P2MP tree instance are identified by the tuple: <Root, Tree-ID, Instance-ID, Node-ID>, where Root, Tree-ID of SR P2MP Policy and Instance-ID of the instance map to Replication- ID of Replication segment and Node-ID is as defined in [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. > -- > [RP] If multiple tree instances share the same sub-topology then a single shared Replication segment can be instantiated in the sub-topology to be shared across all the instances. For traffic forwarding, Replication node of the shared Replication segment "pushes" its Replication SID on top of the incoming P2MP tree instance SID and the packet is replicated to the downstream nodes of the shared Replication segment where the shared Replication SID is "popped" and the packet is forwarded on the inner P2MP tree instance replication SID. A Shared Replication segment can also be used for local protection backup across P2MP. tree instances. A │ B C─┴─ D │ │ E F In above topology, say two P2MP tree instances span from Root A to Leaf nodes E and F. They share same sub-topology from node B to downstream nodes C and D, In this case, a single shared Replication segment can be instantiated on B, C and D and shared cross the two P2MP tree instances. > 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? > -- > [RP] The idea was to distinguish between the P2MP tree as a concept and the P2MP tree instance construct defined in this document. I have revised the text in the document to make this distinction clear in the context of the text. > > 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. > -- > [RP] The Tree-SID is unique for each P2MP tree instance in the SR domain. If CP has more than one P2MP tree instance, each instance has its own Tree-SID. P2MP tree instances for more than one CP of a SR P2MP Polcy may be computed and instantiated at same time. All these P2MP tree instances for the CPs for SR P2MP Policies have a unique Tree-SID. This holds even if same Tree-SID is not used for all the Replication segments of the P2MP tree instance i.e. Replication SIDs of the Replication segments are different at the nodes of a P2MP tree instance. Basically, since Replication-SID is a unique forwarding identifier for a Replication segment of a P2MP tree instance, all P2MP tree instances on a node have unique SID values. If the above is not clear in the document, I can add some text to Section 3.1. > 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? > -- > [RP] Binding SID is for a specific use-case where Root of SR P2MP Policy is not the ingress node of the SR domain. The ingress node steers traffic to be replicated using a Segment List where the last segment is the Binding SID of SR P2MP Policy. The Binding SID is swapped with Tree-SID of the active instance of active CP and the packet is replicated. If the Tree-SID is used as the Binding SID of the policy, the Binding SID will change when active instance or active CP changes, and the segment list used to steer packets from the Ingress node to the Root node will have to be changed too. > -- > 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? > -- > > [RP] We did not intend Section 4 to be a formal specification of controller behavior, but as a general guideline for supporting SR P2MP Policies with some MUST and SHOULD behaviors. That said, I can add some guiding text for SID management. > -- > 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. > -- > > [RP] Correct. I will add text about how this disjoint tree instance can be instantiated. > -- > 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. > -- > > [RP] This document is meant for a controller to compute and maintain P2MP tree instances for SR P2MP Policies. Explicit CP with statically defined tree topology is certainly feasible, but IMO impractical. These explicit CPs can also be provisioned on the Root node or on the controller (which skips the computation and just instantiates the Replication segments for the explicit tree topology). I can certainly add text about these possibilities but keep it out of the scope of this document. > > ---------------------------------------------------------------------- > 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 :-) > [RP] We have tried to be consistent but I will go through the text again. I wholeheartedly agree on this easing the RFC editor comments :) > > <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. > [RP] Understood. We have tried to be consistent with the terms Root, Leaf and Replication segment, but I will recheck. I will change Candidate Path(s) to lowercase to match RFC 9526. > > 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. > [RP] The modified Abstract text in version 18 already addresses this comment. > > 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. > > [RP] The first paragraph of the Terminology section points to the Terminology section RFC 9524 for Replication segment and other related terms. I will add the Tree-SID definition. > 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. > [RP] I am beginning to agree. This has also led other reviewers to compare SR Policy and SR P2MP Policy identifiers and then make suggestions about adding text to describe the equivalency of the fields. I see you have comments below about that. If it helps, I can try to remove text drawing similarities between the two and just retain or add text about CPs and tie breaking rules. > > > 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. > [RP] As I mentioned above, this similarity was introduced based on comments of another reviewer who wanted to make the differences and similarities between SR P2MP Policy and SR Policy clear. However, if we agree to remove text regarding similarity, we can clean up this and other text about similarity. > > > 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" ? > [RP] I can make the suggested change, or remove this altogether as discussed above. > > 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. > [RP] In response to your discuss #1, I have modified text to clarify that SR P2MP policy and its CPs are provisioned on the controller and the Root node and signalled between the two. I have removed the last two sentences. > > 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. > [RP] The semantics are the same. I have modified the text to include the CP identifier tuple elements and their semantics referring to RFC 9256. > > 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 > [RP] Done. > > 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. > [RP] Done. > > 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. > [RP] See my response to discuss #2. > > 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. > [RP] I have done the latter i.e. created a new top level section and moved text of current Section 3.1 defining the Tree-SID into this new section. > > > 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? > [RP] Done. > > 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. > [RP] Yes, for SRv6 the locator would be specific to each intermediate and leaf node. > > > 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. > > [RP] Done. > > 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. > [RP] I can add a reference to the PCEP draft. BGP and YANG drafts exist, but both are expired as of now :( > > 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 [RP] I will modify the text to refer to SR Policy considerations draft as RFC 9526 does, though it has expired, > > > 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? > > [RP] See comments for discuss #7 > 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 > [RP] Removed this section > > 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? > [RP] Yes, the SR Policy for backup will be associated with a replication branch of Replication segment. The segment list of backup SR policy will be imposed on the downstream Replication SID when the backup SR policy is used. > > 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? > [RP[ Yes, though uLoop is really applicable when the replication node and its downstream node are not adjacent > > 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. > > [RP]. Yes, this is in general for SR. So it should refer to RFC 8402, RFC 8754 and RFC 8986 > 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? > [RP] See previous response. > > <EoRv17> > > > > _______________________________________________ > pim mailing list -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ pim mailing list -- [email protected] To unsubscribe send an email to [email protected]