Segment Routing Point-to-Multipoint Policy
draft-ietf-pim-sr-p2mp-policy-22

[Ballot discuss]
Thanks to the authors and the WG for your work on this document.

This is an updated ballot for the v20 posted by the authors. Note that the numbering of open points in the DISCUSS position is being retained as in the original ballot for ease of tracking.

While the proposal is quite straightforward, it took me a few passes to grasp
the the information model of the different constructs introduced in this document
and their interrelationship. Perhaps it is because I am comparing it with
RFC9256 that specified the constructs for SR Policy.

I will attempt to describe the model based on my reading of the document, and would
appreciate if the authors can correct/clarify any errors in my understanding.
Please note some discussions points that I've brought up as part of this
description so as to provide a better context.

An SR P2MP Policy is a construct that represents a (set of?) P2MP trees in a
SR domain that can be used for delivery of P2MP service (i.e., multicast
traffic). Each SR P2MP Policy is identified by .

An SR P2MP Policy can have one or more CPs where each provides constraints and
optimization objective for the computation of a specific tree topology from root
to leaves.

Each CP is identified by  which is
same as in the case of a SR Policy CP. Please see my comment on making this
explicit.

Each CP that is valid (i.e., for which a tree can be computed) has at least
one P2MP tree instance associated with it. There can be more than one instance
in cases like make-before-break (MBB). Within a SR P2MP Policy, each P2MP tree instance is
identified by an Instance-ID.

At any point, only one CP is active and this is selected based on the same
tie-breaking logic as for SR Policy CPs.

All the constructs until this point are instantiated only on the root node
(not considering the controller for now).

Now, we switch to RFC9524 that specified Replication Segment which is
identified as .

Note that per RFC9524 the replication-id is a variable length field and is not
actually specified in that document. This document actually specifies the
replication-id to be .

--
discuss #2 : The text in 2.3 that conveys this is not very clear (please see
the comments section for suggestions). It also makes me wonder if this document
should "update" RFC9524?

This remains open for discussion
--

The replication segment thus represents a unique per P2MP tree
context at each root, intermediate and leaf nodes of a specific P2MP tree
within the context of an SR P2MP Policy CP in the network.

--
discuss #3: This makes the section 3.2 of shared replication segments somewhat
confusing. That section seems to say that replication segment MAY be shared
across different P2MP tree instances and then says shared replication segment
MUST NOT be associated with an SR P2MP tree in v17. In v18, this text is modified
but the explanation is still not clear on how they are used for the P2MP tree.

This remains open for discussion
--

The instantiation of these per P2MP tree replication segment constructs on the
root, intermediate and leaf nodes in the computed tree setup the forwarding
context in the network.

Now, the terminology section says that the terms 'P2MP tree instance' and
'P2MP tree' are used interchangeably.

Then we come to section 3 which specifies the P2MP tree construct in a way
that is disconnected with the SR P2MP Policy construct. Is it because the SR
P2MP Policy construct is something that only exists on the controller (see
discuss#1 above) ?

Then the replication segment and its replication SID constructs from RFC9524
are introduced within the P2MP Tree context.

[Ballot discuss]
Thanks to the authors and the WG for your work on this document.

This is an updated ballot for the v19 posted by the authors. Note that the numbering of open points in the DISCUSS position is being retained as in the original ballot for ease of tracking.

While the proposal is quite straightforward, it took me a few passes to grasp
the the information model of the different constructs introduced in this document
and their interrelationship. Perhaps it is because I am comparing it with
RFC9256 that specified the constructs for SR Policy.

I will attempt to describe the model based on my reading of the document, and would
appreciate if the authors can correct/clarify any errors in my understanding.
Please note some discussions points that I've brought up as part of this
description so as to provide a better context.

An SR P2MP Policy is a construct that represents a (set of?) P2MP trees in a
SR domain that can be used for delivery of P2MP service (i.e., multicast
traffic). Each SR P2MP Policy is identified by .

An SR P2MP Policy can have one or more CPs where each provides constraints and
optimization objective for the computation of a specific tree topology from root
to leaves.

Each CP is identified by  which is
same as in the case of a SR Policy CP. Please see my comment on making this
explicit.

Each CP that is valid (i.e., for which a tree can be computed) has at least
one P2MP tree instance associated with it. There can be more than one instance
in cases like make-before-break (MBB). Within a SR P2MP Policy, each P2MP tree instance is
identified by an Instance-ID.

At any point, only one CP is active and this is selected based on the same
tie-breaking logic as for SR Policy CPs.

All the constructs until this point are instantiated only on the root node
(not considering the controller for now).

Now, we switch to RFC9524 that specified Replication Segment which is
identified as .

Note that per RFC9524 the replication-id is a variable length field and is not
actually specified in that document. This document actually specifies the
replication-id to be .

--
discuss #2 : The text in 2.3 that conveys this is not very clear (please see
the comments section for suggestions). It also makes me wonder if this document
should "update" RFC9524?

This remains open for discussion
--

The replication segment thus represents a unique per P2MP tree
context at each root, intermediate and leaf nodes of a specific P2MP tree
within the context of an SR P2MP Policy CP in the network.

--
discuss #3: This makes the section 3.2 of shared replication segments somewhat
confusing. That section seems to say that replication segment MAY be shared
across different P2MP tree instances and then says shared replication segment
MUST NOT be associated with an SR P2MP tree in v17. In v18, this text is modified
but the explanation is still not clear on how they are used for the P2MP tree.

This remains open for discussion
--

The instantiation of these per P2MP tree replication segment constructs on the
root, intermediate and leaf nodes in the computed tree setup the forwarding
context in the network.

Now, the terminology section says that the terms 'P2MP tree instance' and
'P2MP tree' are used interchangeably.

--
discuss #4: Why can't the same consistent term 'P2MP tree' be used throughout
the document? Is there a subtle difference with the use of "instance" here?

In the updated version, can this text now be removed from section 1.1?
"This document uses terms P2MP tree instance and P2MP tree interchangeably."
--

