[bess] RtgDir review: draft-ietf-bess-evpn-overlay-10

Lou Berger <lberger@labn.net> Tue, 09 January 2018 23:37 UTC

Return-Path: <lberger@labn.net>
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 B15141241F5 for <bess@ietfa.amsl.com>; Tue, 9 Jan 2018 15:37:03 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id dM0E3npz_3AQ for <bess@ietfa.amsl.com>; Tue, 9 Jan 2018 15:37:02 -0800 (PST)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09DBF120713 for <bess@ietf.org>; Tue, 9 Jan 2018 15:37:02 -0800 (PST)
Received: from cmgw2 (unknown []) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 5FE1C140440 for <bess@ietf.org>; Tue, 9 Jan 2018 16:37:00 -0700 (MST)
Received: from box313.bluehost.com ([]) by cmgw2 with id wPcw1w00P2SSUrH01PczGP; Tue, 09 Jan 2018 16:37:00 -0700
X-Authority-Analysis: v=2.2 cv=doKrMxo4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=RgaUWeydRksA:10 a=48vgC7mUAAAA:8 a=blyHRfvnitcRAip7kYsA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=M3u5A0RRW5ktR7OApkgsa9S08UPmltsZ9OQmyqB6H2Y=; b=EvZtPj0tXutJtkAbjia3vrQzvW 1UO43yfoH7hAyNaYutDEF2qxpCcvw6MfUYI3aMbhrMKqMBQkyzg0M7p6BwdWSxd5KUj1qGGT5zxVM xg3CzN45h+Wwz03CbrkVkDsSa;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([]:38820 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from <lberger@labn.net>) id 1eZ3Rw-002038-9L; Tue, 09 Jan 2018 16:36:56 -0700
From: Lou Berger <lberger@labn.net>
To: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>
Cc: draft-ietf-bess-evpn-overlay.all@ietf.org, rtg-dir@ietf.org, BESS <bess@ietf.org>
Message-ID: <27a39a31-d85b-b496-13cb-0b75ddccb76d@labn.net>
Date: Tue, 09 Jan 2018 18:36:53 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Exim-ID: 1eZ3Rw-002038-9L
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) []:38820
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/Xa1i2hIjJgJqib_QXfG7Kn9iNx0>
Subject: [bess] RtgDir review: draft-ietf-bess-evpn-overlay-10
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 09 Jan 2018 23:37:04 -0000


I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see 

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-bess-evpn-overlay-10.txt
Reviewer: Lou Berger
Review Date: Jan 9, 2018
IETF LC End Date: date-if-known
Intended Status: Standards Track


I have some minor concerns about this document that I think should be 
resolved before publication.


To me the document reads more like an applicability statement than a 
PS.  I think a few things can and should be done to the document to 
clean this up.  Some are trivial, some may take more thought.  The core 
issues are related to (a) detecting/handling configuration mismatches 
and (b) definition of support for multiple encapsulation types.  I 
suspect all raised issues can be addressed via documentation changes.

Major Issues:

Minor Issues:

- The document defines a number of deployment options that are not 
compatible, e.g., section 5.1.2 options 1 and 2, or allowing for 
"locally configured encapsulation".  It would be good  if the document 
should explain how such mismatches can be detected by an implementation 
or in operation and addressed.  If an option can be eliminated, such as 
configured encapsulation, this should be considered.

- The approach taken in the document is clearly applicable to multiple 
tunneling technologies, and mentioning this is certainly appropriate, 
but the document leaves some aspects unsaid (and open to interpretation) 
for encapsulations other than VXLAN.  The scope of the document states 
that vxlan, nvgre and MPLSoGRE encapsulation are fully supported by the 
document, but full specification seems to only be present for the 
first.  For example, section 5.1 references multiple encapsulation 
technologies, but only defines mechanisms relative to VXLAN (VNIs).  
Adding specific procedures for each encapsulation type would make the 
required mechanisms unambiguous, but this is certainly not the only way 
to ensure each is fully documented and multiple independent 
interoperable implementations will be possible.

- Section should cover how 4 byte ASes are to be handled


- Lowercase "should" is used in a some places where it looks like 
"SHOULD" be used.  In general it appears that lowercase was used when 
referring to requirements defined in other documents.  Upper case is 
still appropriate in such cases.

- Some terms are used without references on their first use.