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

Hi Rishabh,

This looks great. I'll clear my DISCUSS position once the update is posted.

Thanks again for your (and your co-authors) patience through these
discussions. I hope it has helped improve the document.

Thanks,
Ketan


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

> Ketan,
> After discussion with Hooman, I have added some text about TTL and IPv6
> Hop Limit. Please check the changes in Section 3 and 4.3 of the attached
> document and diff.
>
> Rishabh.
>
> On Wed, Sep 3, 2025 at 11:42 PM Rishabh Parekh <[email protected]> wrote:
>
>> 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]