Then we come to section 3 which specifies the P2MP tree construct in a way
that is disconnected with the SR P2MP Policy construct. Is it because the SR
P2MP Policy construct is something that only exists on the controller (see
discuss#1 above) ?

Then the replication segment and its replication SID constructs from RFC9524
are introduced within the P2MP Tree context.

--
discuss #6: Section 2.4 introduces the term Binding SID for SR P2MP Policy but
does not specify what it is. It says Tree-SID of the active CP SHOULD be used
as the BSID, but does not say what happens if that is not the case? Is there a
need to introduce BSID here and is it not sufficient to only use the Tree-SID
always in the context of SR P2MP Policy?

Note: In the updated text, the part of the BSID (which is constant), getting
swapped with the currently active Tree SID (which may be changing) is not
covered even though that was one of the points that came out during the
discussion on this topic. Wanted to cross-check that it was left out intentionally.
--

--
discuss #7: Sections 4.1, talks about allocation of Tree SID. However, it does
specify whether allocation is from the SRGB, SRLB, dynamic range, or any of
them (along with any recommendations). Same goes for the replication SIDs at
intermediate and leaf nodes. Please also note a detailed comment below about
section 4.1 and need for some text to indicate how these SIDs are managed across
multiple nodes and how conflicts/errors (e.g., due to unavailability) are
handled. I would expect that this impacts the order in which a controller
needs to provision and setup (as also update) the P2MP trees across the nodes
- perhaps starting from the leaves and building the tree until the root?

This is largely addressed in the updated text. However, the following text in
section 5.5 seems odd - did you mean "reporting this success"?

"A node SHOULD report a successful installation of a Replication segment.
The exact procedure for reporting this failure is outside the scope of this
document."
--

[Ballot discuss]
Thanks to the authors and the WG for your work on this document.

Note: My review was done on v17 of the document and while v18 does touch upon
some of the same areas/aspects brought in this review, I will request the
authors to please cross-check.

While the proposal is quite straightforward, it took me a few passes to grasp
the the information model of the different constructs introduced in this document
and their interrelationship. Perhaps it is because I am comparing it with
RFC9256 that specified the constructs for SR Policy.

I will attempt to describe the model based on my reading of the document, and would
appreciate if the authors can correct/clarify any errors in my understanding.
Please note some discussions points that I've brought up as part of this
description so as to provide a better context.

An SR P2MP Policy is a construct that represents a (set of?) P2MP trees in a
SR domain that can be used for delivery of P2MP service (i.e., multicast
traffic). Each SR P2MP Policy is identified by .

Note: Tree-ID doesn't identify a P2MP tree so seems like an odd choice for the
term but it is too late to change this?

An SR P2MP Policy can have one or more CPs where each provides constraints and
optimization objective for the computation of a specific tree topology from root
to leaves.

Each CP is identified by  which is
same as in the case of a SR Policy CP. Please see my comment on making this
explicit.

Each CP that is valid (i.e., for which a tree can be computed) has at least
one P2MP tree instance associated with it. There can be more than one instance
in cases like make-before-break (MBB). Within a CP, each P2MP tree instance is
identified by an Instance-ID.

At any point, only one CP is active and this is selected based on the same
tie-breaking logic as for SR Policy CPs.

All the constructs until this point are instantiated only on the root node.

--
discuss #1: The document text (see below) seems to indicate that it is only the
replication segment that is instantiated on the root node while the SR P2MP
Policy construct is something on the controller. I believe, that is not the
case, and please clarify with explicit text saying that the SR P2MP Policy is
instantiated on the root node. As an example, unless instantiated on it, the root
may not be able to perform monitoring/OAM on the tree corresponding to the
active CP and switchover (without controller action) to a backup CP on failure
(this is what is described in section 4.5.2?).

section 2.2. says "An SR P2MP Policy is provisioned on a controller
(see Section 4). The controller computes the P2MP tree instances of Candidate
Paths of the policy and instantiates the necessary Replication segments at the
Root, Replication and Leaf nodes of the trees. "
--

Now, we switch to RFC9524 that specified Replication Segment which is
identified as .

Note that per RFC9524 the replication-id is a variable length field and is not
actually specified in that document. This document actually specifies the
replication-id to be .

--
discuss #2 : The text in 2.3 that conveys this is not very clear (please see
the comments section for suggestions). It also makes me wonder if this document
should "update" RFC9524?
--

The replication segment thus represents a unique per P2MP tree
context at each root, intermediate and leaf nodes of a specific P2MP tree
within the context of an SR P2MP Policy CP in the network.

--
discuss #3: This makes the section 3.2 of shared replication segments somewhat
confusing. That section seems to say that replication segment MAY be shared
across different P2MP tree instances and then says shared replication segment
MUST NOT be associated with an SR P2MP tree in v17. In v18, this text is modified
but the explanation is still not clear on how they are used for the P2MP tree.
--

The instantiation of these per P2MP tree replication segment constructs on the
root, intermediate and leaf nodes in the computed tree setup the forwarding
context in the network.

Now, the terminology section says that the terms 'P2MP tree instance' and
'P2MP tree' are used interchangeably.

--
discuss #4: Why can't the same consistent term 'P2MP tree' be used throughout
the document? Is there a subtle difference with the use of "instance" here?
--

