Segment Routing MPLS Point-to-Multipoint (P2MP) Policy Ping
draft-ietf-pim-p2mp-policy-ping-25

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

I have a few points that I would like to discuss with the authors and the WG.

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.


discuss#2 This is related to a point of discussion that I've also raised on
the p2mp policy document. It arises from the lack of clarity on whether the
SR P2MP Policy construct is instantiated on the root node or not. There is
text in section 3.1.1 which seems to leave this critical aspect to
implementations and will result in interoperability problems. The base spec
needs to be very clear on this point and then this document updated to reflect
it. I believe having the construct instantiated in the root will greatly
benefit and simplify OAM operations. And things would then become very
similar to RSVP-TE P2MP trees?

< update for v20 > Note that the base document now clarifies that the P2MP Policy
construct is instantiated on the root. This document is not in sync with the
base - this point remains open for discussion.

Quoting some text from section 3.1.1 that is problematic:

"Only the Root node, where the P2MP SR Policy is programmed, may have visibility
into the leaf nodes."

"In the case of P2MP SR Policies, the Root of the tree may have full visibility
into the egress nodes if the P2MP SR Policy is PCC-initiated. If the P2MP SR
Policy is PCE-initiated, the Root may or may not have visibility into the egress
nodes, as this depends on the specific implementation and configuration of the
PCE. "

Further dependencies like the following seem unnecessary:

"Based on this, a P2MP SR Policy SHOULD follow the recommendations in Section
4.3.1 of [RFC6425], depending on the level of visibility the Root has into the
egress nodes. For example, in a PCC-initiated P2MP SR Policy, the Root can
learn egress node identities through Next-Generation MVPN procedures and BGP,
as described in [RFC6514]. In contrast, for a PCE-initiated P2MP SR Policy,
the PCE may not provide the egress node information to the Root, making this
process optional and implementation-specific."

The lack of clarity hurts interoperability and would affect operations in a
multi-vendor network. I would like to discuss why all of this cannot be
simplified by ensuring that the SR P2MP Policy construct is instantiated on
the root node.

discuss#3 My understanding is that the P2MP MPLS trees that are setup by MLDP
or RSVP-TE are hop by hop in nature. While in this case, the packet can travel
multiple hops from one node to the next intermediate node using that next
intermediate node's Prefix SID. In this case, how would operation like
traceroute (or even errors in the case of ping) work when the packet is
exposed at a node that is doing unicast forwarding and has no replication
segment context for that specific P2MP Tree? Now, section 3.1.3 is covering
this, but talking about it as "unicast SR domains" is very misleading since
there is only an SR domain and it is just that the specific P2MP tree context
is not required to be instantiated on a transit node. Does this mean that this
mechanism works only when the P2MP Tree is setup up hop-by-hop? If so, this
should be clearly called out as a caveat upfront and the text in 3.1.3 updated
appropriately.

< update for v20 > This point remains open for discussion.

[Ballot comment]
Please also find below some comments provided inline in the idnits format of
the v18 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.

Note: the comments are updated by removing those that were addressed in v20

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).

142 3.  Motivation

144   A P2MP Policy and its corresponding Replication Segments are
145   typically provisioned via a centralized controller or configured
146   using NETCONF/YANG or CLI.  The root and the leaves are discovered in

Perhaps you mean that the network topology that includes the root and
leaves is discovered?


319   *  Address Length: (1 octet) specifying the length of the Root
320       Address in octets (4 octets for IPv4, 16 octets for IPv6).

reserved is missing; also I believe it MBZ

< update for v20 > Still needs a change ... s/and it should be/and - this is to make the "MUST" apply to both sender and receiver.

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

I have a few points that I would like to discuss with the authors and the WG.

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.


discuss#2 This is related to a point of discussion that I've also raised on
the p2mp policy document. It arises from the lack of clarity on whether the
SR P2MP Policy construct is instantiated on the root node or not. There is
text in section 3.1.1 which seems to leave this critical aspect to
implementations and will result in interoperability problems. The base spec
needs to be very clear on this point and then this document updated to reflect
it. I believe having the construct instantiated in the root will greatly
benefit and simplify OAM operations. And things would then become very
similar to RSVP-TE P2MP trees?

< update for v19 > Note that the base document now clarifies that the P2MP Policy
construct is instantiated on the root. This document is not in sync with the
base - this point remains open for discussion.

Quoting some text from section 3.1.1 that is problematic:

"Only the Root node, where the P2MP SR Policy is programmed, may have visibility
into the leaf nodes."

