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

Hi Rishabh,

The update looks good to me and it addresses the 2 remaining discussion
points.

However, before you post the update, can you please discuss with Hooman
(and co-authors of the ping document) about covering aspects related to
propagation of TTL for SR-MPLS and Hop Limit for SRv6 in the base SR P2MP
Policy document instead of in the ping document?

Please check
https://mailarchive.ietf.org/arch/msg/pim/O6jzvF2v6RMt4VCPfubexgdeTxQ/ for
details.

Thanks,
Ketan


On Thu, Sep 4, 2025 at 11:37 AM Rishabh Parekh <[email protected]> wrote:

> Ketan,
> As discussed in today's meeting, I have addressed the two remaining
> DISCUSS points with changes we agreed on.
>
> I am attaching the proposed update (ver 21) along with diff. Please
> review these to confirm if it indeed addresses the DISCISS points.
>
> Thanks,
> Rishabh
>
> On Thu, Aug 28, 2025 at 11:36 PM Ketan Talaulikar via Datatracker <
> [email protected]> wrote:
>
>> Ketan Talaulikar has entered the following ballot position for
>> draft-ietf-pim-sr-p2mp-policy-20: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to
>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> Thanks to the authors and the WG for your work on this document.
>>
>> This is an updated ballot for the v20 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.
>>
>> 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.
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Thanks to the authors for addressing all the comments raised.
>>
>>
>>
>> _______________________________________________
>> 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]