[bess] Comments on BGP procedures for draft-ietf-bess-evpn-igmp-mld-proxy

Jeffrey Haas <jhaas@pfrc.org> Thu, 09 May 2019 15:42 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 63B2D1200BA; Thu, 9 May 2019 08:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VD-57WSPckPm; Thu, 9 May 2019 08:42:06 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org []) by ietfa.amsl.com (Postfix) with ESMTP id E519512016C; Thu, 9 May 2019 08:41:54 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 5E12F1E2D8; Thu, 9 May 2019 11:42:18 -0400 (EDT)
Date: Thu, 09 May 2019 11:42:17 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: draft-ietf-bess-evpn-igmp-mld-proxy@ietf.org
Cc: bess@ietf.org
Message-ID: <20190509154217.GA16412@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/JKA5pGa2UZCaEJlpuu_53DsyHsI>
Subject: [bess] Comments on BGP procedures for draft-ietf-bess-evpn-igmp-mld-proxy
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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, 09 May 2019 15:42:09 -0000

I have a few comments on this draft, in particular on the BGP PDU encoding

Section 7.1:
The lengths of the various fields and their consistency should be spelled
out in more detail.  

For example, a source could be 0 for (*,G), or should be the length of an
IPv4 or IPv6 host address (32/128).  Other lengths likely do not make sense.

The length of a multicast group also likely should be a "host" length -

For the source and the group, it is likely an error if the lengths do not
agree.  E.g. S may be 0, but when 32 or 128 the group must be 32 or 128

The originator router also should likely be a host length, although I'm a
bit unclear what the intent of the contents of this field should be.  Is
this intended to be a loopback?  If so, how does one choose it among
several, if more than one is available?  Should the length of the originator
also agree with the S,G fields?

Some discussion about what to do when the fields are syntactially valid but
semantically invalid (e.g. mis-matched lengths) is needed.  See RFC 7606
about what to discuss.  Likely "treat as withdraw" semantics are desired.

The flags field is somewhat confusing when the addresses are IPv6 and thus
the procedures are expected to be for MLD rather than IGMP.  The draft as a
whole, in spite of its title, is worded heavily toward IGMP.  I would
suggest requesting some appropriate review to help normalize the terminology
here.  However, the flags field should be clarified for MLD cases.

Similar comments apply to section 7.2 and 7.3.

Section 7.3 does not discuss the two new fields Leave Group Synchornization
and Maximum Response Time or the procedures for these fields.  It should
refer back to section 4.2.

-- Jeff