Then we come to section 3 which specifies the P2MP tree construct in a way
that is disconnected with the SR P2MP Policy construct. Is it because the SR
P2MP Policy construct is something that only exists on the controller (see
discuss#1 above) ?

Then the replication segment and its replication SID constructs from RFC9524
are introduced within the P2MP Tree context.

--
discuss #5: The replication SID associated with the replication segment at the
root node is specified as the tree SID. This maps it to a specific P2MP tree
under a specific CP under a specific SR P2MP Policy. It is not clear if there are
multiple tree SIDs associated with a single CP (one per P2MP tree?) or if each
CP has only one tree SID. It is also not clear if the same tree SID can be
used by all CPs of the same SR P2MP Policy.
--

One of the challenges that I faced during the review of this document is the
attempts at establishing equivalency between SR P2MP Policy and SR Policy. I
found this to be problematic (please also see in the comments section for more
details).

--
discuss #6: Section 2.4 introduces the term Binding SID for SR P2MP Policy but
does not specify what it is. It says Tree-SID of the active CP SHOULD be used
as the BSID, but does not say what happens if that is not the case? Is there a
need to introduce BSID here and is it not sufficient to only use the Tree-SID
always in the context of SR P2MP Policy?
--

--
discuss #7: Sections 4.1, talks about allocation of Tree SID. However, it does
specify whether allocation is from the SRGB, SRLB, dynamic range, or any of
them (along with any recommendations). Same goes for the replication SIDs at
intermediate and leaf nodes. Please also note a detailed comment below about
section 4.1 and need for some text to indicate how these SIDs are managed across
multiple nodes and how conflicts/errors (e.g., due to unavailability) are
handled. I would expect that this impacts the order in which a controller
needs to provision and setup (as also update) the P2MP trees across the nodes
- perhaps starting from the leaves and building the tree until the root?
--

--
discuss #8: Section 4.5.2 says that a disjoint backup tree instance can be
used to provide end-to-end path protection. I assume it means end-to-end tree
protection? It is also necessary to clarify how this is done in the constructs
introduced in this document. I assume this is done by having a backup CP that
has constraints to ensure disjoint-ness with the primary/active CP? If so,
please clarify.
--

--
discuss #9: The document does cover the provisioning of the SR P2MP
Policy construct along with replication segment(s) directly on the root node
and of the corresponding replication segments on the intermediate & leaf nodes
via CLI/NETCONF/YANG. However, It is also silent on explicit candidate paths.
Is it not possible that (what is called as) a controller in this document is
simply a provisioning platform that does no path computation but allows an
operator to setup static trees? In other words, I find the tight coupling of
the concepts of path (or rather tree in this case) computation and
provisioning/signaling to the network to be limiting.
--

[Ballot comment]
Please also find below some comments provided inline in the idnits format of
the v17 of this document. On all editorial and minor comments, I will leave it
to the authors discretion. On the major ones, I would appreciate responses and
clarifications.

Please look for  at the end of this review and if it is not there, then
likely the email has gotten truncated by your client (please refer to the mailing
list in that case).

13               Segment Routing Point-to-Multipoint Policy
14                     draft-ietf-pim-sr-p2mp-policy-17

Please look for all occurences of
"policy" and ensure that the term SR P2MP Policy (with consistent
capitalization) is used throughout the document. For other uses of the word
"policy" the lowercase can be used (e.g., local policy). This will save a lot
of time and effort when the RFC Editor processes this document ... from my own
experience :-)

Candidate Path - another term where consistency of use needs
to be fixed. I suggest using all lowercase to match RFC9256. There are also
other terms like "root node", "leaf node", "replication segment", etc. where
consistency in capitalization will help down the line.

16 Abstract

18   Point-to-Multipoint (P2MP) policy enables creation of P2MP trees for
19   efficient multi-point packet delivery in a Segment Routing (SR)
20   domain.  A SR P2MP Policy consists of Candidate Paths (CP) which
21   define the topology of P2MP tree instances of the Candidate Paths.  A
22   P2MP tree instance is instantiated by a set of Replication segments.

Suggest to drop/skip the last 2 sentences from the abstract. They are
imprecise and leaving them out will not take anything from the abstract - only
make it better.

109 1.  Introduction

111   A Multi-point service delivery can be realized with P2MP (Point-to-
112   Multipoint) trees in a Segment Routing domain [RFC8402].  A P2MP tree
113   spans from a Root node to a set of Leaf nodes via intermediate
114   Replication nodes.  It consists of a Replication segment [RFC9524] at
115   the root node, stitched to one or more Replication segments at Leaf
116   nodes and intermediate Replication nodes.  A Bud node [RFC9524] is a
117   node that is both a Replication node and a Leaf node.  Any mention of
118   "Leaf node(s)" in this document should be considered as referring to
119   "Leaf or Bud node(s)".

121   A Segment Routing P2MP Policy defines the Root and Leaf nodes of a
122   P2MP tree.  It has one or more Candidate Paths (CP) with optional
123   constraints and/or optimization objectives.

125   A controller computes P2MP tree instances of a SR P2MP Policy, from
126   the Root to Leaf nodes, of a Candidate Path using the constraints and
127   objectives specified in the Candidate Path.  Once computed, the
128   controller instantiates a P2MP tree instance in the SR domain by
129   signaling Replication segments to the Root, Replication and Leaf
130   nodes.  A Path Computation Element (PCE) [RFC4655] is one example of
131   such a controller.

133   The Replication segments of a P2MP tree can be instantiated for SR-
134   MPLS [RFC8660] and SRv6 [RFC8986] data planes, enabling efficient
135   packet replication within an SR domain.

Let me share some suggestions for improving the introduction
section for better readability. It could just provide an overview or
introduction of the topics/concepts the document is covering and leave the
details for the body of the document. Alternately, you could consider
providing a high-level information model of the constructs specified in the
document (please feel to leverage the text from the DISCUSS portion, if that
helps).

137 1.1.  Terminology

139   This section defines terms used frequently in this document.  Refer
140   to Terminology section of [RFC9524] for definition of Replication
141   segment and other terms associated with it.

143   SR P2MP Policy: A SR P2MP Policy is a mechanism to construct P2MP
144   trees in a SR domain by specifying a Root and Leaf nodes.

SR P2MP Policy is not a mechanism (also goes for other similar terms).
It can be called a construct, or a framework or such perhaps?

146   Candidate Path: A Candidate Path of SR P2MP Policy defines
147   topological or resource constraints and optimization objectives that
148   are used to construct P2MP Tree instances.