"In the case of P2MP SR Policies, the Root of the tree may have full visibility
into the egress nodes if the P2MP SR Policy is PCC-initiated. If the P2MP SR
Policy is PCE-initiated, the Root may or may not have visibility into the egress
nodes, as this depends on the specific implementation and configuration of the
PCE. "

Further dependencies like the following seem unnecessary:

"Based on this, a P2MP SR Policy SHOULD follow the recommendations in Section
4.3.1 of [RFC6425], depending on the level of visibility the Root has into the
egress nodes. For example, in a PCC-initiated P2MP SR Policy, the Root can
learn egress node identities through Next-Generation MVPN procedures and BGP,
as described in [RFC6514]. In contrast, for a PCE-initiated P2MP SR Policy,
the PCE may not provide the egress node information to the Root, making this
process optional and implementation-specific."

The lack of clarity hurts interoperability and would affect operations in a
multi-vendor network. I would like to discuss why all of this cannot be
simplified by ensuring that the SR P2MP Policy construct is instantiated on
the root node.

discuss#3 My understanding is that the P2MP MPLS trees that are setup by MLDP
or RSVP-TE are hop by hop in nature. While in this case, the packet can travel
multiple hops from one node to the next intermediate node using that next
intermediate node's Prefix SID. In this case, how would operation like
traceroute (or even errors in the case of ping) work when the packet is
exposed at a node that is doing unicast forwarding and has no replication
segment context for that specific P2MP Tree? Now, section 3.1.3 is covering
this, but talking about it as "unicast SR domains" is very misleading since
there is only an SR domain and it is just that the specific P2MP tree context
is not required to be instantiated on a transit node. Does this mean that this
mechanism works only when the P2MP Tree is setup up hop-by-hop? If so, this
should be clearly called out as a caveat upfront and the text in 3.1.3 updated
appropriately.

< update for v19 > This point remains open for discussion.

[Ballot comment]
Please also find below some comments provided inline in the idnits format of
the v18 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.

Note: the comments are updated by removing those that were addressed in v19

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).

94 1.  Introduction

96   A P2MP Policy can have one or multiple Candidate Paths (CPs).  The CP

Please align terminologies with the SR P2MP policy draft. Term is SR P2MP
Policy, then there is P2MP Tree (Instance), etc. Would be nice to avoid
introducing new terms (e.g., TI) in this document related to any of the constructs.

< update for v19 > Please use the term "SR P2MP Policy" in this document to be consistent with the base document. Thanks for aligning the other terms.


142 3.  Motivation

144   A P2MP Policy and its corresponding Replication Segments are
145   typically provisioned via a centralized controller or configured
146   using NETCONF/YANG or CLI.  The root and the leaves are discovered in

Perhaps you mean that the network topology that includes the root and
leaves is discovered?


319   *  Address Length: (1 octet) specifying the length of the Root
320       Address in octets (4 octets for IPv4, 16 octets for IPv6).

reserved is missing; also I believe it MBZ

< update for v19 > It should be ... MUST be set to zero by sender and ignored by the receiver (or something like that).

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

I have a few points that I would like to discuss with the authors and the WG.

discuss#1 This one should be easy to fix. Since the document is about MPLS and
not SRv6, the correct title for this document would be "Segment Routing
MPLS Point-to-Multipoint (P2MP) Policy Ping" ?

discuss#2 This is related to a point of discussion that I've also raised on
the p2mp policy document. It arises from the lack of clarity on whether the
SR P2MP Policy construct is instantiated on the root node or not. There is
text in section 3.1.1 which seems to leave this critical aspect to
implementations and will result in interoperability problems. The base spec
needs to be very clear on this point and then this document updated to reflect
it. I believe having the construct instantiated in the root will greatly
benefit and simplify OAM operations. And things would then become very
similar to RSVP-TE P2MP trees?

Quoting some text from section 3.1.1 that is problematic:

"Only the Root node, where the P2MP SR Policy is programmed, may have visibility
into the leaf nodes."

"In the case of P2MP SR Policies, the Root of the tree may have full visibility
into the egress nodes if the P2MP SR Policy is PCC-initiated. If the P2MP SR
Policy is PCE-initiated, the Root may or may not have visibility into the egress
nodes, as this depends on the specific implementation and configuration of the
PCE. "

Further dependencies like the following seem unnecessary:

"Based on this, a P2MP SR Policy SHOULD follow the recommendations in Section
4.3.1 of [RFC6425], depending on the level of visibility the Root has into the
egress nodes. For example, in a PCC-initiated P2MP SR Policy, the Root can
learn egress node identities through Next-Generation MVPN procedures and BGP,
as described in [RFC6514]. In contrast, for a PCE-initiated P2MP SR Policy,
the PCE may not provide the egress node information to the Root, making this
process optional and implementation-specific."

