[pim] Re: Ketan Talaulikar's Discuss on draft-ietf-pim-sr- p2mp-policy-18: (with DISCUSS and COMMENT)

Hi Rishabh,

Thanks for your quick response. Please check inline below for
clarifications and some follow-ups.

For the ones that I haven't replied to your comments, I am good and will
await the updated version.


On Thu, Aug 21, 2025 at 9:56 AM Rishabh Parekh <[email protected]> wrote:

> 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.
>

KT> I figured. Let it be so.


>
>> 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.
>

KT> Yes, I missed to correct that in my description between my multiple
passes over the document :-)


>
>
>> 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.
>

KT> Thanks for confirming. It would be very helpful if this were clarified
in the text. Especially the part about the SR P2MP Policy and its CPs being
instantiated on the root - please also see the next response.


>
>
>>
>> --
>> 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 ....."
>

KT> I will try to be careful with the terminologies. I prefer use of the
term instantiation since it is separate from provisioning (seen as a sort
of management action) and signaling (something done using a routing
protocol). How about:

An SR P2MP Policy and its Candidate Paths are instantiated on the Root
node. Their provisioning may be done on either the controller or the Root
node or both depending on the provisioning model and choice of signaling
protocol (see Section 4) . The controller computes ...


>
>
>>
>> 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."
>

KT> Let's keep aside the "updates" part for now. How does one know the
encoding of the replication-id ? There is no "replication id type" defined
in RFC9524 that allows for different encoding schemes for the
replication-id. How would this get modeled in a YANG module or a protocol
encoding that is supporting generic reporting/signaling of replication
segments (i.e., not in the context of these SR P2MP trees specifically)?


>
> 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].
>
>
>
KT> How about:

   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 to be the tuple:
   <Root, Tree-ID, Instance-ID>, where <Root, Tree-ID> identifies the
   SR P2MP Policy and Instance-ID identifies the P2MP tree instance
   within that SR P2MP Policy. This results in the Replication
   segments used to instantiate a P2MP tree instance being identified by
   the tuple: <Root, Tree-ID, Instance-ID, Node-ID>.



>
>> 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.
>

KT> Thanks for the explanation. I get the idea now. However, this isn't
specified in that manner in the document. Further, I find the construct of
setting the root to 0 for shared replication segments to be a bit strange.
As you mention, this is a tree that is shared and used as a sub-tree along
the path by more than one P2MP tree. Doesn't that make that shared tree
also a P2MP tree except that it is not associated with a SR P2MP Policy? I
am wondering how these shared replication segments will be identified in
the network and their provisioning, OAM, etc. will work. In short, I feel
this needs more details to be specified.


>
>
>> 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.
>

KT> Ok. Thanks. I did get a sense that they were not identical. Please also
discuss this with the authors of the accompanying ping document since that
uses "TI" (which should have been defined in this document) quite
extensively.


>
>> 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.
>

KT> This seems to be at odds with the text (or my reading of it). Perhaps
I've gotten confused due to the reference to BSID. Let's take a SR P2MP
Policy with a single CP and it has a single P2MP Tree under it. Now, the
tree needs to be recomputed and for MBB another P2MP Tree is instantiated
under that CP. You are saying that this new tree would have its own unique
Tree-SID.  From the BSID reference, I got the impression that Tree SID is
more like the property of the SR P2MP Policy CP and that each CP in the SR
P2MP Policy has its own unique Tree SID or it can be shared by CPs since
only one CP is actively forwarding traffic at any point. So Tree-SID would
then be a stable dataplane construct/reference. But it seems like that is
not the case? The Tree SID being used by the SR P2MP Policy will keep
changing every time the P2MP Tree needs to be recomputed (for MBB). Doesn't
that make it hard for an operator to keep track of the Tree SID being used?
If it is from SRGB or SRLB, then it might make things challenging to keep
track of? In any case, I think some text is needed for clarity but I am not
sure if it should be only in section 3.1 - please see the term Tree SID
being used before then as well.


>
>
>> 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.
>

KT> This is related to the previous comment. Please add text that defines
what the BSID of a SR P2MP Policy is and how it is used. Basically, the
explanation above. The following text that exists currently does not align
with your explanation (which makes sense to me) above:

The Tree-SID of the active instance of the active Candidate Path SHOULD be
used as the Binding SID of the 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?
>> --
>>
>> [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.
>

KT> There are two parts here. The first is about the SIDs - since this
document introduces Tree SID and talks about BSID and Replication SID,
there should be some text that describes where those are allocated from
(especially for MPLS). Then perhaps some operational recommendation on
which one of SRGB, SRLB, or dynamic is better suited (please see one of my
previous responses for the implications). That then leads to the 2nd part
about errors and conflicts. That 2nd part is not really a controller
behavior specification but the router specification where these SIDs (e.g.,
labels) are allocated and programmed. As an example, please check the text
related to BSID unavailability and allocation failures in
https://www.rfc-editor.org/rfc/rfc9256.html#section-6


> --
>> 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.
>

KT> Thank you.


> --
>> 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.
>

KT> Thanks, some text to cover this would be good. As well, some
recommendations on the challenges when using explicit CPs that you indicate
(I agree there are challenges).


>
>> ----------------------------------------------------------------------
>> 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.
>

KT> Yes, it does. Thanks.


>
>
>>
>> 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.
>

KT> I think the document will be greatly simplified if those comparisons
were removed. It is OK to point to RFC9256 for using the CP identifiers or
leveraging the tiebreaking (if they both make sense), but I don't think
there are commonalities beyond that?


>
>>
>> 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.
>

KT> The trick is don't even mention SR Policy or mention anything to
compare/contrast the two. Even if there is one such instance, then it is
natural for a reader to start making comparisons along the way in their
minds for more things and begin looking for texts about it :-)


>
>>
>> 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.
>

KT> I will leave it to you.


>
>
>>
>> 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.
>

KT> Sure, let me await the text.


>
>> 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.
>

KT> Thanks. Please also correct the section reference from 2.9 to 2.6 of
RFC9256


>
>
>>
>> 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.
>

KT> Great. I will look for that text.


>
>>
>> 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.
>

KT> Thanks. I hope you can clarify this distinction for MPLS and SRv6.


>
>
>>
>>
>> 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 :(
>

KT> I was inspired by the following text in the abstract of the companion
ping draft. I quite liked it. It gives an example of a signaling protocol
(just add reference in this document) and it covers the management API as
well (if you have an individual YANG draft would it still be good to
reference it?).

These policies are typically calculated via a controller-based mechanism
and installed via, e.g., a Path Computation Element (PCE). In other cases
these policies can be installed via using NETCONF/YANG or CLI.


>
>
>>
>> 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,
>

KT> That individual informational draft was not adopted/progressed by
SPRING WG since it was believed that all this was well known. So, I guess
it should be ok to reference it informatively. But if the intention is
normative then please don't reference that draft and either find another
suitable RFC or provide references.


>
>>
>> 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
>

KT> OK. Will wait for the update since I was only referencing the last
sentence and not the 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.
>

KT> Make sense. Can you please include these details in the document?


>
>> 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
>

KT> Correct for link down, but for link-up it may apply even for
non-adjacent. But I am digressing. If you agree and believe it is helpful
then you can informatively refer to TI-LFA and SR Microloop avoidance since
this is deployed in SR networks.


>
>
>>
>> 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
>

KT> Ack


>
>
>> 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.
>

KT> Ack

Thanks,
Ketan


>
>
>>
>> <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]