[pim] Re: draft-ietf-pim-sr-p2mp-policy-13 ietf last call Ts vart review

David,
The intent was to convey the idea that SR Policy and SR P2MP Policy are
related because they are used to realize traffic engineering in a Segment
Routing domain, former for Point-to-Point paths and latter for P2MP trees.
Both use the same constructs such as Candidate Paths, and same criteria for
selecting the Active Candidate Path. In terms of identification, The "Root"
of SR P2MP policy is equivalent to "Headend" of SR Policy. "Color" in SR
Policy is an unsigned 32-bit number which uniquely identifies policy on a
Headend and so is "Tree-ID" of SR P2MP Policy and it serves the same
purpose. "Endpoint" does not apply to SR P2MP policies because it is
intended to build trees with varying set of endpoints (Leaf nodes).

That said, SR Policy and SR P2MP Policies are independent elements and have
to be treated as distinct from each other if they are deployed in a SR
domain. If you feel use of "specialized form" implies a stronger
relationship between the two then intended, we can re-word the language in
the document to clarify this. The best relationship I can think of is
"similar". If you agree, I will make this change in next revision of the
document.

Thanks,
Rishabh.



On Fri, Jul 25, 2025 at 2:55 PM David Black via Datatracker <
[email protected]> wrote:

> Document: draft-ietf-pim-sr-p2mp-policy
> Title: Segment Routing Point-to-Multipoint Policy
> Reviewer: David Black
> Review result: Ready with Issues
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the
> document's
> authors and WG to allow them to address any issues raised and also to the
> IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> [email protected] if you reply to or forward this review.
>
> As a routing policy draft, this draft does not raise any transport-oriented
> issues, but I did notice one discrepancy that ought to be addressed.
>
> - Section 2 says: "An SR P2MP policy is a specialized form of an SR policy
> as
> defined in[RFC9256] ..." - Section 2.1 says: "A SR P2MP Policy is uniquely
> identified by the tuple <Root, Tree-ID>, where: ..." - RFC 9256 Section 2.1
> says: "An SR Policy MUST be identified through the tuple <Headend, Color,
> Endpoint>."
>
> I don't understand how <Root, Tree-ID> is a "specialized form of" <Headend,
> Color, Endpoint> that satisfies the RFC 9256 "MUST" requirement quoted
> above.
> In particular, Color appears to be missing from <Root, Tree-ID>. I'm
> reading
> "specialized form of" as implying a "subtype of" relationship, which may be
> more restrictive than what was intended.
>
> I suggest adding a paragraph to the end of Section 2.1 (SR P2MP Policy
> Identification) that explains the relationship between those two types of
> identification tuples and how policies are uniquely identified in an
> environment that uses both RFC 9256 SR Policies and this draft's SR PMP
> Policies.
>
>
> _______________________________________________
> 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]