The lack of clarity hurts interoperability and would affect operations in a
multi-vendor network. I would like to discuss why all of this cannot be
simplified by ensuring that the SR P2MP Policy construct is instantiated on
the root node.

discuss#3 My understanding is that the P2MP MPLS trees that are setup by MLDP
or RSVP-TE are hop by hop in nature. While in this case, the packet can travel
multiple hops from one node to the next intermediate node using that next
intermediate node's Prefix SID. In this case, how would operation like
traceroute (or even errors in the case of ping) work when the packet is
exposed at a node that is doing unicast forwarding and has no replication
segment context for that specific P2MP Tree? Now, section 3.1.3 is covering
this, but talking about it as "unicast SR domains" is very misleading since
there is only an SR domain and it is just that the specific P2MP tree context
is not required to be instantiated on a transit node. Does this mean that this
mechanism works only when the P2MP Tree is setup up hop-by-hop? If so, this
should be clearly called out as a caveat upfront and the text in 3.1.3 updated
appropriately.

discuss#4 This is an easy one to fix - the following is not a normative
reference, please move to informative.

[IANA-AF]
"IANA Assigned Port Numbers, "http://www.iana.org/assignments/address-family-numbers"".

[Ballot comment]
Please also find below some comments provided inline in the idnits format of
the v18 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).

94 1.  Introduction

96   A P2MP Policy can have one or multiple Candidate Paths (CPs).  The CP

Please align terminologies with the SR P2MP policy draft. Term is SR P2MP
Policy, then there is P2MP Tree (Instance), etc. Would be nice to avoid
introducing new terms (e.g., TI) in this document related to any of the constructs.

97   with highest preference is designated as the active CP, while all
98   other CPs are the backup CPs.  To enable seamless global optimization

The CP preference is only the first tiebreaker in the selection of
active CP. Perhaps "One of the CPs (e.g., with highest preference) is
designated ..."

131   [draft-ietf-pim-sr-p2mp-policy] section 2, defines terms and concepts
132   specific to SR P2MP Policy including the CP and the TI.

I couldn't find TI defined in that document. Please introduce in the base.


142 3.  Motivation

144   A P2MP Policy and its corresponding Replication Segments are
145   typically provisioned via a centralized controller or configured
146   using NETCONF/YANG or CLI.  The root and the leaves are discovered in

Perhaps you mean that the network topology that includes the root and
leaves is discovered?


161   This diagnostic process can be initiated from the node responsible
162   for establishing the P2MP Policy, ensuring proactive monitoring and
163   rapid fault detection.

Is use of "rapid" appropriate here? Rapid as in BFD?

295 3.2.1.1.  P2MP Policy CP FEC Stack Sub-TLVs

297   The P2MP Policy MPLS Candidate Path sub-TLV value field follows the

Please consider changing the name of this TLV since it is not about CP
but about the P2MP Tree instance under a CP. Perhaps "SR P2MP Policy Tree FEC
Stack sub-TLV" ... or something similar. I was trying to not make it too long
by including the CP in there, but that would also be ok.


298   format specified in Section 2 of [draft-ietf-pim-sr-p2mp-policy].
299   The structure of this sub-TLV is illustrated in the figure below.

Please add text to clarify here that the CP identifiers are not
required since the Instance-ID is unique within the SR P2MP Policy context
(with a reference to section 2.3 of the p2mp policy draft).


315   *  Address Family: (2 octets) IPv4/IPv6 ADDRESS FAMILY NUMBERS as
316       specified in [IANA-AF] , indicating the address family of the
317       Root.

Are all AFIs allowed? I believe it has to allow only IPv4 or IPv6?


319   *  Address Length: (1 octet) specifying the length of the Root
320       Address in octets (4 octets for IPv4, 16 octets for IPv6).

reserved is missing; also I believe it MBZ

382 5.  IANA Consideration

384   IANA has assigned a TEMPORARY code point for the "P2MP Policy MPLS
385   Candidate Path" Sub-TLV Name.  This Sub-TLV is assigned from TLV type
386   1 (Target FEC Stack) from the "Multi-Protocol Label Switching (MPLS)
387   Label Switched Paths (LSPs) Ping Parameters" registry group.  The
388   Sub-TLVs for TLV type 1 are listen under "Sub-TLVs for TLV Types 1,

s/listen/listed

397 6.  Security Considerations

399   Overall, the security needs for P2MP policy ping are the same as
400   [RFC8029].  The P2MP policy ping is susceptible to the same three
401   attack vectors as explained in RFC8029 section 5.  The same
402   procedures and recommendations explained in [RFC8029] section 5
403   should be taken and implemented to mitigate these attack vectors for
404   P2MP policy Ping as well.