150   P2MP Tree Instance: A P2MP tree instance in a SR domain is
151   constructed by stitching Replication segments between Root and Leaf
152   nodes of a SR P2MP Policy.  A P2MP tree belongs to a Candidate Path
153   and its topology is determined by constraints and optimization
154   objective of the Candidate Path.  This document uses terms P2MP tree
155   instance and P2MP tree interchangeably.

Please consider introducing other terms such as Replication
Segment, Tree SID, root/intermediate/leaf nodes, etc. as well in this section.


157 2.  SR P2MP Policy

159   An SR P2MP Policy is used to instantiate P2MP trees between a Root
160   and Leaf nodes in an SR domain.  It is similar to SR Policy

Except for the part that SR P2MP Policy also has multiple CPs just
like SR Policy and uses the same tiebreaking for selection of the active CP, I
don't see any similarity between the two constructs. My concern is that
drawing such equivalency may be more harmful than helpful for a reader that is
familiar with SR Policy but new to this document. I feel it is a bad idea
to keep comparing/constrasting the two. Also see further comments that are
related to this point.


175   *  Tree-ID: A 32-bit unsigned integer that uniquely identifies the
176       P2MP Policy in the context of the Root node.  This is equivalent
177       to the Color of SR Policy identifier tuple.

Since Tree-ID is specified here as a locally unique/significant
context on the root node alone, I can't see how it can be equivalent to the
Color of SR Policy that identifies the "intent" and is not local to the
headend node. See use of Color ExtCom for BGP service routes to perform
steering over SR policies across the network. I don't understand why this
document should even attempt to do an equivalency between SR Policy and SR P2MP
Policy constructs when they are like apples and oranges.


179   Note, SR P2MP Policy identification tuple does not have a member
180   equivalent to Endpoint of SR Policy identifier tuple since SR P2MP
181   Policies result in P2MP trees to a varying set of endpoints (Leaf
182   nodes).

Perhaps "P2MP tree branches to a varying set of endpoints" ?

194   An SR P2MP Policy is provisioned on a controller (see Section 4).
195   The controller computes the P2MP tree instances of Candidate Paths of
196   the policy and instantiates the necessary Replication segments at the
197   Root, Replication and Leaf nodes of the trees.  The Root and Tree-ID
198   of the SR P2MP Policy are mapped to Replication-ID element of the
199   Replication segment identifier [RFC9524].

The above paragraph is not very helpful at this place. These things
are described in more detail further in the document. I would suggest to keep
these sections where the constructs are described as crisp as possible.

201 2.3.  Candidate Paths and P2MP Tree Instances

203   An SR P2MP Policy has one or more CPs.  Identification of a CP in
204   context of the P2MP Policy is as specified in Section 2.9 of
205   [RFC9256].  A CP may include topological and/or resource constraints

Identification of CP is in section 2.6 of RFC9256 and it would be
helpful to list those identifiers in this document as well. Also, are the
semantics of those identifiers the same as in RFC9256 - if so, please clarify
the same.

206   and optimization objectives which influence the computation of P2MP
207   tree.  The Root node selects the active Candidate Path based on the
208   tie breaking rules defined in[RFC9256].

Please clarify that it is based on section 2.9 of RFC9256

210   A Candidate Path has zero or more P2MP tree instances.  A P2MP tree
211   instance is identified by an Instance-ID.  This is an unsigned 16-bit
212   number which is unique in context of the SR P2MP Policy of the
213   Candidate Path.

Here, please try to explain briefly why zero or more than one.
It would help the reader to bring forward (or put forward reference) to the
points about MBB.

215   The Replication segments used to instantiate a P2MP tree instance are
216   identified by the tuple: , where
217   Root, Tree-ID of SR P2MP Policy and Instance-ID of the instance map
218   to Replication-ID of Replication segment and Node-ID is as defined in
219   [RFC9524].

RFC9525 specifies that replication segments are identified by
and that cannot be changed by this document. What
this document does is that it is expanding the replication-id to be . Is my understanding correct? If so, please clarify this
very precisely.

225 2.4.  Steering traffic into a SR P2MP policy

227   The Tree-SID, as described in Section 3, serves as the data plane
228   identifier of a P2MP tree instance.  It is instantiated in the data
229   plane at the Root node, intermediate Replication nodes, and Leaf
230   nodes of the P2MP tree instance.  The Tree-SID of the active instance
231   of the active Candidate Path SHOULD be used as the Binding SID of the
232   SR P2MP Policy.

Please consider inserting a separate section before this one
where the Tree SID is specified instead of within this section. Or consider
moving this topic in a new top-level section between the current sections 3
and 4 where the Tree SID can be specified along with the steering aspects.


259 3.1.  Tree-SID and Replication segments

261   The Replication SID associated with the Replication segment at the
262   Root node is referred to as the Tree-SID.  The Tree-SID SHOULD also
263   serve as the Replication-SID for the Replication segments at
264   intermediate Replication nodes and Leaf nodes.  However, the

Perhaps "It is RECOMMENDED that the Tree-SID is also used as the
Replication-SID ..." ? Also, it would be helpful to clarify why this is
recommended - e.g., it simplifies debuging/troubleshooting/operations?

265   Replication segments at intermediate Replication nodes and Leaf nodes
266   MAY use Replication-SIDs that differ from the Tree-SID.

For SR-MPLS, the same global Tree-SID label can be used at each
replication point. However, I would assume that for SRv6 it may be same
function that used in all replications points but the locator parts would be
specific to each intermediate/leaf nodes? Please clarify.


293   A P2MP tree can associated with one or more multi-point services on
294   the Root and Leaf nodes.  In SR-MPLS deployments, if it is known a
295   priori that multi-point services mapped to a SR-MPLS P2MP tree can be
296   uniquely identified within the SR domain, a controller MAY opt not to

perhaps "can be uniquely identified using their service labels"? This
is clarified later on, but not clear in that sentence.

