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

Alvaro Retana <aretana.ietf@gmail.com> Tue, 05 December 2017 22:22 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D805E126B6D; Tue, 5 Dec 2017 14:22:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mE4PY3PtBVr; Tue, 5 Dec 2017 14:22:37 -0800 (PST)
Received: from mail-ot0-x242.google.com (mail-ot0-x242.google.com [IPv6:2607:f8b0:4003:c0f::242]) (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 15420124319; Tue, 5 Dec 2017 14:22:36 -0800 (PST)
Received: by mail-ot0-x242.google.com with SMTP id y10so1685589otg.10; Tue, 05 Dec 2017 14:22:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.157.20.225 with SMTP id r30mr22097335otr.187.1512512555519; Tue, 05 Dec 2017 14:22:35 -0800 (PST)
Received: from 895490483151 named unknown by gmailapi.google.com with HTTPREST; Tue, 5 Dec 2017 14:22:35 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <23037_1512483940_5A26AC64_23037_392_5_1512483939.26596.80.camel@orange.com>
References: <23037_1512483940_5A26AC64_23037_392_5_1512483939.26596.80.camel@orange.com>
X-Mailer: Airmail iOS (331)
MIME-Version: 1.0
Date: Tue, 5 Dec 2017 14:22:35 -0800
Message-ID: <CAMMESsxnrqXkViY0R9V5SMMx_Hi2et3C5d4oCJtpy0HSdwR5dA@mail.gmail.com>
To: Martin Vigoureux <martin.vigoureux@nokia.com>, bess-chairs@ietf.org, thomas.morin@orange.com
Cc: bess@ietf.org
Content-Type: multipart/alternative; boundary="001a113cdada97154e055f9f4562"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/52iSJ9VlCxsoBZ7zpYITi-gJvfY>
Subject: Re: [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: Tue, 05 Dec 2017 22:22:39 -0000

On December 5, 2017 at 9:25:39 AM, thomas.morin@orange.com (
thomas.morin@orange.com) 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:
>
> https://mailarchive.ietf.org/arch/msg/bess/z1J2VD9rtCQC7NHnmi_4tz_bR_w
>
> 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.

Thanks!

Alvaro.