Should this not include reference to the security considerations of
the SR P2MP policy draft as well?

Additional note from IANA (also sent to authors):

Please add the name of the registry (as it appears on the website) to the IANA Considerations section.

Please make either this change or another change that replaces "registry" with "registry group" and updates the affected subregistry name:

OLD: from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "TLVs and sub-TLVs" sub-registry.

NEW: from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry group, "Sub-TLVs for TLV Types 1, 16, and 21" subregistry (beneath the "TLVs" registry).

For reference, please see

https://www.iana.org/assignments/mpls-lsp-ping-parameters

[Ballot comment]
Understandably, this document is fairly deep in the SR/MPLS stack and assumes a familiarity with many basic terms from that technology. Thank you for referencing sources for much of your terminology in Section 1.1. It would be helpful to spell out some of these initialisms (CP, TI, etc.), particularly as they are used in their expanded form later in the document. I also do not see the term LSP referenced here; perhaps a reference to RFC 3031 Sections 2.2 and 2.3 should be added to this section, possibly with a list of terms which are defined there and used in this document?

[Ballot comment]

Thanks to Wes Hardaker for their secdir review.

I found the referenced security considerations in RFC 8029 to be quite good.  In fact, it discusses rate limiting to avoid DOS attacks.
[Note:  I wasn't going to send this ballot to the list, but it might help w/ one of the discusses]

[Ballot comment]
The following set of COMMENTS is mostly non-blocking comments, which the authors should consider as part of improving the readability of the draft.

"Abstract", paragraph 2
>    Segment Routing Point-to-Multipoint (SR-P2MP) Policies are used to
>    define and manage explicit P2MP paths within a network.  These
>    policies are typically calculated via a controller-based mechanism
>    and installed via, e.g., a Path Computation Element (PCE).  In other
>    cases these policies can be installed via using NETCONF/YANG or CLI.
>    They are used to steer multicast traffic along optimized paths from a
>    Root to a set of Leaf routers.
>
>    This document defines extensions to Ping and Traceroute mechanisms
>    for SR-P2MP Policy with MPLS encapsulation to provide OAM
>    (Operations, Administration, and Maintenance) capabilities.  The
>    extensions enable operators to verify connectivity, diagnose failures
>    and troubleshoot forwarding issues within P2MP Policy multicast
>    trees.
>
>    By introducing new mechanisms for detecting failures and validating
>    path integrity, this document enhances the operational robustness of
>    P2MP multicast deployments.  Additionally, it ensures that existing
>    MPLS and SR-based OAM tools can be effectively applied to networks
>    utilizing P2MP Policies.

I believe the Abstract is too long and can easily be shortened. How about saying:

"Segment Routing Point-to-Multipoint (SR-P2MP) Policies are used to define and manage explicit P2MP paths within a network. This document defines extensions to Ping and Traceroute mechanisms for SR-P2MP Policy with MPLS encapsulation to provide OAM (Operations, Administration, and Maintenance) capabilities."

Or something similar. All the justification for why and how it is improves OAM can go into the introduction.

Section 3, paragraph 1
>    A P2MP Policy and its corresponding Replication Segments are
>    typically provisioned via a centralized controller or configured
>    using NETCONF/YANG or CLI.  The root and the leaves are discovered in
>    accordance with [draft-ietf-pim-sr-p2mp-policy] and the multicast
>    tree is computed from the root to the leaves.  However, there is no
>    underlay signaling protocol to distribute the P2MP Policy from the
>    root to the leaf routers.  Consequently, when a P2MP tree fails to
>    deliver user traffic, identifying the failure can be challenging
>    without ping and traceroute mechanisms to isolate faults along the
>    tree.
>
>    To address this challenge, P2MP Policy ping and traceroute can be
>    utilized to detect and localize faults within the P2MP tree and its
>    associated Replication Segments, as defined in [RFC9524].  These OAM
>    tools enable periodic ping operations to verify connectivity between
>    the root and the leaves.  In cases where a ping fails, a traceroute
>    can be initiated to determine the point of failure along the tree.
>    This diagnostic process can be initiated from the node responsible
>    for establishing the P2MP Policy, ensuring proactive monitoring and
>    rapid fault detection.

I beleive the Motivation section should come before the text in Introduction as it is not clear reading the Introduction why this extension is needed in the first place till you read the Motivation section.

Section 3.1, paragraph 0
>    This document specifically addresses Replication Segments that use
>    MPLS encapsulation.  Future documents will extend support for
>    Replication Segments using SRv6 encapsulation.  Packets are processed
>    based on the standard behavior when their Time-to-Live (TTL) expires
>    or when they reach the egress (leaf) router.  The appropriate
>    response is sent back to the root node following the procedures
>    outlined in [RFC6425].

Are the first two statements a repeat of the statements in the last paragraph of the Introduction?

Section 3.1.1, paragraph 0
>    1.  Egress Address P2MP Responder Sub-TLVs: Multicast LDP, as per
>        section 3.2.1 of [RFC6425], does not allow for the inclusion of
>        Egress Address P2MP Responder Sub-TLVs, as upstream LSRs lack
>        visibility into downstream leaf nodes.  Similarly, P2MP SR
>        Policies often rely on a Path Computation Element (PCE) for
>        programming transit routers, meaning these routers do not have
>        knowledge of the leaf nodes.  Only the Root node, where the P2MP
>        SR Policy is programmed, may have visibility into the leaf nodes.
>        Consequently, these Sub-TLVs SHOULD NOT be used when an echo
>        request carries a P2MP Policy MPLS Candidate Path FEC.  If a node
>        receives these TLVs in an echo request, then it will not respond
>        since it is unaware of whether it lies on the path to the address
>        in the sub-TLV.

There is multiple use of "these" in this paragraph, and it not clear what "these" is referring to. For example, it is better to say "transit routers" than "these routers". Similarly, what does "these Sub-TLVs" " or "these TLVs" refer to?

No reference entries found for these items, which were mentioned in the text:
[RFC7942].

-------------------------------------------------------------------------------
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.1, paragraph 0
>    Ping/Traceroute packets are forwarded on the P2MP Policy, on a
>    specific CP and its TIs toward the designated leaf routers.  These
>    packets are replicated at the replication point based on the
>    Replication Segment forwarding information on the corresponding
>    router.

s/forwarded on the P2MP Policy/forwarded based upon the P2MP Policy/

Section 3.1.1, paragraph 0
>    The procedures in [RFC6425] define fault detection and isolation
>    mechanisms for P2MP MPLS LSPs.  These mechanisms extend the LSP ping
>    techniques described in [RFC8029] such that they may be applied to
>    P2MP MPLS LSPs, ensuring alignment with existing fault management
>    tools.  [RFC6425] emphasizes the reuse of existing LSP ping
>    mechanisms designed for Point-to-Point P2P LSPs, adapting them to
>    P2MP MPLS LSPs to facilitate seamless implementation and network
>    operation.

s/These mechanisms/The mechanisms defined in this document/

Duplicate normative references to: rfc2119.


These URLs in the document can probably be converted to HTTPS:

* http://www.iana.org/assignments/address-family-numbers

"Table of Contents", paragraph 1
> andidate Paths (CPs). The CP with highest preference is designated as the ac
>                                  ^^^^^^^
A determiner may be missing.

Section 3.1.2, paragraph 1
> eplication Segment is transiting over a Unicast SR domain, it must be only pr
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.1, paragraph 4
>  of the Root. * Address Length: (1 octets) specifying the length of the Root
>                                  ^^^^^^^^
Please verify that the plural noun "octets" is in agreement with the quantifier
"1". Did you mean to use the singular form?

[Ballot discuss]

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

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address), 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 concise 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

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Section 3.2.1.1

