IETF Last Call Review of draft-ietf-pim-gaap-18
review-ietf-pim-gaap-18-rtgdir-lc-vainshtein-2026-08-02-00

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
(@alexander.vainshtein@rbbn.com<mailto:alexander.vainshtein@rbbn.com>) 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.