Re: [RTG-DIR] RTG-DIR Telechat review of draft-ietf-bess-dci-evpn-overlay

Alvaro Retana <aretana.ietf@gmail.com> Wed, 21 February 2018 13:04 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573A0127077; Wed, 21 Feb 2018 05:04:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SNrOBIeLZnw; Wed, 21 Feb 2018 05:04:21 -0800 (PST)
Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (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 95F5C1200FC; Wed, 21 Feb 2018 05:04:21 -0800 (PST)
Received: by mail-ot0-x230.google.com with SMTP id s4so1314099oth.7; Wed, 21 Feb 2018 05:04:21 -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=BZ3mM8V1+vhblsTBZomJDJsS287vJgqDyRfqUAfolnA=; b=G36JhCMpmUwED3XogOndyRbYx/L2EomsVvIUG8igxIGG6d+3WGjxhBYvD9QO+cCZ86 BaTODINx2d17uqTNPBgX0K6RPF8euyWFoNa80mhZL9FCpQ11VJ6vZobrue0SVAJFj+GC p0yDwEocawUNb8en5ChyUvHN8JZxVMlNW0sIZu7ASKCJ9k80RK4srF/7xED8ltvHa3oi sSaKScW6uBzzsOPlCwnRKITrXiwjFuHx7G/7MW7sT5GQDY9B5DBXisn0ujDZfz43DcaZ oVM39RKTa4sl3vbxtlBhns1mwWpF22OafPE5J6IUHFF7CsIvmR+FE0h5OggN5j1ax/Mb 5UeA==
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=BZ3mM8V1+vhblsTBZomJDJsS287vJgqDyRfqUAfolnA=; b=kHW6HNg7LKlsl3lWhUPHgMbxKjgOWEMvA/YCCI1v6+AlcpCEAyQ55Ckffw5blUCXg0 DymSeo5Qe1BZ4FboviYZIbeg/rsIXN2NztlsiD8UAX89YrmG0+bM27ZWynJ54N5kkRnF 8kFH9ZFonBwd6I9osWtz8YVsexcNcq85lR/k0ZBydONb2dfOCWwvRU+vw4s16wHdw9Ve DIdu3hJZcIU0QusoRoEiN9Sfi+sK6A0EQSZUODQ7jtk26R9a2qqZlQyH4TghLZuskUjT lfMo4WGYUw7J7AknkP/QDuQg8Lzlr3golVi7RSBngbuiaukMNWqTJzN62OS2IMR65o8y iH0g==
X-Gm-Message-State: APf1xPCIrschCooePKD21RUiB/Uay/6m5n0aPSfoxYLrrF/4TxwNYjN/ z9PFfpB5cfbHrxWLRX8rtf2vjolSQf3jJNB9jsg=
X-Google-Smtp-Source: AG47ELte2F60txby4pCFUVTxO/1f/sN09doZWhn1wZJk6XTEAdnu4x4DA5BB3fTk2V8NbHusM4rUvE3VtXCqygAJIGQ=
X-Received: by 10.157.55.136 with SMTP id x8mr2180725otb.114.1519218260931; Wed, 21 Feb 2018 05:04:20 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 21 Feb 2018 08:04:20 -0500
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <381B2074-0F2C-4FED-8F1B-245B7196A80A@nokia.com>
References: <DB3PR03MB096972D1DF55006E50BECCA39DF50@DB3PR03MB0969.eurprd03.prod.outlook.com> <381B2074-0F2C-4FED-8F1B-245B7196A80A@nokia.com>
X-Mailer: Airmail (467)
MIME-Version: 1.0
Date: Wed, 21 Feb 2018 08:04:20 -0500
Message-ID: <CAMMESswK-Lf6sy=65LeSv7EK5RmC1QRDiUcmwbeQFV0kmAEcAA@mail.gmail.com>
To: Alexander Vainshtein <alexander.vainshtein@ecitele.com>, "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
Cc: "draft-ietf-bess-dci-evpn-overlay.all@ietf.org" <draft-ietf-bess-dci-evpn-overlay.all@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c000cfec79e990565b89097"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/RAem9KnXy_MUZtnbvBr-wHl__fQ>
Subject: Re: [RTG-DIR] RTG-DIR Telechat review of draft-ietf-bess-dci-evpn-overlay
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Feb 2018 13:04:23 -0000

Hi!

I see that the change below has already been made in -09.  However, I don’t
think that an Update applies in this case.

In general, when Updating another document we’re basically saying: “change
what was specified there for what is specified in here”…which, in this
case, translates to rfc7432 implementations having to also be compliant
with this document (for all cases).  As far as I can tell, the extensions
defined in this document are specific to the DCI case and not general to
any EVPN scenario.  If that is correct then we shouldn’t be formally
Updating rfc7432.

Having said that, Sasha is correct in pointing out that there are several
differences with respect to rfc7432.  That is properly captured in the text
at the end of Section 2 (for the DCI scenario), without the need for the
formal Update.

Thanks!

Alvaro.

On February 20, 2018 at 5:40:59 PM, Rabadan, Jorge (Nokia - US/Mountain
View) (jorge.rabadan@nokia.com) wrote:


1.       From my POV this draft should be marked as updating RFC 7432 in
its metadata. The update should refer to several aspects including at least
the following:

a.       Use of Ethernet PWs (see Figure 1 in the draft) as an Ethernet
Segment. RFC 7432 defines Ethernet Segment as a set of Ethernet links that
connect a customer sit to one or more PEs.

b.       Use of the Unknown MAC Route (UMR). RFC 7432 only says that a PE
may flood unicast frames with unknown destination MAC to all other PEs but
does not have to do that, with the decision being a matter of local
policy;  it neither defines any mechanisms that advertise a specific PE and
a specific Ethernet Segment attached to this PE as the “default next Hop”
for all unknown destination MAC addresses, nor prevents usage of such
mechanisms.

[JORGE] I marked it as updating RFC7432 and explained why in section 2.