[bess] AD Review of draft-ietf-bess-evpn-overlay-08

Alvaro Retana <aretana.ietf@gmail.com> Mon, 04 December 2017 21:49 UTC

Return-Path: <aretana.ietf@gmail.com>
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 B33D1128CD5; Mon, 4 Dec 2017 13:49:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7ct9E5SQlacf; Mon, 4 Dec 2017 13:49:25 -0800 (PST)
Received: from mail-ot0-x241.google.com (mail-ot0-x241.google.com [IPv6:2607:f8b0:4003:c0f::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72AF4128BB7; Mon, 4 Dec 2017 13:49:25 -0800 (PST)
Received: by mail-ot0-x241.google.com with SMTP id v21so16127173oth.6; Mon, 04 Dec 2017 13:49:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=xplbdpkacz6S1PEGrgCoaLrMABXaGvuI/ONdO90mmKk=; b=WH+OAw6PdSKchgCmd9PcHJKzBh1qlz92jm8SRjt7pVgKDOuVJX1pdzkhou2XbG3VQJ ZRdl6CN87RU5YfhxO+PVL7Pc8ttrmBavty3L1bCXKRu22v98S0cns8L4UuNxH1J/Tky6 URoz0ZKtlivtoYVxRMdYdawDfk4Vp/7B3wwMkjfCaXpTv7hRAno0VBkLjyZAMW6lzX7L osulHP589us/UVzES06rWas0JLnHrBhh4YTOXX70QYkEmfZpg5F3BAXSIQfIXGQR3RCt bBrbjtXiNL6MV51WcfXJ3352Tb15h8JbA/aO1F2L1sRHU1ygLb794yQx/DQyoFzkfSCG 9n6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=xplbdpkacz6S1PEGrgCoaLrMABXaGvuI/ONdO90mmKk=; b=ENaXG6tm0WAN0+qZp+ENeS+JYbCW+cWJ28mgamoTyl+sk7K01h9GrlwQy59eds7so4 qHmPo5oFStWY1hEyMwpatQ/F9+1Q/T8T16S70vUFHs7keVH1zyMZBUlup/80oIsdioO2 mCjM4UsYewVHVetLuiFi5VX0VTV5YYHR83lATuO3AmoZtxlrK79js5/SuhyEOFBloZ1O oX8iWnPm82VmrxGUmMbEJcxallHoy+lVOgFvCdcy/y5epm34feXkH1EW7fcIWlAAqKRI dmvTZNSUjVdJjJOaQHh8syPcG7VE2XcBEePuwBJpTifzUCHNy0bS+eMj1/uVMkAGOrxc cQog==
X-Gm-Message-State: AJaThX6Vx1OSfulUzoB4QrRCYzHu3W5IMdgWoeAOn8gqa/nuRcEMIZl2 PjywMSzqsyzTQvQzgtk7QvbTyosyzoshVOEGoaw=
X-Google-Smtp-Source: AGs4zMaz1AvdnzMacw5ztq7QpMVj5bsG4+eDUo//qF9c4bwHoxXqpZdl+gb7sbIKcNxqTsgbWzFRAyOxJjJKjAw/fnQ=
X-Received: by with SMTP id c52mr16040361ote.317.1512424164612; Mon, 04 Dec 2017 13:49:24 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 4 Dec 2017 16:49:24 -0500
From: Alvaro Retana <aretana.ietf@gmail.com>
X-Mailer: Airmail (461)
MIME-Version: 1.0
Date: Mon, 04 Dec 2017 16:49:24 -0500
Message-ID: <CAMMESsw2x53Av-_zi5nL5czKCXYmi_mk0i6qyYYZDYHE8oo_tA@mail.gmail.com>
To: bess-chairs@ietf.org
Cc: Thomas Morin <thomas.morin@orange.com>, bess@ietf.org
Content-Type: multipart/alternative; boundary="001a1141c09014e01a055f8ab13a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/9x_rgwqxQYVXVGjC94YdIVBB9jk>
Subject: [bess] AD Review of draft-ietf-bess-evpn-overlay-08
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: Mon, 04 Dec 2017 21:49:28 -0000

Dear Authors:

I just finished reading this document (finally!).  I have a some comments
(see below) which I think should be easy to address.

I also have some bigger issues that we’ll need the Chairs’ help to solve:

(1) Coordination with nv03

For the Chairs:  Except for some clarification comments [1] related to the
current version, I see no other traffic in the nvo3 list related to this
document.  Was there some other coordination that I’m missing?   I am not
questioning having this document in bess (that’s perfectly fine); I’m just
raising the needed coordination with other WGs, from the Charter: "The
working group will also coordinate with...NVO3 working group for coordination
of protocols to support data center VPNs.”

What about Geneve (draft-ietf-nvo3-geneve)?  The nvo3 WG is focusing on
Geneve as the Standard encapsulation, but this document doesn’t
even mention it.

(2) Document Status

Why is this a Standards Track document?  The Abstract/Introduction say that
“this document describes how Ethernet VPN (EVPN) can be used as an NVO
solution and explores applicability of EVPN functions and procedures.”  --
if it’s just a description (as the text clearly is), and not a technical
specification, then why it is not Informational?

I can see how we could call it an Applicability Statement (rfc2026) and
still publish it in the Standards Track.  If we want to go that way, we
would need some minor updates to make it clear that this is an
Applicability Statement and is not intended to stand in for a Technical
Specification.  I am not clear on the process as it related to possible
DownRefs (see below), but I’m willing to Last Call an Applicability
Statement in the Standards Track…if that is what you want.





M1. Section (Auto Derivation of RT) shows a “packet format” to
illustrate how the RT can be auto-derived.  Without any context, the
description doesn’t make much sense: the fields are not described in order,
the reader is expected to know about global and local administrative
fields, the “A-bit” (or the Type field) are not mentioned in the
description, people could probably guess that “D-ID” means “domain-id”,
there’s no indication of what to do with that “packet format”, etc.  Please
clean the description up, include clearer explanations and some references
can’t hurt.

M1.2. What about 4-byte ASNs?

M2. From 5.1.3 (Constructing EVPN BGP Routes): “...routes MAY be
advertised with
multiple encapsulation types as long as they use the same EVPN multi-homing
procedures (section 8.3.1, Split Horizon)…”. Is Split Horizon an example,
or the only multi-homing procedure that should be considered?  Please be

M3. From 5.2 (MPLS over GRE):

M3.1. “...when it is used in conjunction with EVPN the GRE key field SHOULD
be present, and SHOULD be used to provide a 32-bit entropy field.”  What
are the cases when it is ok not to include the field, or use it for that
purpose?  IOW, why are these SHOULDs not MUSTs?  Or maybe, when is the key
field needed?

M3.2. "The Checksum and Sequence Number fields are not needed and their
corresponding C and S bits MUST be set to zero.”  This is different than
what rfc4023 specifies (not a problem).  If you’re specifying the setting
of the bits, then you should be more prescriptive with whether the fields
are included of not; suggestion: "The Checksum and Sequence Number fields
MUST NOT be included and the corresponding C and S bits in the GRE Packet
Header MUST be set to zero.”

M4. In 7.1 (Impact on EVPN BGP Routes & Attributes for VXLAN/NVGRE

M4.1. These 2 MUSTs seem out of place as they are used to explain, and not
in a Normative way: “ ..the RD must be a unique value per EVI or per
NVE as described
in [RFC7432]. In other words, whenever there is more than one
administrative domain for global VNI, then a unique RD MUST be used, or
whenever the VNI value have local significance, then a unique RD MUST be
used.”  s/MUST/must

M4.2. This SHOULD is also out of place because the standardization was
already done in rfc7432 (this document is just mentioning it): “...as noted
in section 8.6 of [RFC7432]...the single-homing ingress NVE SHOULD be able
to…”. s/SHOULD/should

M4.3. Section 10.2.1 then points back at the text in 7.1 using another
SHOULD…again, s/SHOULD/should

M5. 7.2 (Impact on EVPN Procedures for VXLAN/NVGRE Encapsulation) also
includes a superfluous SHOULD: “...as noted in section 8.6 of [RFC7432]...a
single-homing ingress NVE SHOULD implement…”.  s/SHOULD/should

M6. The introductory paragraph in Section 8.1 (EVPN Multi-Homing Features)
says that it is used to "recap the multi-homing features of EVPN to highlight
the encapsulation dependencies. The section only describes the features and
functions at a high-level. For more details, the reader is to refer to
[RFC7432].”  However some of the 8.1.* sub-sections contain Normative
language.  Is that Normative language specifying new behavior introduced in
this document, or highlighting the recap from rfc7432?  If there’s no
new behavior, then please use lower cases.  If there is new behavior, then
it would be nice to clarify that in 8.1.

M7. In 8.3.1 (Split Horizon), this MUST is out of place because it is not
specifying anything: “...other means of performing the split-horizon
filtering function MUST be devised.” s/MUST/must

M8. References

M8.1. TUNNEL-ENCAP (aka draft-ietf-idr-tunnel-encaps) should be Normative,
which btw is marked to Obsolete rfc5512; I mention this because both are
listed in several parts, so you should take rfc5512 out.

M8.2. These should also be Normative: RFC7348, NVGRE, VXLAN-GPE, RFC4023


P1. Please use the new Normative Language boilerplate (rfc8174).

P2. From 7.1 (Impact on EVPN BGP Routes & Attributes for VXLAN/NVGRE
Encapsulation): “...reduces the required routes and attributes to the
following subset of four out of eight”.  Please either list the attributes
that are not needed, or put in a reference to where those can be found.
(rfc7432 ??)

P3. From 8.3.1 (Split Horizon): "In order to prevent unhealthy
interactions…”. I would really like to see more here: what does “unhealthy
interactions” mean?  Can it result in loops or lost traffic or some other
“bad” thing?   I note that even through you “prohibit” the configuration,
you don’t go as far as mandating that it not to be used (MUST NOT), which
makes me want to understand more the potential effects…if it happens, what
are the risks?

P4. In 8.3.3 (Unknown Unicast Traffic Designation): “...the ingress PE MAY
use a flag-bit in the VxLAN header to indicate BUM traffic type. Bit 6 of
flag field in the VxLAN header is used for this purpose per section 3.1 of
[VXLAN-GPE].”  Suggestion: “…the ingress PE MAY set the BUM Traffic Bit (B
bit) [VXLAN-GPE] to indicate BUM traffic.”

P5. Security Considerations:  I find that the suggestion of IPSec may be
out of place in this document; this document pretty much just talks about
how to use EVPN, it doesn’t really introduce new capabilities, so unless
IPSec is mentioned in rfc7432 (which is not — and not even mentioned in
this section), or recommended in rfc4271 (which is not) then I would
refrain from including such recommendation here.  In fact, I think that
pointing at the Security Considerations of existing RFCs should be enough.

P5.1. The reference to rfc4301 (beyond what VXLAN/NVGRE) mention seems like
you’re trying too hard.  I would just put explicit references to the
encapsulations since they should be dealing with security themselves.

P6. References: [KEYWORDS] shows up twice.  I think that the reference to
rfc4271 can be made Informative.


N1. Section 3 (Terminology) literally transcribes several definitions
from rfc7432/rfc7365 — while it is ok, I personally prefer just pointing at
the definitions: it’s just easier to have the other RFCs be the
authoritative source and not rely on maintaining the definitions in sync
should they ever change.  Suggestion: “The reader is expected to be
familiar with the terminology in …”.

N2. s/the VNI value have local significance/the VNI value has local

N3. s/it is recommend/it is recommended

N4. Please be consistent in naming references, some list the RFC number,
while others a name...