[pim] Mike Bishop's No Objection on draft-ietf-pim-sr-p2mp-p olicy-17: (with COMMENT)

Mike Bishop has entered the following ballot position for
draft-ietf-pim-sr-p2mp-policy-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/



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



_______________________________________________
pim mailing list -- [email protected]
To unsubscribe send an email to [email protected]