297   instantiate Replication segments at Leaf nodes.  In such cases,
298   Replication Nodes upstream of the Leaf nodes effectively implement
299   Penultimate-Hop Popping (PHP) behavior by removing the Tree-SID from
300   the packet before forwarding it.  A multi-point service context
301   allocated from an upstream assigned label or Domain-wide Common Block
302   (DCB), as specified in [RFC9573], is an example of a globally unique
303   context that facilitates this optimization.



333 4.  Using a controller to build a P2MP Tree

335   A controller is provisioned with SR P2MP Policy and its Candidate
336   Paths to compute and instantiate P2MP trees in an SR domain.  Once
337   computed, the controller instantiates the Replication segments that
338   compose the P2MP tree in the SR domain nodes using signalling
339   protocols such as PCEP, BGP, NetConf, etc.  The procedures for
340   provisioning a controller and the instantiation of Replication
341   segments in an SR domain are outside the scope of this document.

An informative reference to draft-ietf-pce-sr-p2mp-policy would be
very helpful. I am not sure why it is necessary to reference BGP here and if
just taking PCEP as an example of a signaling protocol would not be
sufficient. Note that NETCONF is not a signaling protocol. But of course we
need to cover NETCONF/YANG even if there is no reference to provide to a model
as yet.

343 4.1.  SR P2MP Policy Provisioning on a controller

345   An entity (an operator, a network node or a machine) provisions a SR
346   P2MP Policy on a controller by specifying the addresses of the Root,

Perhaps "A SR P2MP Policy is provisioned on a controller by
specifying ..." ?

347   set of Leaf nodes Candidate Paths.  The procedures and mechanisms for
348   provisioning a controller are outside the scope of this document.

350   Candidate Path constraints MAY include link color affinity,
351   bandwidth, disjointness across link, node, or Shared Risk Link Group
352   (SRLG) [RFC4202], delay bound, link loss, flexible algorithm etc.,
353   and optimization objectives based on IGP or TE metric or link
354   latency.  Other constraints and optimization objectives MAY be used
355   for P2MP tree computation.

RFC9256 didn't get into these details as these are anyway out of
scope. This document could follow the same approach and perhaps refer to
https://datatracker.ietf.org/doc/html/draft-filsfils-spring-sr-policy-considerations-09#section-3
or alternately provide some references for all those TE constructs and not
just the SRLG one. See https://www.rfc-editor.org/rfc/rfc9256.html#section-5.2

357   The Tree SID of a P2MP Tree instance of a Candidate Path of a SR P2MP
358   Policy can be either dynamically assigned by the controller or
359   statically assigned by entity provisioning the SR P2MP Policy.

This still does not cover how the controller provisioned Tree-SID
conflicts (or unavailability) on the routers are handled. At a minimum, the
text can say that this could happen and what would be result of such errors?


389 4.4.  Instantiating P2MP tree on nodes

391   Once a controller computes a P2MP tree instance for a CP of a SR P2MP
392   Policy, it needs to instantiate the tree on the relevant network
393   nodes via Replication segments.  The controller can use various
394   mechanisms to program the Replication segments as described below.
395   Some examples of these mechanisms are PCEP, BGP and NetConf.  The

the above sentence is repeated from section 4

401 4.5.1.  Local Protection

403   A network link, node or path on the instance of a P2MP tree can be
404   protected using SR policies computed by a controller.  The backup SR
405   policies are programmed in data plane in order to minimize traffic
406   loss when the protected link/node fails.

Please clarify and specify in detail how this works. I am assuming the
SR Policy will be somehow fixed up into one of the replication branches?
Are there any considerations on the encapsulation?

408   It is also possible to use node local Loop-Free Alternate [RFC5286]
409   protection and Micro-Loop [RFC5715] prevention mechanisms to protect
410   link/nodes of P2MP tree.

Since either LSM or unicast SRv6 SID address are used, wouldn't TI-LFA
and microloop avoidance be available for the traffic while traversing between
intermediate/leaf nodes?

429   An SR domain needs protection from outside attackers as described in
430   [RFC8754].

Did you mean SRv6 domain? or else the reference should be to RFC8402
to cover both SR-MPLS and SRv6.

432   Failure to protect the SR MPLS domain by correctly provisioning MPLS
433   support per interface permits attackers from outside the domain to
434   send packets to receivers of the Multi-point services that use the SR
435   P2MP trees provisioned within the domain.

437   Failure to protect the SRv6 domain with inbound Infrastructure Access
438   Control Lists (IACLs) on external interfaces, combined with failure
439   to implement BCP 38 [RFC2827] or apply IACLs on nodes provisioning
440   SIDs, permits attackers from outside the SR domain to send packets to
441   the receivers of Multi-point services that use the SR P2MP trees
442   provisioned within the domain.

References to RFC8754 and its security consideration is required here.
Perhaps also to the security considerations or RFC8986?