The field 'Reserved' is not specified, please use the usual "MUST be set to 0 on transmission and ignored on reception". It is important for potential extensions.

[Ballot comment]

## COMMENTS (non-blocking)

### Title

Should 'MPLS' be included in the title as opposed to "SRv6" ?

### Section 1

The 1st paragraph describes protocols not defined in this I-D. Please add one or more informational references.

### Section 3.1

As SRv6 was already stated 'out-of-scope' in section 1, there is no need for `Future documents will extend support for Replication Segments using SRv6 encapsulation.`

Please be specific about the TTL ? Is it the MPLS header field or the IP header field ?

### Section 5

Please use a informational reference URI to the specific IANA registry.

[Ballot comment]
Hi Hooman, Zafar, Jeffrey, Anuj, and Dan,

Thank you for the effort put into this document.

Also, thanks to Linda Dunbar for the OPSDIR. I’m not reiterating any of the points raised by Linda. I trust that agreed changes will be made to the spec to reflect the ongoing discussion.

Having some examples to illustrate the use of the extensions would be helpful.

Please find below some comments; major ones are tagged with (*). 

# Candidate Policy (*)

The following is not consistent with the definition of CP:

OLD: Each P2MP Policy can have multiple Candidate Paths (CPs). 

Please consider updating to

NEW: A P2MP Policy can have one or multiple Candidate Paths (CPs). 

# Inappropriate use of normative language

