Skip to main content

IETF Last Call Review of draft-ietf-pim-sr-p2mp-policy-13
review-ietf-pim-sr-p2mp-policy-13-tsvart-lc-black-2025-07-25-00

Request Review of draft-ietf-pim-sr-p2mp-policy
Requested revision No specific revision (document currently at 22)
Type IETF Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2025-07-28
Requested 2025-07-07
Authors Rishabh Parekh (editor) , Daniel Voyer , Clarence Filsfils , Hooman Bidgoli , Zhaohui (Jeffrey) Zhang
I-D last updated 2025-10-07 (Latest revision 2025-09-04)
Completed reviews Rtgdir IETF Last Call review of -14 by Linda Dunbar (diff)
Opsdir IETF Last Call review of -15 by Bing Liu (diff)
Secdir IETF Last Call review of -13 by Corey Bonnell (diff)
Tsvart IETF Last Call review of -13 by David L. Black (diff)
Assignment Reviewer David L. Black
State Completed
Request IETF Last Call review on draft-ietf-pim-sr-p2mp-policy by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/Vq8ogeYygsb_n4RMk7Tfdxki_YM
Reviewed revision 13 (document currently at 22)
Result Ready w/issues
Completed 2025-07-25
review-ietf-pim-sr-p2mp-policy-13-tsvart-lc-black-2025-07-25-00
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
tsv-art@ietf.org 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.