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

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]