CURRENT:
  The CP
  with highest preference is designated as the active CP, while all
  other CPs are the backup CPs.  To enable seamless global optimization
  a CP MAY consist of multiple Path Instances (PIs),

Please s/MAY/may

# Root, Root-ID, rootID (*)

This document uses rootID, which deviates from draft-ietf-pim-sr-p2mp-policy.

draft-ietf-pim-sr-p2mp-policy says:

  A SR P2MP Policy is uniquely identified by the tuple ,
  where:

  *  Root: The IP address of the Root node of P2MP trees instantiated
      by the SR P2MP Policy.  This is equivalent to the Headend of SR
      Policy identifier tuple.

+ have one instance of Root-ID

  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-

(1) I guess this is an issue to be fixed in draft-ietf-pim-sr-p2mp-policy.

(2) Both specs have to be consistent. Please fix that.

# Deviation vs base P2MP SR Policy Spec

OLD:
  A PI is identified on the Root node by the rootID
  which is the Root's node IP address, tree ID and PI's instance ID.

NEW:
  A PI is identified on the Root node by the Root-ID
  which is the Root's node IP address, Tree-ID and PI's Instance-ID.

# Deviation, again

CURRENT:
  [draft-ietf-pim-sr-p2mp-policy] section 2, defines terms and concepts
  specific to SR P2MP Policy including the CP and the PI.

