[bess] Robert Wilton's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with COMMENT)

Robert Wilton via Datatracker <noreply@ietf.org> Thu, 28 October 2021 14:16 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: bess@ietf.org
Delivered-To: bess@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8E73A10DA; Thu, 28 Oct 2021 07:16:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bess-evpn-igmp-mld-proxy@ietf.org, bess-chairs@ietf.org, bess@ietf.org, slitkows.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <163543056373.28123.9786943826005845036@ietfa.amsl.com>
Date: Thu, 28 Oct 2021 07:16:03 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/76nlkRM1jfzJXbzmbJO2-vGyY0g>
Subject: [bess] Robert Wilton's No Objection on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Oct 2021 14:16:04 -0000

Robert Wilton has entered the following ballot position for
draft-ietf-bess-evpn-igmp-mld-proxy-14: 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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thanks for this document.  I have to say that I found that the heavier use of
acronyms made this document somewhat harder to read.  I'm also not an expert in
these technologies.

My main question isn't directly actionably on this document, but I wanted to
check whether any updates to the EVPN YANG module are required to support this
functionality, and if so, is that work in progress, or planned?

Otherwise, I just had a couple of minor comments:

On 4.1.1.  IGMP/MLD Membership Report Advertisement in BGP

   When a PE wants to advertise an IGMP Membership Report (Join) using
   the BGP EVPN route, it follows the following rules (BGP encoding
   stated in Section 9):

   1.  ....  This is because BGP is a stateful protocol and
       no further transmission of the same report is needed.  If the
       IGMP Membership Request is for (*,G), then multicast group
       address MUST be sent along with the corresponding version flag
       (v2 or v3) set.

This implies to me that either the v2 or v3 flag is exclusively set, but
presumably it could also be both.  Would "add/or" be better than or?

Does OIF need to be an acronym, it doesn't seem worth it, and makes the text
harder to parse.  Is this a standard term used in other related docs?

5.  Operation

In the paragraph of text above the diagram, perhaps more clearly indicate that
S1, S2 indicate multicast sources and R1 indicates a multicast router, and Hx
indicates hosts.

9.1.  Selective Multicast Ethernet Tag Route

Rather than writing things like "second least significant bit", just writing
"bit 6" would seem to be clearer.

9.1.1.  Constructing the Selective Multicast Ethernet Tag route

I was surprised that the lengths are specified in bits, not bytes.  I presume
that bits are used for consistency with other encodings.

Thanks,
Rob