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

Yes, I will check with Hooman.

Rishabh.

On Wed, Sep 3, 2025 at 11:26 PM Ketan Talaulikar <[email protected]>
wrote:

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