There is no PI thing there :-(

# Remind behavior

CURRENT:
      Consequently, these Sub-TLVs SHOULD NOT be used when an echo
      request carries a P2MP Policy MPLS Candidate Path FEC.

Can we remind in the text what happens if these were included?

# Concretely

CURRENT:
  P2MP SR Policies SHOULD adhere to the common procedures specified in
  [RFC6425] for P2MP MPLS LSPs. 

What does “adhere” concretely means?

# Problematic MUSTs

CURRENT:
  The Ping and Traceroute packets MUST be forwarded along
  the specified CP and its PI, traversing the associated Replication
  Segments.  When a downstream node receives a Ping or Traceroute
  packet, it MUST process the request and generate a response even if
  the CP and its PI are not currently the active path.

These two absolute MUSTs may be problematic as there are conditions where this should not be the case. A typical example, is when there is a rate-limit in place to protect a node against overload/DDoS, etc.

I would adjust these two accordingly.

# Inappropriate use of normative language

CURRENT:
  For
  example, when a P2MP Policy Ping or Traceroute packet between two
  Replication Segment is transiting over a Unicast SR domain, it MUST
  be only processed on Replication Segments, based on the Replication
  SID and its TTL value. 

This is an example. Please s/MUST/must

# Replication ID TTL (*)

CURRENT:
  The SR domain itself SHOULD be treated as a
  single hop, meaning that the Replication SID TTL MUST be decremented
  by one before pushing the Unicast SR SIDs onto the Replication SID
  stack. 

(1) Under which condition the SHOULD can be ignored?

(2) I failed to find where “Replication SID TTL” is defined. Can you please clarify that? Thanks.

# Address Family (*)

CURRENT:
  *  Address Family: (2 octets) containing a value from ADDRESS FAMILY
      NUMBERS in [IANA-AF] , indicating the address family of the Root
      Address.

(1) Shouldn’t this be restricted to IPv4/IPv6?

(2) There is no “Root Address” field. Root is defined in the base spec as an address. Please update accordingly.






# Please find below some minor comments

## Better title that reflect the content

OLD: P2MP Policy Ping
NEW: Segment Routing Point-to-Multipoint (P2MP) Policy Ping


## Abstract

OLD:
  Segment Routing Point-to-Multipoint (SR-P2MP) Policies are used to
  define and manage explicit P2MP paths within a network.  These
                                                ^^^^^^^^
  policies are typically calculated via a controller-based mechanism
  and installed via a Path Computation Element (PCE).  In other cases
                ^^^^^^^^^^^^
  these policies can be installed manually via using YANG models or CLI.
                        ^^^^^^^^^^^^^^^^^^   
  They are used to steer multicast traffic along optimized paths from a
  Root to a set of Leaf routers.

  This document defines extensions to Ping and Traceroute mechanisms
  for SR-P2MP Policy with MPLS encapsulation to provide OAM
  (Operations, Administration, and Maintenance) capabilities.  The
  proposed extensions enable operators to verify connectivity, diagnose
  ^^^^^^^^
  failures and troubleshoot forwarding issues within P2MP Policy
  multicast trees.


NEW:
  Segment Routing Point-to-Multipoint (SR-P2MP) Policies are used to
  define and manage explicit P2MP paths within an SR domain.  These
  policies are typically calculated via a controller-based mechanism
  and installed via, e.g., a Path Computation Element (PCE).  In other cases
  these policies can be installed via using NETCONF/YANG or CLI.
  They are used to steer multicast traffic along optimized paths from a
  Root to a set of Leaf routers.

  This document defines extensions to Ping and Traceroute mechanisms
  for SR-P2MP Policy with MPLS encapsulation to provide OAM
  (Operations, Administration, and Maintenance) capabilities.  The
  extensions enable operators to verify connectivity, diagnose
  failures and troubleshoot forwarding issues within P2MP Policy
  multicast trees.

## Introduction

OLD:
  This specification applies exclusively to Replication Segments
  (Replication SIDs) that use MPLS encapsulation for forwarding and
    ^^^^^^^^^^^^^^^^
  does not cover Segment Routing over IPv6 (SRv6).  The mechanisms
  described herein build upon the concepts established in [RFC6425] for
  P2MP MPLS Operations, Administration, and Maintenance (OAM).  All
  consideration and limitations described in section 6 of [RFC6425]
              ^^^^^^
  applies apply to this document as well.
  ^^^^^^

NEW:
  This specification applies exclusively to Replication Segments
  (Replication-SIDs) that use MPLS encapsulation for forwarding and
  does not cover Segment Routing over IPv6 (SRv6).  The mechanisms
  described herein build upon the concepts established in [RFC6425] for
  P2MP MPLS Operations, Administration, and Maintenance (OAM).  All
  considerations and limitations described in section 6 of [RFC6425]
  apply to this document as well.

## Section 3

OLD:
  A P2MP Policy and its corresponding Replication Segments are
  typically provisioned via a centralized controller or configured
  statically using YANG models or CLI.
  ^^^^^^^^^^^^^^^^^^^^

NEW:
  A P2MP Policy and its corresponding Replication Segments are
  typically provisioned via a centralized controller or configured
  using NETCONF/YANG or CLI. 


## Section 3.1

Which mechanisms extend 8029?

CURRENT:
  The procedures in [RFC6425] define fault detection and isolation
  mechanisms for P2MP MPLS LSPs.  These mechanisms extend the LSP ping
  techniques described in [RFC8029] such that they may be applied to
  P2MP MPLS LSPs, ensuring alignment with existing fault management
  tools. 

Cheers,
Med

[Ballot discuss]
Thanks for preparing this document. Please find below one blocking DISCUSS point (trivial to address).

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I think that the document would be improved with a small addition here, but can be convinced otherwise.

As I understand, the described mechanism generates a response over a protocol that is not rate-limited or congestion controlled. Therefore, I'd like to see text that guards against a Denial-of-Service attack to send MPLS echo requests/replies that seek to increase their workload. As such, I suggest a warning/scoping is added that this traffic needs to avoid sending/processing such requests, possibly in the last para of the introduction.

RFC 6425 includes some text that might be a suitable starting point:

  As is described in [RFC4379], to avoid potential denial-of-service
  attacks, it is RECOMMENDED to regulate the LSP ping traffic passed to
  the control plane.  A rate limiter should be applied to the incoming
  LSP ping traffic.

[Ballot discuss]
Thanks for preparing this document.

As I understand, the described mechanism generates a response over a protocol that is not rate-limited or congestion controlled. Therefore, I'd like to see text that guards against a Denial-of-Service attack to send MPLS echo requests/replies that seek to increase their workload. As such, I suggest a warning/scoping is added that this traffic needs to avoid sending/processing such requests, possibly in the last para of the introduction.

RFC 6425 includes some text that might be a suitable starting point:

  As is described in [RFC4379], to avoid potential denial-of-service
  attacks, it is RECOMMENDED to regulate the LSP ping traffic passed to
  the control plane.  A rate limiter should be applied to the incoming
  LSP ping traffic.

[Ballot comment]
NiT:

/As specified in section 3.2 of [RFC6425] ,/As specified in section 3.2 of [RFC6425],/
- Please remove space befor comma.

Request for IETF Last Call review by OPSDIR Completed: Has Issues. Reviewer: Linda Dunbar. Sent review to list. Submission of review completed at an earlier date.

Request for IETF Last Call review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour. Sent review to list. Submission of review completed at an earlier date.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-pim-p2mp-policy-ping-11. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the Sub-TLVs for TLV Types 1, 16, and 21 sub-registry of the TLVs registry in the Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registry group located at:

https://www.iana.org/assignments/mpls-lsp-ping-parameters/

the existing early allocation for:

Sub-type: 41
Sub-TLV Name: P2MP Policy MPLS Candidate Path

will be made permanent and its reference changed to [ RFC-to-be ].

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the action that will be performed.

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-14):

