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

Hi Rishabh,

Thanks for pushing the update. It addresses the majority of the points in
my previous DISCUSS position and all of the comments.

I'll post an updated ballot shortly where 2 discussion points remain open
for a call (to be scheduled by me). For the rest of the discussion points,
I am only looking for some clarification/confirmation. If you would like to
push another update for them, please feel free to do so.

Thanks,
Ketan


On Sat, Aug 23, 2025 at 5:34 AM Rishabh Parekh <[email protected]> wrote:

> Ketan,
> I have published version 19 addressing most of your discussions and
> comments.As you suggest, let's hash out a few remaining ones in a call next
> week.
>
> Please take a look at version 19,
> Rishabh.
>
> On Fri, Aug 22, 2025 at 5:01 AM Ketan Talaulikar <[email protected]>
> wrote:
>
>> Hi Rishabh,
>>
>> Thanks for the continued discussion. Please check inline for follow-ups
>> with KT2.
>>
>> At this point, I think it would be great if you (and your co-authors)
>> could post an update with the changes discussed and agreed so far. This way
>> we can focus on the outstanding points alone. I am asking the same for the
>> base SR P2MP Policy Ping document as well - this way can ensure that both
>> are in sync and consistent.
>>
>> Note: My responses may be slow next week.
>>
>>
>> On Fri, Aug 22, 2025 at 4:37 AM Rishabh Parekh <[email protected]>
>> wrote:
>>
>>> Ketan,
>>> Responses @ [RP2]
>>>
>>> On Thu, Aug 21, 2025 at 3:29 AM Ketan Talaulikar <[email protected]>
>>> wrote:
>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>> 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 ...
>>>>
>>>
>>> [RP2] If we want to distinguish between provisioning and instantiation,
>>> then either can be on the Root and controller. For example, in the
>>> MVPN/EVPN use case a SR P2MP policy and a CP can be thought of as being
>>> "provisioned" on the Root node (via MVPN/EVPN auto-discovery procedures)
>>> and these are then instantiated on the controller via signalling. In
>>> another use case, an entity can provision a SR P2MP policy and a CP on the
>>> controller and these are then instantiated on the Root node via signalling.
>>> So provisioning and instantiation can happen on either Root node or
>>> controller. How about this slight modification to your proposed text:
>>>
>>> "An SR P2MP Policy and its candidate paths are provisioned on either the
>>> controller or the Root node or both depending upon the provisioning model
>>> (see Section 4). After provisioning, they are instantiated on the Root node
>>> or the controller by the signalling protocol."
>>>
>>
>> KT2> This works for me. Thanks.
>>
>>
>>>
>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> 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)?
>>>>
>>>>
>>> [RP2] I see. One can interpret "variable-length" field to mean that a
>>> "length" field has to be present for the Replication-ID in the model or
>>> signalling protocol , but this is imprecise.
>>>
>>
>> KT2> Exactly. Let us perhaps discuss this over a call as it will be
>> easier. Next week may be tough for me, but I will try to suggest a common
>> slot for both the SR P2MP documents.
>>
>>
>>>
>>>
>>>>> 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>.
>>>>
>>>>
>>>>
>>>  [RP2] This is fine.
>>>
>>>
>>>>>> 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.
>>>>
>>>
>>> [RP2]
>>>
>>> Note that the shared sub-tree in the above example is not the same as
>>> the "P2MP tree instance" construct defined in this document.  That is why
>>> it is a *shared Replication segment* and not a shared P2MP tree. A
>>> replication segment is just the Replication node and its downstream nodes.
>>> In this example, B-C-D are adjacent, but if they are not, the shared
>>> Replication segment will be ingress replication from B to C and D, not an
>>> optimized replication on a tree. The Replication segment may be shared
>>> across P2MP tree instances originating at different Root addresses and
>>> hence the Root address is 0.
>>>
>>> Anyway, the section on shared Replication segment is in the text because
>>> one of the vendors on the draft uses this only as a facility backup not for
>>> the generalized use case above. If it is fine with you, I can change text
>>> in this section to make it clear that this is the only use case supported
>>> in the document and keep other use cases out of scope.
>>>
>>
>> KT2> This also seems like a topic to discuss over a call?
>>
>>
>>>
>>>
>>>>
>>>>>
>>>>>
>>>>>> 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.
>>>>
>>>
>>> [RP2] I discussed this with the authors of the ping draft and that
>>> document uses "TI" as an abbreviation of P2MP tree instance. I can add this
>>> abbreviation to the definition of P2MP tree instance in the Terminology
>>> section of the draft.
>>>
>>
>> KT2> I leave it between the authors of both the drafts - whatever
>> terminology that you arrive at, please define it in this base document and
>> then use it in the ping (as also perhaps the PCEP?) document.
>>
>>
>>>
>>>
>>>>
>>>>>
>>>>>> 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?
>>>>
>>>
>>> [RP2] The Tree-SID is the data plane identifier of a P2MP tree instance.
>>> P2MP tree instances are likely to have different tree topologies due to
>>> different constraints/objectives of CPs in an SR P2MP policy and across
>>> different policies. Even in one CP with given constraints/objectives, two
>>> P2MP tree instances for MBB will have different tree topologies due to
>>> differing network topology (between the "old" instance and "new" instance
>>> after network change).  Since the P2MP tree instances differ in their tree
>>> topology, their replication state is also likely to be different at core
>>> nodes (i.e. a non-Root node) in the SR domain. Therefore each P2MP tree
>>> instance has its own Replication segment with associated Replication-SID
>>> (Tree-SID).
>>>
>>> I can see how BSID can cause confusion about this. BSID is an identifier
>>> of SR P2MP Policy to steer traffic into it. It is only used when the Root
>>> of SR P2MP Policy is NOT the ingress node on which traffic arrives to the
>>> SR domain. To draw analogy with SR Policy, incoming packet with BSID of SR
>>> Policy is steered with segment list of the active CP. For SR P2MP Policy,
>>> the packet is steered with Tree-SID of the active instance of the active
>>> CP. In this way, BSID for SR P2MP Policy is similar to BSID of SR Policy as
>>> specified in Section 6 for RFC 9256.
>>>
>>> When the Root node of SR P2MP Policy is also the ingress node at which
>>> traffic arrives to the SR domain, it is steered into the SR P2MP Policy by
>>> local policy on the Root, not the BSID.
>>>
>>
>> KT2> Please see how you can capture this in the document and we can
>> follow-up over a call after the update is posted?
>>
>>
>>>
>>> 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.
>>>>
>>>>
>>>
>>> [RP2] Yes, the Tree-SID can change, but only if there are multiple CPs
>>> or MBB is used. Though it is outside the scope of this draft, I assume most
>>> implementations would provide information about the traffic that is steered
>>> into a  SR P2MP Policy and the current active Tree-SID of that policy.
>>>
>>
>> KT2> Would be great to capture this in the text. Some of these are
>> important operational aspects and having things specified here would help
>> operators in achieving consistency across vendors.
>>
>>
>>>
>>>
>>>>>
>>>>>> 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.
>>>>
>>>
>>> [RP2] I will add explanatory text.
>>>
>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>> --
>>>>>> 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
>>>>
>>>
>>> [RP2] Ok will add some text about SID management and handling of
>>> conflicts/errors.
>>>
>>
>>>
>>>>
>>>>
>>>>> --
>>>>>> 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).
>>>>
>>>
>>> [RP2] Will do.
>>>
>>
>>>
>>>>
>>>>
>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>> 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?
>>>>
>>>
>>> [RP2] I agree.
>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> 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.
>>>>
>>>
>>> [RP2] I will remove the text.
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> 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
>>>>
>>>
>>> [RP2] Corrected the Section number.
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> 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.
>>>>
>>>>
>>>  [RP2] BGP signalling is specified in draft-ietf-idr-sr-p2mp-policy-00
>>> and YANG model is specified in draft-hb-spring-sr-p2mp-policy-yang-02.
>>> However, I am not sure if these documents cover recent revisions of this
>>> document, especially the YANG draft which expired back in 2021. I can add
>>> informative references to both.
>>>
>>>>
>>>>>
>>>>>>
>>>>>> 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.
>>>>
>>>
>>> [RP2] It is going to be an informative reference since this section is
>>> not a formal specification of the controller behavior.
>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> 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.
>>>>
>>>
>>> [RP2] I realized that almost all of the text in this section is covered
>>> in the first paragraph of Section 4. I will remove text in that paragraph
>>> and retain this subsection.
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> 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?
>>>>
>>>
>>> [RP2] Will do.
>>>
>>>>
>>>>
>>>>>
>>>>>> 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.
>>>>
>>>>
>>> [RP2] Can you suggest a good reference to SR TI-LFA and uLoop
>>> document(s) in addition to RFC 5286 and 5715 which are already referred to
>>> here?
>>>
>>
>> KT2>
>> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-segment-routing-ti-lfa/
>> and
>> https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-segment-routing-uloop/
>> ... the later is an individual document but should be still ok as an
>> informative reference alongside the two existing ones.
>>
>> Thanks,
>> Ketan
>>
>>
>>>
>>>
>>>>>
>>>>>>
>>>>>> 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]