[bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-vpws-13: (with COMMENT)

Warren Kumari <warren@kumari.net> Sun, 07 May 2017 17:05 UTC

Return-Path: <warren@kumari.net>
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 88A38128796; Sun, 7 May 2017 10:05:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari <warren@kumari.net>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bess-evpn-vpws@ietf.org, aretana@cisco.com, "Zhaohui (Jeffrey) Zhang" <zzhang@juniper.net>, bess-chairs@ietf.org, zzhang@juniper.net, bess@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149417673555.23196.14417727329971821809.idtracker@ietfa.amsl.com>
Date: Sun, 07 May 2017 10:05:35 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/HdL06kUwPsNiDdaCwIATnc2pobs>
Subject: [bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-vpws-13: (with 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: Sun, 07 May 2017 17:05:36 -0000

Warren Kumari has entered the following ballot position for
draft-ietf-bess-evpn-vpws-13: 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:


[ For -11 / -12 ] 
This document is very heavy on the acronyms, and could do with some
expanding of these -- for example, the document starts out with "This
document describes how EVPN can be used...". I'm no MPLS VPN person, so
much time was spent searching to try figure out what everything meant.

I also agree with Spencer's "In multihoming scenarios, both B and P flags
MUST NOT be both set. " being hard to parse, and disagree with Acee that
is it clear.

[ For -13 ]
The draft was revised to address Alia's DISCUSS, and also Spencer's
"traditional way" and "both B and P flags MUST NOT be both set" comment,
but still does not expand EVPN; I also agree with Spencer that it would
be helpful to expand P2P on first use.  I reread the document and have
some additional comments - note that these are are only comments, but I
think that they would make the document more readable...

1: Introduction:
"that in EVPN terminology would mean a single pair of Ethernet Segments
ES(es)." - I'm confused by the 'ES(es)' - guessing this was an editing
failure and 'Ethernet Segments (ES)' was intended? If not, 

You use both "Ethernet AD" and "Ethernet A-D" - please choose and stick
with one.

1.1: Terminology:
"EVI: EVPN Instance." --  Ok, but EVPN is still not defined /

3.1  EVPN Layer 2 attributes extended community
" A PE that receives an update with both B and P flags set MUST treat
 route as a withdrawal. If the PE receives a route with both B and P
 clear, it MUST treat the route as a withdrawal from the sender PE."
Do the above 2 sentences say the same thing? It sure sounds like
repetition, if not, please explain the difference. If not, removing one
would make this less confusing.

Figure 3: EVPN-VPWS Deployment Model
You use the terms / labels "PSN1", "PSN2" - what are these? "Provider
<something> Network"?