Re: [bess] AD Review of draft-ietf-bess-dci-evpn-overlay-05

Alvaro Retana <> Fri, 26 January 2018 21:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 29855126BFD; Fri, 26 Jan 2018 13:17:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RN3k1SfSCKRO; Fri, 26 Jan 2018 13:17:18 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 32C1D129C6E; Fri, 26 Jan 2018 13:17:18 -0800 (PST)
Received: by with SMTP id a184so1213248oif.7; Fri, 26 Jan 2018 13:17:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=/Z3JgG7a6RUS8DJa9CrZr8sPttqVUe3PO7JnfMSbYo8=; b=cXMOsqLyqBwT9aW9gDyvE7r43I0jbB8dC3QnsOZm+KXuTRTBevom9bs87JI89dJlPR dpZ88BRx0znLg8VN3uQyXh7tg0aOoCgCrWmRUpJ2js6SEFLHeUq/77imYJIBzpyBt/UV biHnYqIpqZciv/jb2v5Rf3N0zzbZYAiuK8rTtTBVS4IJUNCUDaDFGZWNnYHq16dGzWCo krnwlK4GfCDgbqm9/uo1YlYcmYiwv4kvln7IOV0lffKwDzHFt7qiEG6blUjXAeDn/HI3 Z5+HLSPgT6Z4jflzzV9qwXaUDXV69oVwjE6ZwGHevN58oRMZH0NsDMNX8gghArwjuXxM /DXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=/Z3JgG7a6RUS8DJa9CrZr8sPttqVUe3PO7JnfMSbYo8=; b=s5FkC5Svo4HUSGaGvn9KHDNSd2XVhxmX6xsKBA1onPTO0JIlbj7y3MIbTJ0dY8HrRY 0WiyOrgJXnhbL1StG7frzfyaVLk6ZKsDjDZF/VYgc+tjpKocP/IEgmzZJLeRkStItIfo YXBTCX0Bgwo9hNPy7mxuYgXTBgsXMzbVHg1NzKTSqKysDpiUE5UtftsfaUa0qYeAASBW TQodXmH1kIgmlnBB3/SOMJOUB2njmI5M4uLT6hkUj1Sk9PwlT6gLyVo4by39o4vqSznL IYF5nnZMP/oCgevsvba9x6+dBjLKmO+s3Wl99wByM/6ek9KyD9qwpU6VGl+mrlArSsau mmIA==
X-Gm-Message-State: AKwxytcUO+feDoNFi6Nf9VmVr3Zr1GSDbAgLh2332lD6FIatWBBNuAwi kcpCbKvrkrxQt7RuCq58KspsKCrXXzLVLN4eYbE=
X-Google-Smtp-Source: AH8x224KFskrAWl1C35qQc72C/i8uUuRERt0MxjWl0xjL6pgy7/j26ZIPx9iUw1r0SYt7iCP9lwNOBUHEd2M8X67rhc=
X-Received: by with SMTP id d205mr543916oib.308.1517001437238; Fri, 26 Jan 2018 13:17:17 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Fri, 26 Jan 2018 16:17:16 -0500
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
X-Mailer: Airmail (467)
MIME-Version: 1.0
Date: Fri, 26 Jan 2018 16:17:16 -0500
Message-ID: <>
To: "" <>, "Rabadan, Jorge (Nokia - US/Mountain View)" <>
Cc: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="001a113d735aca5d600563b46b97"
Archived-At: <>
Subject: Re: [bess] AD Review of draft-ietf-bess-dci-evpn-overlay-05
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Jan 2018 21:17:21 -0000


Thanks for the update.

I’m starting the IETF LC, but I need you to please fix the nits related to
the references:

  == Missing Reference: 'RFC8174' is mentioned on line 125, but not defined

  -- No information found for draft-ietf-bess-evpn-vpls-integration - is the
     name correct?



