[pim] Re: Éric Vyncke's No Objection on draft-ietf-pi m-sr-p2mp-policy-16: (with COMMENT)

Eric,
Thanks for the review. Comments inline @ [RP]

-Rishabh

On Thu, Aug 14, 2025 at 2:31 AM Éric Vyncke via Datatracker <
[email protected]> wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-pim-sr-p2mp-policy-16: No Objection
>
> ----------------------------------------------------------------------
> 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.
>

[RP] Will do in next revision

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

[RP]  Bud node is already defined in the Terminology section of RFC 9524.
Hence the reference.


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

[RP] I am not clear about this comment. Do you mean it is ambiguous whether
this document applies to both SR-MPLS and SRv6 data plane? For now, I have
removed "both" from "... can be instantiated for both SR-MPLS and SRv6 data
planes, ...". I hope that clarifies it.


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

[RP] Fixed.


>
> ### Section 2.1
>
> Should there be a reference for `Color of SR Policy identifier` ?
>

[RP] First paragraph of Section 2 references SR Policy RFC 9256. IMO, the
context of use "Headend", "Color" and "Endpoint" of SR Policy identifier
tuple in the text should be clear here.


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

[RP] SR P2MP Policy is meant to create P2MP transport trees in SR domain to
carry overlay traffic. The overlay traffic can be IP multicast groups or L2
frames that require multipoint distribution  (further specified in
draft-ietf-bess-sr-mvpn-evpn). There can be N:1 mapping between overlay
traffic streams and a P2MP tree instance created from a SR P2MP policy.
Hence, SR P2MP Policy identifier does not have a multicast group, or any
other overlay traffic identifier component in it.


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

[RP] The term 'tuple' borrowed from SR Policy RFC.


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

[RP] I will add similar text for SRv6 and change the title of the
sub-section.

>
> ### Section 4.1
>
> What is `SRLG` ? Please expand and perhaps add an informative reference.
>

[RP] Done.

>
> ### Section 4.5.1
>
> Should there be informative references for the protection mechanisms ?
>

[RP] Added references.


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

[RP] Removed the reference. Though RFC 9524 has the same reference :)


>
> ### Appendix A
>
> Please expand `PSP` and `USD` (plus add references ?).
>

[RP] I have expanded the terms but the beginning of the section expects the
reader to be familiar with RFC 8986 and both of these flavors of End
function are covered there.

>
> 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 ;-)
>
>
>
> _______________________________________________
> pim mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

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