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

Ketan,
I am going to publish version 20 to clarify some of the below discuss
points. Responses inline @ [RP]

Thanks,
Rishabh.

On Mon, Aug 25, 2025 at 1:18 AM Ketan Talaulikar via Datatracker <
[email protected]> wrote:

> Ketan Talaulikar has entered the following ballot position for
> draft-ietf-pim-sr-p2mp-policy-19: Discuss
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks to the authors and the WG for your work on this document.
>
> This is an updated ballot for the v19 posted by the authors. Note that the
> numbering of open points in the DISCUSS position is being retained as in
> the
> original ballot for ease of tracking.
>
> While the proposal is quite straightforward, it took me a few passes to
> grasp
> the the information model of the different constructs introduced in this
> document
>  and their interrelationship. Perhaps it is because I am comparing it with
> RFC9256 that specified the constructs for SR Policy.
>
> I will attempt to describe the model based on my reading of the document,
> and
> would appreciate if the authors can correct/clarify any errors in my
> understanding. Please note some discussions points that I've brought up as
> part
> of this description so as to provide a better context.
>
> An SR P2MP Policy is a construct that represents a (set of?) P2MP trees in
> a
> SR domain that can be used for delivery of P2MP service (i.e., multicast
> traffic). Each SR P2MP Policy is identified by <Root, Tree-ID>.
>
> An SR P2MP Policy can have one or more CPs where each provides constraints
> and
> optimization objective for the computation of a specific tree topology
> from root
> to leaves.
>
> Each CP is identified by <Protocol Origin, Originator, Discriminator>
> which is
> same as in the case of a SR Policy CP. Please see my comment on making this
> explicit.
>
> Each CP that is valid (i.e., for which a tree can be computed) has at least
> one P2MP tree instance associated with it. There can be more than one
> instance
> in cases like make-before-break (MBB). Within a SR P2MP Policy, each P2MP
> tree
> instance is identified by an Instance-ID.
>
> At any point, only one CP is active and this is selected based on the same
> tie-breaking logic as for SR Policy CPs.
>
> All the constructs until this point are instantiated only on the root node
> (not considering the controller for now).
>
> 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?
>
> This remains open for discussion
> --
>
> 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.
>
> This remains open for discussion
> --
>
> 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?
>
> In the updated version, can this text now be removed from section 1.1?
> "This document uses terms P2MP tree instance and P2MP tree
> interchangeably."
> --
>

[RP] Removed this sentence.


>
> 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 #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?
>
> Note: In the updated text, the part of the BSID (which is constant),
> getting
> swapped with the currently active Tree SID (which may be changing) is not
> covered even though that was one of the points that came out during the
> discussion on this topic. Wanted to cross-check that it was left out
> intentionally. --
>

[RP] No, it was not left out intentionally. I thought other text about
forwarding would make this obvious. Anyway, I have added text explaining
this explicitly.



>
> --
> 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?
>
> This is largely addressed in the updated text. However, the following text
> in
> section 5.5 seems odd - did you mean "reporting this success"?
>
> "A node SHOULD report a successful installation of a Replication segment.
> The exact procedure for reporting this failure is outside the scope of this
> document."
> --
>
> [RP] It was a copy and paste typo :) Fixed.

>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks to the authors for addressing all the comments in v19
>
>
>
> _______________________________________________
> 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]