[pim] Mahesh Jethanandani's No Objection on draft-ietf-pim-s r-p2mp-policy-17: (with COMMENT)

Mahesh Jethanandani 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:
----------------------------------------------------------------------

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: <Root, Tree-ID, Instance-ID, Node-ID>, where
>    Root, Tree-ID of SR P2MP Policy and Instance-ID of the instance map
>    to Replication-ID of Replication segment and Node-ID is as defined in
>    [RFC9524].

Can the definition of Instance-ID and Node-ID be called out along with Root and
Tree-ID in a Terminology section instead of scattering them in the document?

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



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