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

Ketan,
Thanks for your diligent review. It certainly improved the document. I will
post the ver 21 update.

Rishabh.

On Thu, Sep 4, 2025 at 10:00 PM Ketan Talaulikar <[email protected]>
wrote:

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