[pim] draft-ietf-pim-sr-p2mp-policy-13 ietf last call Tsvart r eview

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]