[Ballot 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?

Section 2.3, paragraph 0
>    The Replication segments used to instantiate a P2MP tree instance are
>    identified by the tuple: , 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?

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3.3, paragraph 1
>    A P2MP tree can associated with one or more multi-point services on
>    the Root and Leaf nodes.  In SR-MPLS deployments, if it is known a
>    priori that multi-point services mapped to a SR-MPLS P2MP tree can be
>    uniquely identified within the SR domain, a controller MAY opt not to
>    instantiate Replication segments at Leaf nodes.  In such cases,
>    Replication Nodes upstream of the Leaf nodes effectively implement
>    Penultimate-Hop Popping (PHP) behavior by removing the Tree-SID from
>    the packet before forwarding it.  A multi-point service context
>    allocated from an upstream assigned label or Domain-wide Common Block
>    (DCB), as specified in [RFC9573], is an example of a globally unique
>    context that facilitates this optimization.

s/tree can associated/tree can be associated/

Section 4, paragraph 0
>    A controller is provisioned with SR P2MP Policy and its Candidate
>    Paths to compute and instantiate P2MP trees in an SR domain.  Once
>    computed, the controller instantiates the Replication segments that
>    compose the P2MP tree in the SR domain nodes using signalling
>    protocols such as PCEP, BGP, NetConf, etc.  The procedures for
>    provisioning a controller and the instantiation of Replication
>    segments in an SR domain are outside the scope of this document.

The protocol is NETCONF, the WG is NetConf, therefore in this case it better to say NETCONF. Same comment applies to Section 4.4.

"Appendix A.", paragraph 12
> sing N-SID6, steers packet via IGP shortest path to that node. Replication to
>                                    ^^^^^^^^
A determiner may be missing.

"Appendix A.", paragraph 13
> ing N-SID7, steers packet via IGP shortest path to R7 via either R5 or R4 ba
>                                  ^^^^^^^^
A determiner may be missing.

"A.1.1.", paragraph 6
> ation to R6, steers packet via IGP shortest path to that node. Replication to
>                                    ^^^^^^^^
A determiner may be missing.

[Ballot comment]
In both the abstract and the introduction, it is unclear whether P2MP was an existing concept that this document built on, or a new concept being defined by this document. The first paragraph reads as if it's providing the necessary context for what this document does, but then the second paragraph states that it defines... much of the stuff that was just said? Consider moving "This document specifies..." earlier in the abstract or adjusting scope to make it clear which elements already exist. For example, "RFC 9524 defines a mechanism for one Segment Routing node to distribute traffic to multiple other nodes, called a Replication segment. Using multiple layers of Replication segments can enable [better scale, etc.], but requires centralized coordination of these Replication segments. This document defines a mechanism to perform this coordination and distribute the resulting configuration." Similarly, the introduction would benefit from an explanation of the current state of things, in what situations that state is suboptimal, and how this new element improves the situation.

Thank you for expanding CP into Candidate Path on its first use. Also consider mentioning the abbreviation at the definition of Candidate Path in the Terminology section.

The document is inconsistent about whether it's "a" SR Policy (if SR is pronounced "segment routing") or "an" SR Policy (if SR is pronounced "ess arr"). They're about evenly split right now -- please pick one. (For what it's worth, RFC9524 uses "an" throughout.)

In Section 3.2, I'm unclear what "a shared Replication segment MUST NOT be associated with an SR P2MP tree" means. Can you expand on this? It seems natural that a node might need to see whether a given Replication segment is being used by any trees at the moment, and it's unclear why tracking that information would be explicitly prohibited.

You probably need a definition for "Penultimate-Hop Popping behavior," either in this document or by reference. Alternatively, don't make it a Capitalized Term and just say something like "Replication Nodes upstream of the Leaf nodes can remove the Tree-SID from the packet before forwarding, avoiding the need to configure the Leaf nodes to [whatever]."

In Section 3.4, isn't this the process at *each* node, not just the Root?

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-pim-sr-p2mp-policy-16
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Mike McBride for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Section 1

Please expand "P2MP" in the introduction as well as the abstract is stand-alone.

The "bud" considerations should probably be in the terminology section.

Unsure whether a mix of SR-MPLS & SRv6 is specified here as the following sentence is a little ambiguous `enabling efficient packet replication within an SR domain.`.

### Section 1.1

In `construct a P2MP Tree instances` please use singular or plural form ;-)

### Section 2.1

Should there be a reference for `Color of SR Policy identifier` ?

Assuming that P2MP is mainly for multicast traffic, I am a little surprised not to see the mcast group in the tuple. But, I may have missed the point of P2MP.

Also, why using `tuple` rather than "pair" (this is cosmetic though).

### Section 3.3

As this is a SR-MPLS specific section, should there be a SRv6 specific section as well ?

### Section 4.1

What is `SRLG` ? Please expand and perhaps add an informative reference.

### Section 4.5.1

Should there be informative references for the protection mechanisms ?

### Section 6

Unsure whether the paragraphs after the first one are useful.

### Section 9.2

While not critical, it is highly unusual to refer to an individual expired draft such as draft-filsfils-spring-srv6-net-pgm-illustration (especially when used in the appendix).

### Appendix A

Please expand `PSP` and `USD` (plus add references ?).

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

[Ballot comment]
Hi Rishabh, Dan, Clarence, Hooman, and Jeffrey,

Thank you for the effort put into this specification, which leverages RFC9524 and RFC9256.

Please find some comments below:

# Check

Section 2 has the following:

  It is similar to SR Policy
  [RFC9256].  Like SR Policy, SR P2MP Policy has one or more Candidate
  Paths and uses same criteria to select the Active Candidate Path.

I’d like to check this as I’m not sure that all parameters are inherited. For example, do we still have Discriminator for the P2MP case as well?

# Active instance of a Candidate Path?!

Section 2.3 says:
  The controller designates an active instance of a CP at the Root node
  of SR P2MP Policy by signalling this state through the protocol used
  to instantiate the Replication segment of the instance.

(1) What is meant by “an active instance of a CP”?

(2) How this behavior interacts with the tie-breaking rules?

As I’m there, please fix this: s/The controller/A controller

# Section 2.4

CURRENT:
  The Tree-SID of the active
  instance of the active Candidate Path SHOULD be used as the Binding
  SID of the SR P2MP Policy.

Why this is not MUST? (see also next comment)

# Steering behavior

CURRENT:
  The Root node can steer an incoming packet into a SR P2MP Policy in
  one of following methods:

  *  Local Policy-Based Routing: The Root node selects the active P2MP
      tree instance of the active Candidate Path of the SR P2MP Policy
      based on local policy.  The procedures to map an incoming packet
      to a SR P2MP Policy are out of scope of this document.

  *  Tree-SID Based Routing: The Binding SID (Tree-SID) in the incoming
      packet is used to map the packet to the appropriate P2MP tree
      instance.

(1) Should the behavior of the root node be part of the instructions received from the controller?

(2) As discussed earlier in the document, there is room for a case where BID!=Tree-SID. What is the expected behavior in such cases?

(3) s/Local Policy-Based Routing/Local Policy-Based forwarding and s/Tree-SID Based Routing/Tree-SID Based forwarding

# Section 3.1

CURRENT:
  The Tree-SID SHOULD also
  serve as the Replication-SID for the Replication segments at
  intermediate Replication nodes and Leaf nodes. 

Please provide the rationale for this one. What are the implications if this SHOULD is not followed?

# Section 3.2

(1)

CURRENT:
  A shared Replication Segment SHOULD be identified using a Root-ID set
  to zero (0.0.0.0 for IPv4 and :: for IPv6) along with a Replication-
  ID that is unique within the context of the node where the
  Replication segment is instantiated.

Idem as previous point, why this isn’t a MUST? At least the rationale should be called out.

(2)

CURRENT:
  However, a shared Replication segment MUST NOT be associated with an
  SR P2MP tree.

Does this apply even if this is shared only between a subset and not all instances?

# Section 3.3

## Transport/Service Context

CURRENT:
  For multi-point services, the transport identifier which is the Tree-
  SID or Replication SID at a Leaf node is also associated with the
  service context because it is not always feasible to separate the
  transport and service context with efficient replication in core
  since a) multi-point services may have differing sets of end-points,
  and b) downstream allocation of service context cannot be encoded in
  packets replicated in the core.

