[RTG-DIR]RTGDIR Early review : draft-ietf-pim-gaap-18

[Alexander Vainshtein <[e-mail]>]

Hello

I have been selected to do a routing directorate "early" review of this draft: draft-ietf-pim-gaap-18<https://datatracker.ietf.org/doc/html/draft-ietf-pim-gaap-18>,

The routing directorate will, on request from the working group chair, perform an "early" review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft's lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached.

According to the IETF Datatracker, the draft has been submitted to the IESG for publication. Therefore, my focus for the review was to determine whether the document is ready to be published. Please consider my comments along with the other working group last call comments.

For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir<https://wiki.ietf.org/en/group/rtg/RtgDir>.

Document: draft-ietf-pim-gaap-18<https://datatracker.ietf.org/doc/html/draft-ietf-pim-gaap-18>
Reviewer: Alexander ("Sasha") Vainshtein (@[e-mail]<mailto:[e-mail]>)
Review date: 02-Aug-2026
Intended Status: Experimental

Summary:

This document is basically ready for publication but has nits that should be resolved prior to its being approved for publication.

Please keep in mind that multicast is not exactly my area of expertise, so some questions may be naïve or not important.

Unfortunately, I have not completed discussion of my comments below with the authors due to the deadline set for this review.

Comments:

The draft is well written and, mainly, easy to read and understand even for a non-expert. But there are several points where its readability could be improved.


1.       I have been looking for some time for the specification of the destination IP address of the GAAP Claim messages. Eventually I have found that Section 9.2 requests IANA to allocate one IPv4 well-known multicast address from the Internetwork Control Block and one IPv6 Multicast address from the Variable Scope Multicast Addresses block. From my POV, these addresses should be mentioned much earlier in the text.

2.       It seems that GAAP relies on availability of Any Source Multicast (ASM) infrastructure (e.g., Rendezvous Points (RP) in the case of IPv4 multicast) for delivery of GAAP Claim messages.

     *   This is not a surprise because applications using GAAP would probably rely on such infrastructure for delivery of their traffic - but it would be nice if this could be explicitly specified
     *   Specifically, in the case of IPv4 multicast, I assume that the RPs used for delivery of the traffic to GAAP applications should be configured with the entire GAAP Multicast Allocation Range
     *   If yes, this should also be clarified in the document

3.       The draft does not mention if using GAAP in inter-AS environments has any specific issue - e.g., whether support of the of the RPF Vector (RFC 5496) is expected in this case. Any clarification would be useful IMHO

4.       A similar question about using GAAP in environments in which multicast delivery is provided a Multicast VPN, e.g., as described in RFC 6513 and RFC 6514

5.       I concur with the comment by a previous reviewer<https://datatracker.ietf.org/doc/review-ietf-pim-gaap-11-rtgdir-early-zhang-2026-03-25>: parsing of GAAP messages that contain multiple variable length Group Names is somewhat problematic. I wonder if the authors have considered encapsulating each specific record in this message as a TLV.

6.       Section 7 says that the receiver must validate the GAAP message length before processing it, but this is the only mention of the message length in the draft. What exactly is supposed to be used as the message length in this validation?

7.       The draft explains what the experiment (the intended status is Experimental) should resolve and mentions "networks of various size", but it does not provide any hints about the desired scale of the experiment (size of the network, number of groups etc.).

I have not run the Nits tool on the document (this is usually done by the submission tool).

Hopefully, these comments will be useful.


Regards,
Sasha

Disclaimer

This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.