[RTG-DIR]Rtgdir last call review of draft-ietf-pim-light-06

Henning Rogge via Datatracker <noreply@ietf.org> Tue, 27 August 2024 19:07 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from [10.244.2.19] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id B6883C17C8A5; Tue, 27 Aug 2024 12:07:49 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Henning Rogge via Datatracker <noreply@ietf.org>
To: rtg-dir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.22.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <172478566936.910891.2686579938558998269@dt-datatracker-584cd6c8dd-fvr2f>
Date: Tue, 27 Aug 2024 12:07:49 -0700
Message-ID-Hash: 3WDVH2LMRWYYMR5GHFGPUZSZ47BPL6W5
X-Message-ID-Hash: 3WDVH2LMRWYYMR5GHFGPUZSZ47BPL6W5
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rtg-dir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-pim-light.all@ietf.org, last-call@ietf.org, pim@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Henning Rogge <hrogge@gmail.com>
Subject: [RTG-DIR]Rtgdir last call review of draft-ietf-pim-light-06
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/qYwl-5t4XPJy2cqwW3fENVy_BI4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Owner: <mailto:rtg-dir-owner@ietf.org>
List-Post: <mailto:rtg-dir@ietf.org>
List-Subscribe: <mailto:rtg-dir-join@ietf.org>
List-Unsubscribe: <mailto:rtg-dir-leave@ietf.org>

Reviewer: Henning Rogge
Review result: Has Nits

Hello,
I was asked to do a RTG review on the pimp-light-draft, this review is based on
revision 06 of the draft.

General comment:

Multicast in general can be quite complex to get right, so having simplified
protocol options (like this draft) for some situations is a good idea. Content
of this draft reads good, its just the graphics (and their explanation) could
use a bit more polish.

Section 3.2.2:

I think the graphics in 3.2.2 is a little bit too compact with too many things
going on. I assume that the domains are meant to be vertical "slices" and the
PIM Domains are the groups A-B-E and the group D-E-F, the BIER domain would
contain B-C-D-E-F? I think this part needs a bit more text that just states
which group is meant by each "annotation". Its difficult to see which "line" in
this graphics is a connection between nodes and which is meant to mark the
domain areas. Maybe it would help to explicitly state the domain membership
when the domain are first mentioned in this section?

Section 3.4:

I think the description of the graphics here in the text is better than in
3.2.2, but this graphics also feels a bit "cramped". Maybe UBER and DBER could
be just described in the text instead of putting it into the graphics?

Something like
"In another example, if PLI is configured automatically, as an example in BIER
case, when the downstream BIER Edge Router (DBER) node D is no longer
reachable, the upstream BIER Edge Router (UBER) node B..."

Henning Rogge