From: The IESG
To: IETF-Announce
CC: draft-ietf-pim-p2mp-policy-ping@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:  (P2MP Policy Ping) to Proposed Standard


The IESG has received a request from the Protocols for IP Multicast WG (pim)
to consider the following document: - 'P2MP Policy Ping'
  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-14. 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


  SR Point-to-Multipoint (P2MP) Policies are used to define and manage
  explicit P2MP paths within a network.  These policies are typically
  calculated via a controller-based mechanisms and installed via a Path
  Computation Element (PCE).  In other cases these policies can be
  installed manually via YANG modles or CLI.  They are used to steer
  multicast traffic along optimized paths from a Root to a set of Leaf
  routers.

  This document defines extensions to Ping and Traceroute mechanisms
  for Segment Routing (SR) P2MP Policy with MPLS encapsulation to
  provide OAM (Operations, Administration, and Maintenance)
  capabilities.  The proposed extensions enable operators to verify
  connectivity, diagnose failures and troubleshoot forwarding issues
  within P2MP Policy multicast trees.

  By introducing new mechanisms for detecting failures and validating
  path integrity, this document enhances the operational robustness of
  P2MP multicast deployments.  Additionally, it ensures that existing
  MPLS and SR-based OAM tools can be effectively applied to networks
  utilizing P2MP Policies.




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


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

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

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

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?

Broad agreement.

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

No.

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][3] recommends) or elsewhere
  (where)?

Nokia has implemented [draft-ietf-pim-sr-p2mp-policy-09] and
[RFC9524].  In addition, Nokia has implemented P2MP policy ping as
defined in this draft to verify the end to end connectivity of a P2MP
tree in segment routing domain.  The implementation supports SR-MPLS
encapsulation and has all the MUST and SHOULD clause in this draft.
The implementation is at general availability maturity and is
compliant with the latest version of the draft.  The documentation
for implementation can be found at Nokia help and the point of
contact is hooman.bidgoli@nokia.com.


## Additional Reviews

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.

The draft has been review by the mpls wg. A joint wglc was called on both the
spring and pim mailing lists.

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

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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][5]?

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.

N/A

## Document Shepherd Checks

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][6]. 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][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards Track which is proper.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? 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.

Yes. One IPR declaration has been made by Huawei.

13. Has 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][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All good.

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

Nope.

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][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

N/A.

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?

N/A.

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.

N/A.

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][11]).

Looks good. One code point requested.

21. 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

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

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?

Broad agreement.

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

No.

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][3] recommends) or elsewhere
  (where)?

Nokia has implemented [draft-ietf-pim-sr-p2mp-policy-09] and
[RFC9524].  In addition, Nokia has implemented P2MP policy ping as
defined in this draft to verify the end to end connectivity of a P2MP
tree in segment routing domain.  The implementation supports SR-MPLS
encapsulation and has all the MUST and SHOULD clause in this draft.
The implementation is at general availability maturity and is
compliant with the latest version of the draft.  The documentation
for implementation can be found at Nokia help and the point of
contact is hooman.bidgoli@nokia.com.


## Additional Reviews

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.

The draft has been review by the mpls wg. A joint wglc was called on both the
spring and pim mailing lists.

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

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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][5]?

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.

N/A

## Document Shepherd Checks

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][6]. 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][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards Track which is proper.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? 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.

Yes. One IPR declaration has been made by Huawei.

13. Has 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][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All good.

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

Nope.

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][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

N/A.

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?

N/A.

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.

N/A.

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][11]).

Looks good. One code point requested.

21. 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

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

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?

Broad agreement.

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

No.

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][3] recommends) or elsewhere
  (where)?

Nokia has implemented [draft-ietf-pim-sr-p2mp-policy-09] and
[RFC9524].  In addition, Nokia has implemented P2MP policy ping as
defined in this draft to verify the end to end connectivity of a P2MP
tree in segment routing domain.  The implementation supports SR-MPLS
encapsulation and has all the MUST and SHOULD clause in this draft.
The implementation is at general availability maturity and is
compliant with the latest version of the draft.  The documentation
for implementation can be found at Nokia help and the point of
contact is hooman.bidgoli@nokia.com.


## Additional Reviews

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.

The draft has been review by the mpls wg. A joint wglc was called on both the
spring and pim mailing lists.

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

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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][5]?

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.

N/A

## Document Shepherd Checks

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][6]. 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][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards Track which is proper.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? 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.

Yes. One IPR declaration has been made by Huawei.

13. Has 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][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

All good.

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

Nope.

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][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

N/A.

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?

N/A.

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.

N/A.

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][11]).

Looks good. One code point requested.

21. 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

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/