I guess I understand what is meant here by these contexts, but it would be better to introduce these first.

## Deployment matter?

CURRENT:
  However, for SR-MPLS deployments, if it is known a priori that multi-
  point services mapped to a P2MP tree can be uniquely identified
  within the SR domain, a controller MAY opt not to instantiate
  Replication Segments at Leaf nodes. 

How is that made known to the controller? Also, shouldn’t this better handled by a policy?

# Section 4.2

CURRENT:
  A controller performs the following functions in general:

  *  Topology Discovery: A controller discovers network topology across
      Interior Gateway Protocol (IGP) areas, levels or Autonomous
      Systems (ASs).

  *  Capability Exchange: A controller discovers a node's capability to
      participate in SR P2MP tree as well as advertise it’s capability
      to compute P2MP trees.

It also need to retrieve installed tree instances in the underly domain when it first bootstraps.

# Section 4.3

## Loops

CURRENT:
  A controller MUST compute a P2MP tree such that there are no loops in
  the tree at steady state as required by [RFC9524]).

I guess this should be conditional: IF the controllers computes a tree, then it must be forwarding loop-free.

(nit) delete the extra “)”.

## Policy-based

CURRENT:
  A controller SHOULD modify a P2MP tree of a Candidate Path on
  detecting a change in the network topology or in case a better path
  can be found based on the new network state.  In this case, the
  controller MAY create a new instance of a P2MP tree and remove the
  old instance of the tree from the network in order to minimize
  traffic loss.

The SHOULD is scoped vaguely. No every topology change will trigger a modification of the tree.

Also, I guess some policy is needed to drive the controller behavior for migrating to a new path/instance.

# Section 4.5.2

CURRENT:
  It is possible for a controller create a disjoint backup tree
  instance for providing end-to-end path protection.

Well, this depends on the underlying topology.

Not sure this statement (even if adjusted) adds much to the discussion.

# Additional Operational Considerations

I was expecting some discussion about scalability matters and how to test an active CP.

Please consider adding some discussion about these. Adding readily-available pointers (if any) would work as well. Thanks

# Minor points

## Abstract

(1) Circular definition

CURRENT :
  A SR P2MP Policy consists of Candidate Paths (CP) which
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^           
  define the topology of P2MP tree instances in each Candidate Path.
  ^^^^^^                                    ^^^^^^^^^^^^^^^^^^^^^^ 

(2) (nit) s/Paths and and how P2MP trees/Paths and how P2MP trees

## Introduction

(1) Cite an authoritative reference

CURRENT:
  A Multi-point service delivery can be realized with P2MP trees in a
  Segment Routing domain.
  ^^^^^^^^^^^^^^^^^^^^^^ 

(2) There might be multiple roots

OLD:
  A controller computes P2MP tree instances, from the Root to Leaf
  nodes,

NEW:
  A controller computes P2MP tree instances, from a Root to Leaf
  nodes,

(3) nit

OLD: Once computed, the controller instantiate a P2MP tree instance
NEW: OLD: Once computed, the controller instantiates a P2MP tree instance

(4) Missing references

CURRENT:
  The Replication segments of a P2MP tree can be instantiated for both
  SR-MPLS and SRv6 dataplanes, enabling efficient packet replication
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  within an SR domain.

## Section 2.2: point the reader to Section 4 where these matters are zoomed into

OLD: A SR P2MP Policy is provisioned on a controller. 

NEW: An SR P2MP Policy is provisioned on a controller (see Section 4). 

## Section 2.3

CURRENT:
  The Root
  node selects the active Candidate Path based on the tie breaking
  rules defined in [RFC9256].
                ^^^^^^^^^^^^

Please add the exact section to look at.

## Section 4

OLD:
  A controller is provisioned with SR P2MP Policy and it's Candidate
                                                      ^^^^^^
  Paths to compute and instantiate P2MP trees in SR domain.  Once
                                              ^^^^^^^^^^^^
  computed, the controller instantiates the Replication segments that
  compose the P2MP in the SR domain nodes using signalling protocols
  such as PCEP, BGP, NetConf etc.  The procedures for provisioning a
                      ^^^^^^^^^^^^ 
  controller and the instantiation Replication segments in SR domain
                                  ^^^^                  ^^^^^^^^
  are outside the scope of this document.

NEW:
  A controller is provisioned with SR P2MP Policy and its Candidate
  Paths to compute and instantiate P2MP trees in an SR domain.  Once
  computed, the controller instantiates the Replication segments that
  compose the P2MP in the SR domain nodes using signalling protocols
  such as PCEP, BGP, NETCONF, etc.  The procedures for provisioning a
  controller and the instantiation of Replication segments in an SR domain
  are outside the scope of this document.

## Section 4.2

s/ASs/ASes
s/it’s capability/its capability

## Appendix

