[bess] Eric Rescorla's Discuss on draft-ietf-bess-evpn-etree-13: (with DISCUSS and COMMENT)

Eric Rescorla <ekr@rtfm.com> Sat, 09 September 2017 18:35 UTC

Return-Path: <ekr@rtfm.com>
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 7BFB4132A89; Sat, 9 Sep 2017 11:35:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bess-evpn-etree@ietf.org, aretana@cisco.com, Thomas Morin <thomas.morin@orange.com>, bess-chairs@ietf.org, thomas.morin@orange.com, bess@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.60.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150498215050.8140.12011601639252346290.idtracker@ietfa.amsl.com>
Date: Sat, 09 Sep 2017 11:35:50 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/s-zMwNsq5gp4rM_rAEs27rl2c4w>
Subject: [bess] Eric Rescorla's Discuss on draft-ietf-bess-evpn-etree-13: (with DISCUSS and COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 09 Sep 2017 18:35:52 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-bess-evpn-etree-13: Discuss

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:


It's not clear to me if the prohibition on leaf-to-leaf communications is
intended to be a security requirement. If so, it seems like it needs to
explicitly state why it is not possible for ACs which are leaf to pretend to be
root. If not, then it should say so. Additionally, this solution appears to
rely very heavily on filtering, so I believe some text about what happens
during periods of filtering inconsistency (and what the impact on the security


4.2 Broadcast, Unkonwn, and Multicast (BUM) Traffic
Nit: unknown