[Softwires] Benjamin Kaduk's No Objection on draft-ietf-softwire-mesh-multicast-23: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 27 September 2018 00:50 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: softwires@ietf.org
Delivered-To: softwires@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F1912777C; Wed, 26 Sep 2018 17:50:29 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-softwire-mesh-multicast@ietf.org, Ian Farrer <ianfarrer@gmx.com>, softwire-chairs@ietf.org, ianfarrer@gmx.com, softwires@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153800942916.21537.881189317455678353.idtracker@ietfa.amsl.com>
Date: Wed, 26 Sep 2018 17:50:29 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/FaRzIDyzIPcBOCkn4rW4Rucefa4>
Subject: [Softwires] Benjamin Kaduk's No Objection on draft-ietf-softwire-mesh-multicast-23: (with COMMENT)
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.29
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Sep 2018 00:50:29 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-softwire-mesh-multicast-23: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I'm balloting No Objection instead of Discuss, but I think this document
has a few things that need to be resolved before publication.  In

I'm concerned that the informative references may actually need to be
normative references, but not quite enough to cross my Discuss threshold.
See my comments on Section 9 for details.

There are several things that look like internal references but are not
resolvable (see per-section comments).

Section 1

I think you should provide a brief summary of what "(S,G) states" are in
this document, as well as the reference.

Section 3

   o Address Family Border Router (AFBR) - A router interconnecting two
   or more networks using different IP address families.  Besides, in
   the context of softwire mesh multicast, the AFBR runs E-IP and I-IP

nit: maybe s/Besides/Additionally/?

nit: using "upper reaches" and "lower reaches" is still basically the same
metaphor as upstream/downstream.  I guess "closer to the source" and
"closer to a receiver" might be different, but offer no opinion on whether
it would be better.

Section 5.2/5.3

Please expand SSM and ASM on first usage.

Section 5.4

   To achieve this, every AFBR MUST announce the address of one of its
   E-IPv4 interfaces in the "v4" field alongside the corresponding
   uPreifx64.  The announcement MUST be sent to the other AFBRs through
   MBGP [RFC4760].  Every uPrefix46 that an AFBR announces MUST be
   unique.  "uPrefix46" is an IPv6 prefix, and the distribution
   mechanism is the same as the traditional mesh unicast scenario.

I am not very familiar with this space, and just wanted to check that both
"uPrefix46" and "uPrefix64" are defined things (as opposed to "uPrefix64"
being a typo).

   When a downstream AFBR receives an E-IP PIM (*,G) message, S' can be
   generated according to the format specified in Figure 3, with the
   "source address" field set to * (wildcard value).  The translated

There is no "source address" field in Figure 3.

   message will be forwarded to the corresponding upstream AFBR.  Since
   every PIM router within a PIM domain MUST be able to map a particular
   multicast group address to the same RP (see Section 4.7 of
   [RFC7761]), when the upstream AFBR checks the "source address" field
   of the message, it finds the IPv4 address of the RP, and ascertains
   that this is originally a (*,G) message.  This is then translated
   back to the (*,G) message and processed.

I'm failing to find where the downstream AFBR is setting the source address
to that of the RP; presumably this just means I'm confused about how this
part works.

Section 6.4

   Assume that one downstream AFBR has joined an RPT of (*,G) and an SPT
   of (S,G), and decided to perform an SPT switchover.  According to

Is it the AFBR that has joined the (E-IP) group and decided to switchover,
or some system in the client network?

Section 8

   In Figure 5, the semantics of fields "PIM Ver", "Type", "Reserved",
   and "Checksum" can be referred in Section 4.9 of [RFC7761].
   IPv4 Group Address (Encoded-Group format): The encoded-group format
   of the IPv4 group address described in Section 4.2.

   IPv4 Source Address (Encoded-Group format): The encoded-unicast
   format of the IPv4 source address described in Section 4.3.

   IPv6 Group Address (Encoded-Group format): The encoded-group format
   of the IPv6 group address described in Section 4.2.

   IPv6 Source Address (Encoded-Group format): The encoded-unicast
   format of the IPv6 source address described in Section 4.3.

This document has no Section 4.2 or 4.3 (and those sections of RFC 7761 do
not seem appropriate here, either).

Section 9

"MUST [...] follow the requirements mentioned in
[I-D.ietf-intarea-tunnels]" seems like it needs a normative reference.
"MUST [...] allow the use of encapsulation mechanisms mentioned in
[RFC4925]" would seem to do the same.

Section 10

It may be worth calling out the "interface agent" as being an additional
workload susceptible to DDoS.

It is true that the trusted nature of the BGP peer is what is relevant for
deciding to accept Well-Known prefix advertisements, but perhaps there is
room to mention the potential use of cryptographic methods for
authenticating the peer so as to have increased confidence that such trust
is properly placed.