On January 22, 2018 at 4:16:35 PM, Rabadan, Jorge (Nokia - US/Mountain
View) ( wrote:

Hi Alvaro,

Thank you very much for your detailed review.

Revision 06 has just been uploaded. This rev addresses all your comments.

Please see some responses in-line with *[JORGE].*



*From: *Alvaro Retana <>
*Date: *Thursday, January 18, 2018 at 5:08 PM
*To: *"" <>
*Cc: *"" <>rg>, "" <>gt;, "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <>
*Subject: *AD Review of draft-ietf-bess-dci-evpn-overlay-05
*Resent-From: *<>
*Resent-To: *<>om>, <>om>, <>gt;, <>om>, <>
*Resent-Date: *Thursday, January 18, 2018 at 5:08 PM

Dear authors:

I just finished reading this document.

As with draft-ietf-bess-evpn-overlay, it seems to me that this document is
better suited as an Applicability Statement [1] instead of a Technical
Specification -- both would result in a Standards Track document.  It is
hard for me to clearly identify what this document is specifying, vs
explaining how to use existing mechanisms (already specified elsewhere) to
achieve the DCI.  I don't want to dig too deep into this point, but it
would be nice if you at least considered refocusing the text.

*[JORGE] While a good part of the document describes how different
Technical Specifications can be applied to the DCI case, the document also
describes new procedures or extensions of its normative Technical Specs. In
particular, the new EVPN extensions are:*

·         *The Interconnect Ethernet Segment (I-ES), its definition and
usage are different than the one in [RFC7432]*

·         *The use of the Unknown MAC route in I-ES*

·         *The processing of EVPN routes on Gateways with MAC-VRFs
connecting EVPN-Overlay to EVPN-MPLS networks.*

*I changed the abstract and the introduction to reflect that. *

I do have some more comments below.  I'll wait for an updated draft before
starting the IETF Last Call.





M1. I don't feel too good about using Normative Language to describe the
requirements (2.1 and 3.1) because the normative part of this document
should be the solution itself, not the requirements (which the solution
will then solve).  As I read the requirements, with the Normative Language
in them, there are questions that come up, which wouldn't be there if
rfc2119 keywords were not used.

*[JORGE] OK. I changed sections 2.1 and 3.1 and removed Normative Language.*

M1.1. There's an important use of the words "supported" and "implemented",
what do they mean from a Normative point of view?  Are you using them from
the point of view of the operator implementing something in their network,
or the solution (the software feature) including them?  How do you
Normatively enforce that?  Some examples of their use are: "Per-service
load balancing MUST be supported. Per-flow load balancing MAY be
supported..." (2.1), "The following optimizations MAY be supported..."
(2.1), "Multi-homing MUST be supported. Single-active multi-homing with
per-service load balancing MUST be implemented. All-active multi-homing,
i.e. per-flow load-balancing, SHOULD be implemented as long as the
technology deployed in the WAN supports it" (3.1).  In summary, I think
that the requirements would be better served with non-rfc2119 language.

*[JORGE] OK, fixed now.*

M1.2. The use of "MUST be supported" doesn't stop when talking about the

M1.2.1. In 2.4: "As already discussed, single-active multi-homing, i.e.
per-service load-balancing multi-homing MUST be supported in this type of
interconnect."  Assuming you take off the Normative Language in 2.1, take
out "as already discussed"...

*[JORGE] removed.*

M1.2.2. In 2.5: "The following features MAY be supported..."  I'm assuming
"MAY" is used here because the optimizations are optional; saying so would
be better as some of the descriptions in the sub-sections include other
Normative Language.

*[JORGE] Changed to "The following GW features are optional and optimize
the control plane and data plane in the DC."*

M1.2.2. In 2.3 an option exists...but in both cases "MUST be supported" is
used.  As I asked above, what does this mean from the enforcement of the
Normative Language point of view? If we think about interoperability, then
maybe a more prescriptive sentence would work better.  Suggestion: s/the
provisioning of the VCID for such PW MUST be supported on the MAC-VRF/the
VCID MUST be provisioned…

*[JORGE] Done.*

M1.2.3. In 3.2.2./3.3.2: "Single-active multi-homing MUST be supported on
the GWs." …

*[JORGE] removed Normative language.*

M1.2.4. 3.4.3/3.5.2: "Single-active as well as all-active multi-homing MUST
be supported."

*[JORGE] removed Normative language.*

M2. From 2.5.3: "Individual AC/PW failures MAY be detected by OAM
mechanisms."  The "MAY" seems to just be stating a fact; s/MAY/may

*[JORGE] done.*

M2.1. The two "MAYs" in the bullets following the "for instance" seem out
of place too.  If the intent is to just list two possibilities (examples)
then the "MAYs" should not be Normative.

*[JORGE] changed to 'may'*

M3. Security Considerations.  Please see my note above about thinking that
this document is more appropriate to be an Applicability Statement (than a
Technical Specification).  The Security Considerations section basically
directs the reader to existing work.  I would like to see a statement (for
the benefit of the security reviewers) along the lines of: "This document a result there are no new security considerations."  Note that
considering this document a Technical Specification by definition it means
it adds something -- so please focus on that here.

*[JORGE] Point taken. Please check out the new section now.*

M4. References: The reference to draft-ietf-bess-evpn-overlay should be

*[JORGE] Agreed. Added.*


P1. The "Conventions and Terminology" (Section 5) should be moved to the
front of the document.

*[JORGE] done.*

P2. Please add references to VPLS, EVPN, VXLAN, 802.1q/ag, etc, etc. on
first mention.  All these technologies are important in understanding the
document, but only some are properly referenced later.  Ideally, there
would be a reference when a mayor technology is mentioned (specially the
first time) and when other important features are mentioned and assumed --
for example: in "Even if optimized BGP techniques like RT-constraint are
used..." it would be nice to put a reference to RT-constraint.   It's all
about the completeness of the document…

*[JORGE] ok, done.*

P2.1. In 2.3: "the usual MPLS procedures between GW and WAN Edge router"; a
reference here would be nice.

*[JORGE] ok, done.*

P3. Please use the template in rfc8174, instead of the one in rfc2119.

*[JORGE] ok, done.*

P4. In 3.4.1, I can't really parse this text: "Normally each GW will setup
one (two) BGP EVPN session(s) to the DC RR(s) and one(two) session(s) to
the WAN RR(s)."  Specifically the "one (two)" part.

*[JORGE] changed to: "*Normally each GW will setup one BGP EVPN session to
the DC RR (or two BGP EVPN sessions if there are redundant DC RRs) and one
session to the WAN RR (or two sessions if there are redundant WAN RRs)"

P5. The IANA Considerations section is empty [].

*[JORGE] ok, done.*


N1. I know that many of the abbreviations are well-known by now, but please
expand as needed, specially in the first few sections to give the readers a
better idea of the content.  Note that PBB and VPLS are in the "RFC Editor
Abbreviations List" [2], but, surprisingly EVPN is not.  [Note to
self/shepherd: ask the RFC Editor to add EVPN when this document gets to

*[JORGE] ok, done.*

N1.1. Figure 2 includes "EVPN-Ovl", which is not expanded or explained
anywhere.  I'm guessing this is just a general EVPN-Overlay, but the reader
shouldn't have to guess.

*[JORGE] ok, added a note.*

N2. Section 4 doesn't exist.

*[JORGE] ok, fixed.*

N3. 3.4.1: "Optionally, different I-ESI values MAY be configured..."
 "Optionally...MAY" is redundant.

*[JORGE] ok, fixed.*