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

Alvaro Retana <> Thu, 07 December 2017 14:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02C76129456; Thu, 7 Dec 2017 06:05:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 ODWPxEiMeIys; Thu, 7 Dec 2017 06:05:40 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3E9012945B; Thu, 7 Dec 2017 06:05:40 -0800 (PST)
Received: by with SMTP id s9so4962228oie.5; Thu, 07 Dec 2017 06:05:40 -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=GoJHTQB2aqy75k0oxLQUzUR4z9FWGXxQk8sO5KLdCoA=; b=RscRyFemNg7fgtGyCjqQj/cuu/+9h3WSlqmFjLpnmw5whdwY3lNFHXY9cHZMepune3 GKS9kLO51GsfxkmkHn/jZrujUduJNHHW95uS/86ogjau0dQ4qcMtKYe4A7RIzyltiPAI Tgaq1wdv4oaiJ8O3/6OmB1npjQqGoxqpzQGybf+61YnUCXPjbX6iaRRbzjUO2SR62XNW ytZCeo+MU572JKMfsN2BL/UAqXqO+Nsa6sroVktBkOujmS8ebAK+2hboa4Iya9n76T93 mLErhdvIVj3rWskd+VfrmTi1tmgACiB+/mfkIl/gHvDwKfOdl20RYKEIwTZTqtD0Hw5G HlWg==
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=GoJHTQB2aqy75k0oxLQUzUR4z9FWGXxQk8sO5KLdCoA=; b=GIW5Aj0zMfrfA7ik3kFQ/+nQEZxPETka2g1jzm5w2S6r/XN0yGa5wOOALr32jJpvFx iTqN2cDlPHhmGKTKXVef0hwBq2z3MlLvHPUDaWz3Xr7nEupp43GBubb2LvBrrehkl/Jd 3UAqZypLt3tKl4AvUKcTArodXCUMi5NsPg5QKU9Hx76MG/LZMcukKuDzz41Gnz381KH5 jChle2XkKQ60YLxIuBtAxj7frz0vxF94INEXY+5lm8pINXiVVpCgklNsKwBw4O+8sfp+ w6HCaxHIkjTR9e8sNTrN8fPmkdnvB/bLc129RLPOeWGqMJ2w5H/4lhVl0XOQwPtP2xFy vJ6A==
X-Gm-Message-State: AJaThX7qc5+8IAvQy8yC7gH6XahspkyJGd2bD2zxNd9+3Xc4l/nmHjr4 WC1STk2N7SjwDY1HAXg338/4b90LqzHfdku7QXw=
X-Google-Smtp-Source: AGs4zMb6BnfYA4nHmwTucPI0+BybE6xUiosKuz5y9SUljyhZ2LxLRVTJxdIVHO6ZFaN+AQfMWSJw26kYLRWBbtDnPAs=
X-Received: by with SMTP id q135mr23754593oic.109.1512655539860; Thu, 07 Dec 2017 06:05:39 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 7 Dec 2017 06:05:39 -0800
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
X-Mailer: Airmail (461)
MIME-Version: 1.0
Date: Thu, 07 Dec 2017 06:05:39 -0800
Message-ID: <>
To: "" <>, "Ali Sajassi (sajassi)" <>
Cc: Thomas Morin <>, "" <>
Content-Type: multipart/alternative; boundary="001a11c179841f08d1055fc0906d"
Archived-At: <>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08
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: Thu, 07 Dec 2017 14:05:43 -0000

On December 5, 2017 at 10:53:02 PM, Ali Sajassi (sajassi) (



Thanks for the review. Please refer to my replies to your comments marked
with [Ali] inline. I have incorporated them in rev09 of the draft that has
just been published. Please let me know if you have any other comments.

The only significant issues left are about the references (see below).

I need the Normative references to be in place so I can start the IETF LC
(and can point them out there).  As soon as you post an update I’ll start
the LC.




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?

[Ali] The reason it is a “SHOULD” because, the MPLS over GRE encap still
works without the key field set to the entropy value; however, if that’s
done, then ECMP won’t work well in the network. Also, the core routers in
the network may not support ECMP based on GRE key and that’s another reason
for “SHOULD”.

Can you include something along those lines?


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.

[Ali] Please refer to Thomas explanation on this which is copied here for
your convenience:

“This was debated on a while ago, and this is somehow the conclusion of

the discussion:



We'll also add idr-tunnel-encaps a Informative reference. With respect

to Tunnel Encap Extended Community (which is the only part of

idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draft

itself references RFC 5512.

During the course of WG LC and RFC editorship of evpn-overlay draft, if

we see that idr-tunnel-encap is progressing fast, then we can drop the

reference to RFC 5512 and make the reference to idr-tunnel-encap

Normative. Otherwise, we'll keep both references with RFC 5512 as

Normative and idr-tunnel-encap as Informative.


The question probably is whether or not idr-tunnel-encap progress is


As I replied back:

If anything, both references should at least be of the same type: I can see
no reasoning why one would be Normative and the other Informative.

In this case, idr-tunnel-encap already went through WGLC (according to the
datatracker) — we can’t ignore the fact that idr has consensus on
deprecating rfc5512.  Again, we don’t need both references.

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

[Ali] Please refer to Thomas explanation on this which is copied here for
your convenience:

“My process fu is weakening, but if this specification is standard track

(and I believe it should be), I believe it can't normatively depend on

Informative specs and some of the above are in this category.”

My reply:

It can if we call the Down References out in the IETF Last Call and no one
opposes.  I think we already processed at least one document with a DownRef
toVXLAN, so I don’t think that’s a problem.

In any case, the type of Reference should be decided based on the real
dependency of the document, not on its status.