Replication SIDs formatted as SRv6 Segment Identifier (SID). The textual representation of those has to adhere to RFC 5952, especially this part:

  The characters "a", "b", "c", "d", "e", and "f" in an IPv6 address
  MUST be represented in lowercase.

Cheers,
Med

[Ballot comment]
I did not find any transport-specific concerns in my review of this document.

Thank you for the TSV-ART review by David Black, who noticed one
discrepancy that I think could usefully 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 , where: ..." - RFC 9256 Section 2.1
says: "An SR Policy MUST be identified through the tuple ."

I don't understand how  is a "specialized form of"  that satisfies the RFC 9256 "MUST" requirement quoted above.
In particular, Color appears to be missing from . 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."

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-pim-sr-p2mp-policy-13, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-07-28):

From: The IESG
To: IETF-Announce
CC: draft-ietf-pim-sr-p2mp-policy@ietf.org, gunter@vandevelde.cc, mmcbride7@gmail.com, pim-chairs@ietf.org, pim@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Segment Routing Point-to-Multipoint Policy) to Proposed Standard


The IESG has received a request from the Protocols for IP Multicast WG (pim)
to consider the following document: - 'Segment Routing Point-to-Multipoint
Policy'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-07-28. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Point-to-Multipoint (P2MP) policy enables creation of P2MP trees for
  efficient multi-point packet delivery in a Segment Routing (SR)
  domain.  A SR P2MP Policy consists of Candidate Paths (CP) which
  define the topology of P2MP tree instances in each Candidate Path.  A
  P2MP tree instance is instantiated by a set of Replication segments.

  This document specifies the architecture, signaling, and procedures
  for SR P2MP Policies within Segment Routing over MPLS (SR-MPLS) and
  Segment Routing over IPv6 (SRv6) dataplane.  It defines the P2MP
  Policy construct, the roles of the root and leaf nodes, Candidate
  Paths and and how P2MP trees using Replication Segments are
  instantiated and maintained.  Additionally, it describes the required
  extensions for a controller to support P2MP path computation and
  provisioning.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/5017/

6/29/24 - MM - Authors continue to do a great job updating the draft to answer review questions.
And review below is still correct. It's ready.

This version is dated 4 July 2022.

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

Strong support from individuals across a variety of affiliations. No opposition.

2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

No controversy

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

Cisco has an implementation.

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

Yes, we've worked closely with spring. This draft is normative with RFC9524.
We've worked on this policy draft in PIM under agreement with the spring wg
due to pim's p2mp expertise and due to spring's draft backlog. The spring wg
has been included in all discussions and draft progression steps.


6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type

Not required.

7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

N/A

8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

ID Nits

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes

10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

No issues.

11. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards Track as is the normative draft in spring.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

5017 Cisco Systems, Inc.'s Statement about IPR

13. each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

No nits

15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

No

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

N/A

17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.

No

18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

No requirements for IANA

List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

N/A

Request for posting confirmation emailed to previous authors: Clarence Filsfils , Dan Voyer , Hooman Bidgoli , Mankamana Mishra , Rishabh Parekh , Zhaohui Zhang , pim-chairs@ietf.org

This version is dated 4 July 2022.

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

Strong support from individuals across a variety of affiliations. No opposition.

2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

No controversy

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

Cisco has an implementation.

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

Yes, we've worked closely with spring. This draft is normative with RFC9524.
We've worked on this policy draft in PIM under agreement with the spring wg
due to pim's p2mp expertise and due to spring's draft backlog. The spring wg
has been included in all discussions and draft progression steps.


6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type

Not required.

7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

N/A

8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

ID Nits

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes

10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

No issues.

11. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards Track as is the normative draft in spring.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

5017 Cisco Systems, Inc.'s Statement about IPR

13. each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

No nits

15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

No

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

N/A

17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.

No

18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

No requirements for IANA

List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

N/A

This version is dated 4 July 2022.

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

Strong support from individuals across a variety of affiliations. No opposition.

2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

No controversy

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

Cisco has an implementation.

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

Yes, we've worked closely with spring. This draft is normative with RFC9524.
We've worked on this policy draft in PIM under agreement with the spring wg
due to pim's p2mp expertise and due to spring's draft backlog. The spring wg
has been included in all discussions and draft progression steps.


6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type

Not required.

7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

N/A

8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

ID Nits

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes

10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

No issues.

11. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards Track as is the normative draft in spring.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

5017 Cisco Systems, Inc.'s Statement about IPR

13. each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

No nits

15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

No

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

N/A

17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.

No

18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

No requirements for IANA

List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

N/A

This version is dated 4 July 2022.

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

Strong support from individuals across a variety of affiliations. No opposition.

2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

No controversy

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

No known implementations

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

Yes, we've worked closely with spring. This draft is normative with RFC9524.
We've worked on this policy draft in PIM under agreement with the spring wg
due to pim's p2mp expertise and due to spring's draft backlog. The spring wg
has been included in all discussions and draft progression steps.


6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type

Not required.

7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

N/A

8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

ID Nits

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes

10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

No issues.

11. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards Track as is the normative draft in spring.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

5017 Cisco Systems, Inc.'s Statement about IPR

13. each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

No nits

15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

No

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

N/A

17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.

No

18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

No requirements for IANA

List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

N/A

This version is dated 4 July 2022.

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

Strong support from individuals across a variety of affiliations. No opposition.

2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

No controversy

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No

4. For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

No known implementations

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

Yes, we've worked closely with spring. This draft is normative with RFC9524.
We've worked on this policy draft in PIM under agreement with the spring wg
due to pim's p2mp expertise and due to spring's draft backlog. The spring wg
has been included in all discussions and draft progression steps.


6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type

Not required.

7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

N/A

8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

ID Nits

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes

10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

No issues.

11. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards Track as is the normative draft in spring.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

5017 Cisco Systems, Inc.'s Statement about IPR

13. each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

No nits

15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

No

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

N/A

17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.

No

18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

No

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

No requirements for IANA

List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

N/A