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

Alvaro Retana <> Tue, 05 December 2017 22:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D805E126B6D; Tue, 5 Dec 2017 14:22:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5mE4PY3PtBVr; Tue, 5 Dec 2017 14:22:37 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 15420124319; Tue, 5 Dec 2017 14:22:36 -0800 (PST)
Received: by with SMTP id y10so1685589otg.10; Tue, 05 Dec 2017 14:22:36 -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=wTr/CvAsOJHf3/DQmUyPu9cPBEM/Jn/gCoy/bG9dbIo=; b=p7PBWH9bDznqMRqFaaqvvTdaUlTRlW4R2mION/VUxs9NGqb7kw+zxTMyxPNiIWEAvx Gv2fKYRkLzDEDAu36RXZNRjp+2VYH0FPIHPRPb41mlBl+9kWp7L5QdyhgS+C3OVgezlc MXrU1jojyZTgI/YhEfJXhkVC7QSppx3b1F84BTSAjeUOcShkLrJeeRwHPhkvYEjulf8r SzRDuq99ArmgWdeaKY0asAHxGRxKX5Pw3Y8vhUEjXj0Gj1wDMBTW/OQHvgytZWrupfCG VpByIYTMebsPQTflCGckItP0qnkh3c8EAB8vYG9OJ+DipccBUVE29/435lqS4XSk3lpF YNJQ==
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=wTr/CvAsOJHf3/DQmUyPu9cPBEM/Jn/gCoy/bG9dbIo=; b=V3g3u4TPtIFeLr078LWbCWHGpXl9seXHjdSwbIt7Kc/NWkvSLP1q/j+rHHjAQhnMez f3UdBtdPps3BQLlOekX67PLnwya83QvJftAyLRjUREj2UKPsaCaQ9YjW4RYdITmcQNps ETysVr2WQgr8loZN2ZojDVhqmG9HeQiwegBPV4VgjrBFUiZ7917Zxtt2tCZ/IvLaK393 yc89x2qVdwnl3b8atBn7ttP//QvsWArDs7bGYLTaQgE00tVinciii7fACerGz0bLQOmo oqZXi9h0tLjWhwI+0AKHfWX2vFxlYj/tusZlUDgRUuW6RB5+6pEArr2T4NmKfQGc9LAa kBpA==
X-Gm-Message-State: AJaThX64Qywx81XoFruoqEKzRpFlx1LBh0whHvRI4TDcpq8MdFpOXQyf fECo506A7qrn1Kzrut9XW1r5/gLtgpruKBkZHQk=
X-Google-Smtp-Source: AGs4zMZcwKNnD8aF5Eq4QOE6k0NhoqiZrDrii7HScuAXvp3rc6tVR4EsqjbKGjuRemsn5dMVhOgsc8f6MYjhtPZTerM=
X-Received: by with SMTP id r30mr22097335otr.187.1512512555519; Tue, 05 Dec 2017 14:22:35 -0800 (PST)
Received: from 895490483151 named unknown by with HTTPREST; Tue, 5 Dec 2017 14:22:35 -0800
From: Alvaro Retana <>
In-Reply-To: <>
References: <>
X-Mailer: Airmail iOS (331)
MIME-Version: 1.0
Date: Tue, 05 Dec 2017 14:22:35 -0800
Message-ID: <>
To: Martin Vigoureux <>,,
Content-Type: multipart/alternative; boundary="001a113cdada97154e055f9f4562"
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: Tue, 05 Dec 2017 22:22:39 -0000

On December 5, 2017 at 9:25:39 AM, ( wrote:

> [...]
> M8. References
> M8.1. TUNNEL-ENCAP (aka ) 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.
> This was debated on a while ago, and this is somehow the conclusion of
> the discussion:
> Copy-paste:
> ----
> 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
> sufficient.
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
> 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.
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.