[pim] Re: Mike Bishop's No Objection on draft-ietf-pim-sr- p2mp-policy-17: (with COMMENT)

Mike,
Responses inline.

Thanks for the review,
Rishabh.

On Mon, Aug 18, 2025 at 2:08 PM Mike Bishop via Datatracker <
[email protected]> wrote:

> Mike Bishop has entered the following ballot position for
> draft-ietf-pim-sr-p2mp-policy-17: No Objection
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> In both the abstract and the introduction, it is unclear whether P2MP was
> an
> existing concept that this document built on, or a new concept being
> defined by
> this document. The first paragraph reads as if it's providing the necessary
> context for what this document does, but then the second paragraph states
> that
> it defines... much of the stuff that was just said? Consider moving "This
> document specifies..." earlier in the abstract or adjusting scope to make
> it
> clear which elements already exist. For example, "RFC 9524 defines a
> mechanism
> for one Segment Routing node to distribute traffic to multiple other nodes,
> called a Replication segment. Using multiple layers of Replication
> segments can
> enable [better scale, etc.], but requires centralized coordination of these
> Replication segments. This document defines a mechanism to perform this
> coordination and distribute the resulting configuration." Similarly, the
> introduction would benefit from an explanation of the current state of
> things,
> in what situations that state is suboptimal, and how this new element
> improves
> the situation.
>

[RP] P2MP is a widely used term both in literature and in the industry. I
have reworded both the abstract and introduction per your suggestion.


> Thank you for expanding CP into Candidate Path on its first use. Also
> consider
> mentioning the abbreviation at the definition of Candidate Path in the
> Terminology section.
>

[RP] Done.


> The document is inconsistent about whether it's "a" SR Policy (if SR is
> pronounced "segment routing") or "an" SR Policy (if SR is pronounced "ess
> arr"). They're about evenly split right now -- please pick one. (For what
> it's
> worth, RFC9524 uses "an" throughout.)
>

[RP] I have made it consistent by using "an/An" before "SR" as done in RFC
9524.


> In Section 3.2, I'm unclear what "a shared Replication segment MUST NOT be
> associated with an SR P2MP tree" means. Can you expand on this? It seems
> natural that a node might need to see whether a given Replication segment
> is
> being used by any trees at the moment, and it's unclear why tracking that
> information would be explicitly prohibited.
>

[RP] Since a Replication segment is "shared" across different P2MP tree
instances, it cannot be associated with any one SR P2MP tree instance. But
you are correct that "MUST NOT" is excessively prohibitive. I have changed
the text to state that a shared RS is not associated with any
particular P2MP tree.

>
> You probably need a definition for "Penultimate-Hop Popping behavior,"
> either
> in this document or by reference. Alternatively, don't make it a
> Capitalized
> Term and just say something like "Replication Nodes upstream of the Leaf
> nodes
> can remove the Tree-SID from the packet before forwarding, avoiding the
> need to
> configure the Leaf nodes to [whatever]."
>

[RP] Done.


>
> In Section 3.4, isn't this the process at *each* node, not just the Root?
>
>
[RP] The bullets describe the forwarding action at  "each" intermediate
Replication node, or a terminating Leaf node.


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