[pim] Re: Mahesh Jethanandani's No Objection on draft-ietf -pim-sr-p2mp-policy-17: (with COMMENT)
Mahesh Jethanandani <[email protected]>
| Newsgroups | gmane.ietf.pim |
|---|---|
| Message-ID | <[email protected]> |
HI Rishabh, See my responses with [mj]. > On Aug 19, 2025, at 10:26 AM, Rishabh Parekh <[email protected]> wrote: > > Mahesh, > > Thanks for the review. Responses inline @ [RP] > > Rishabh. > > On Mon, Aug 18, 2025 at 5:10 PM Mahesh Jethanandani via Datatracker <[email protected] <mailto:[email protected]>> wrote: >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Section 2.3, paragraph 0 >> > An SR P2MP Policy has one or more CPs. Identification of a CP in >> > context of the P2MP Policy is as specified in Section 2.9 of >> > [RFC9256]. A CP may include topological and/or resource constraints >> > and optimization objectives which influence the computation of P2MP >> > tree. The Root node selects the active Candidate Path based on the >> > tie breaking rules defined in[RFC9256]. >> >> Is it that the policy has one or more CPs, or that the policy >> defines/discovers/computes one or more CPs and it is the SR network that has >> one or more CPs? > > [RP] Candidate Path is defined in RFC 9256 as " A candidate path is the unit for signaling of an SR Policy to a headend....". In this document, a Candidate Path is a unit of signalling a (computed) tree instances of an SR P2MP Policy to the Root, Intermediate and Leaf nodes. CPs of an SR P2MP Policy are provisioned with constraints and/or objectives and the PCE then computes the tree instances of the CP. An ACtive CP is selected and the active tree instance of that CP carries traffic from the ROOT. An SR network can be said to have one or tree instances of the Candidate Paths of SR P2MP policies. [mj] Thanks for the clarification. I will be good with the text once it is added. >> >> Section 2.3, paragraph 0 >> > The Replication segments used to instantiate a P2MP tree instance are >> > identified by the tuple: <Root, Tree-ID, Instance-ID, Node-ID>, where >> > Root, Tree-ID of SR P2MP Policy and Instance-ID of the instance map >> > to Replication-ID of Replication segment and Node-ID is as defined in >> > [RFC9524]. >> >> Can the definition of Instance-ID and Node-ID be called out along with Root and >> Tree-ID in a Terminology section instead of scattering them in the document? >> > [RP] Root, Leaf and Bud nodes are defined in RFC 9524.I have added text for these terms referring to that RFC. I have added definitions for Tree-ID and Instance-ID to the terminology section. Node-ID is part of an identifier of a Replication segment and this document already refers to RFC 9524 for terms related to a Replication segment. [mj] Thanks for adding them to the Terminology section. > >> ------------------------------------------------------------------------------- >> NIT >> ------------------------------------------------------------------------------- >> > [RP] I have addressed the NITs. [mj] Look forward to the updated draft. Cheers. >> >> >> >> _______________________________________________ >> pim mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] <mailto:[email protected]> Mahesh Jethanandani [email protected] _______________________________________________ pim mailing list -- [email protected] To unsubscribe send an email to [email protected]