Hi Rishabh,
> 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.
Yes, I think changing the wording to describe a weaker relationship to RFC 9256 SR policies is the right thing to do, and “similar” seems like a plausible word.
In addition, I’d like to see some explanation of the relationship added, along the lines of these three sentences from your response:
- 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).
- 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.
That will help convey/clarify the nature of the similarity and avoid too much being read into that relationship.
From: Rishabh Parekh <rishabhp@xxxxxxxxx>
Sent: Friday, July 25, 2025 7:00 PM
To: Black, David <David.Black@xxxxxxxx>
Cc: tsv-art@xxxxxxxx; draft-ietf-pim-sr-p2mp-policy.all@xxxxxxxx; last-call@xxxxxxxx; pim@xxxxxxxx
Subject: Re: [pim] draft-ietf-pim-sr-p2mp-policy-13 ietf last call Tsvart review
[EXTERNAL EMAIL]
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.
On Fri, Jul 25, 2025 at 2:55 PM David Black via Datatracker <noreply@xxxxxxxx> 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
tsv-art@xxxxxxxx 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 -- pim@xxxxxxxx
To unsubscribe send an email to
pim-leave@xxxxxxxx
|
