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

Martin Vigoureux <martin.vigoureux@nokia.com> Tue, 05 December 2017 10:34 UTC

Return-Path: <martin.vigoureux@nokia.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 ADD16128AFE; Tue, 5 Dec 2017 02:34:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 6P8f_6mnodro; Tue, 5 Dec 2017 02:34:16 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0139.outbound.protection.outlook.com [104.47.2.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BF211292CE; Tue, 5 Dec 2017 02:34:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0qBJwLMswNS2mfIFnoUTYRtx1BismuDnr9RswiESQ9c=; b=qqd9eCBUOWww/v2Ko4bH3vP6dxq7pfzst46iadDObCOrLrwcgHT2kEhI/1UHz9DZyvc8hi6XvYRI8o/Dri1yUYWytEKjxTRq8Yrx2hu6ct+Vsiu+BZxIQKT278MQfKqYYQsTKy/D0iUjY4yivoDyjC4dj+6uUBET2wN1iLQrvcc=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com;
Received: from [192.168.1.5] (92.169.252.156) by AM4PR0701MB2132.eurprd07.prod.outlook.com (2603:10a6:200:49::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Tue, 5 Dec 2017 10:34:11 +0000
To: Alvaro Retana <aretana.ietf@gmail.com>, bess-chairs@ietf.org
References: <CAMMESsw2x53Av-_zi5nL5czKCXYmi_mk0i6qyYYZDYHE8oo_tA@mail.gmail.com>
Cc: Thomas Morin <thomas.morin@orange.com>, bess@ietf.org
From: Martin Vigoureux <martin.vigoureux@nokia.com>
Message-ID: <3ca43a6b-2716-ff87-76da-ab520f23c6b4@nokia.com>
Date: Tue, 05 Dec 2017 11:34:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CAMMESsw2x53Av-_zi5nL5czKCXYmi_mk0i6qyYYZDYHE8oo_tA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [92.169.252.156]
X-ClientProxiedBy: HE1PR0802CA0015.eurprd08.prod.outlook.com (2603:10a6:3:bd::25) To AM4PR0701MB2132.eurprd07.prod.outlook.com (2603:10a6:200:49::13)
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: eb4a11aa-4a65-4b32-b1a6-08d53bcbb9a5
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(2017052603286); SRVR:AM4PR0701MB2132;
X-Microsoft-Exchange-Diagnostics: 1; AM4PR0701MB2132; 3:5Atn0BO2DB/Bcm6mbtKW7Z5AFlr9VKDwbxyK22AgMpSPuYxg/SRUV0f/BDoDX0CIzjxRL0wUO93pci7+8kVNrQeF+r6LUME2yik8t9X/IDVjNxs2U52Snm9ab+sZDdMOy4pcM6sw8vWWsRjGccGIbyMrdLYYc8TRESLgVNyIA+G1GkEt1V28JGeia3V32SXicdmwq0HP0TYIACS2aPJc9VBmlEeQgLVRqyR0ay/04VTBxZyfJlgvufH5fm5+q6BJ; 25:iTdmsQ4+ZVoYmfsyPwfFiilQ+AuBRc2DfcDn/++9DCXJyEA8Mzdeufvpb6BX0NZ+olXSmcMLVJsIYXZz5gt5reCHSmnOH+3+lJdGqmhHQ5sLBiEoCWM5UdF1+wOv6HvvNb8lLmzs6mGPYIfkUYmrFr0FjUJgAevINUFhd8C7kCb4Sd4v2+gFrHiV/U/NDsf71O0Prc7fxB4DhHaH3kBIQxVMES42koLuA8bWtU9HyflVH16jhw8ardCO17tKyBqHSPf/rYqJ0uZ3yPiiIwm+/j4bFXRi2U0se/L6QLlZFJ222vHl8OyjETT/op9dflzhSraSDsA9GHtj0CjRHokt4A==; 31:wWCHN2yEkFVhuFTohwgfPGgBNfhrHIQRSGgMFXf5c0T9JmsTWZj4p5tylTsxzVRvAwmO6M0so3gisRFkedGz79sYv8nGGIhBcF5JeVuCovUgSY1qMcMnFwTnge3ZiBM1glPZDcIFkm+5WOg8VEHSC5r601j23srzPOqyCAfBhMy+6UWAR0SFAdLbuQ8ypp8MeeKNy2pEp/HuuAULLH+uZucK03qigpLsY5HMEUJJ4zI=
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AM4PR0701MB2132:
X-Microsoft-Exchange-Diagnostics: 1; AM4PR0701MB2132; 20:0FcHGcNUtxe3WkCEDJP2v1BpCUkq7zOkrw8YHLTp6Do129QtcxaMJCCnsK2vKlRfNB9ML4q61vfes1e5Ddn89Z9iYY8JvXppWPxuL55oGHvbzSqylNoKVkn+TewjasPy4Y/cDKnkuHOQPfDJp+JrWNkLe3ooYtDMXzfSHwjJmTb+fnFmyVYsckyCHHf4YwahoVjI/IosQWUOiYm6qHeRZEwhc/Zz2+BOiCBRQrBX5wXYDn6Mq75AEHu4iQb5M0p/nfbw90rFOFVXASO7q8nyIukUqIDFjqIA3Eho/DxPt6w0inIEAdg5vmmfwP0PCLlG+kjm7VdGytsrNG+d5VdIXsH0C+CqU+wt0XOAuOmKfiMLfCpL142T9ZcImDwWX78a25UP22e1dj+W7gjVdRK2lYdilmGqtUc50SYmtZM25yczVkaZeKBrqPcsx8bhEDHG9cQ3MMT2+RQrHgI5U4mwOYZlWAzrhtvNb2H+WVEtR6ayJLron5XI0FF+0C82+uaw; 4:V7PAh+E+CyaLPclytD9TCHmoDwZwj47Dih9ZSggyXaLjPxvrsB2TmaUYZTEC2ZYs9irSqD00qK5/tzHOs28yqR9JnGqX2I+oPKx/hlodyMwETC+mssQ1nU9jdA8zr2oRIdnfIJFpkydWuHsa64cdYzqljZWUqpDjAeFpvePbaVpQYIoVShuWpKaeFGisPGPRg/oIffJqCNYAMg6cOXBXiOmXHao+m35gKkkyABs0Rk4XX9kYXGkZH/W1VrZXPTd6Tlm0vQ75LOzki+Yt5XwPs61dujdpHCNi/g5cH2YCrmkmyZRn4kIO44J0annRnkIp
X-Microsoft-Antispam-PRVS: <AM4PR0701MB21322DBCB26B46321BAA5F7A8C3D0@AM4PR0701MB2132.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(192374486261705);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231022)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(6072148)(201708071742011); SRVR:AM4PR0701MB2132; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR0701MB2132;
X-Forefront-PRVS: 0512CC5201
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(39860400002)(346002)(366004)(376002)(51444003)(189002)(199003)(6306002)(105586002)(52146003)(16526018)(64126003)(2486003)(77096006)(23676004)(6486002)(3846002)(36756003)(31696002)(6116002)(25786009)(575784001)(86362001)(67846002)(83506002)(117156002)(66066001)(65806001)(47776003)(65956001)(31686004)(189998001)(97736004)(230783001)(50466002)(68736007)(7736002)(33646002)(2950100002)(58126008)(305945005)(6666003)(229853002)(16576012)(316002)(106356001)(2870700001)(2906002)(5660300001)(65826007)(52116002)(8676002)(81166006)(81156014)(478600001)(53936002)(6246003)(39060400002)(966005)(54356011)(76176011)(101416001)(8936002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR0701MB2132; H:[192.168.1.5]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1;AM4PR0701MB2132;23:BxzIKsIDPSwSGW46DGQYeUZ2qjzzR9MtpdzHhdVyjPiTZaVuv2fxdzOeP1P5Bgg3HEOe8YEKR1i4pmDBuGYEt3hEjAvOBnwcjol2hefmSANzBrsZic05bEjG70PkcSVrDo6BLlO8//apyA2nKdhBqDgxUnZxJ0tbZn1yHD3OH6k0uvmybzhy7KWN8e4GHbPktcW0xwj283cYcJ8KM9k34FVIDEMMybZ10Tu+izXAc2NYIvCIJtnhutJGUu8WUzEe+OFzZPAIwv0rAYUc+MgxoBCNO63xnzIMp7D4MfBjY8S64GluCsLf+QaNKoxtHFiU4qQHmwuPJaoSaiooNZX2MTkcEAy3v3i13Q8e/Qrp6Z1ugPrK8hgvtGz9LEy3B6xPof21QrwVEkqhx2rsGKAr9FO0bMKtNUljBGH8XmLfpbuwJ6S8+FSnCP6H3S8ZmKS95ErNAwk5OcGOA63ucSi7scDFmveAS0doqAEbtq3WpQE8T4nBQt443/LsaG5NB6Ze1Mu8kJX4VtAqgRfGblkTtrepwHQBsN4xHcnQ2S72j+qVppmSPJGigBGyP5+ceZaqvQmyc5Qrg8C3Lh+kPzJSSSFhbxVI2i5tU1/0GnEP1XwXUdtCALZX3vV/aeB9fw5TkGw9Gx0vB/yyHe2AvVZ6HYL2+WciBYcSuGWTCohsFccgy3eG55X9wYCcbiL0u53KkEOiqPHGj8kxWCic7Zq34NHoAVbNPZ0uRXm2SvFMGHTHDiKtzmqEdClAPNXQ8agad+Al7hlfdegzUizHuRuMOUoq6hA8iQueUPr9FIXt+bPWdg/O45VEChJo9UWW29yH/QbX2+xr0t1fT7/H2Auo8vc5Zqbxkv/KP2yZikj0bFZjKU+oGU+YSll/b/adyNqoDpp78/nku+m5V2f9sakfpOEEB3tAWv+SNPC5LrHIhhNLqbJiQh44d6Oyi+VTDgx81SUMztzXcVXJF53lNoECwInhUVSaum3yR6gCddKIguUnz9sMK5lfe01gEOFlHFjkfqWTKvxocQxMsRbdEKq4jqiBFyJoHvvF3c+isn/PHTijtSgUxNkQo+I42wjGIfHeIuAF+CWrZRHpvc8+30mMJYzgUpkW/GJgtQiZBNvmD9XoPsJNI2xFeEouuHYkMxL9giCXv2oEmOtEzaLnHfxm4AXG8fYZ0JYZ49kBp7JqOPfZWRIXZIqkRCBJGVWcPg7maHoAZqp9Xa8YyJoQvf7MZZLVef1uyyO8uAPOriUuwXMk9bPQH25/q0HeGNw7I6/+3qr+kp27brEtKO1Cncq0FkciqnZchuP8cBbobHmfGoVzS6gK9hLrMMr8jsd5Ztvtz1sRwDjdxf/y0L78YkZnDNJCH6wLQfb/46bLo8tGYvdJ2VXJiK1DtiQoc9mExrXB7KaDjKyAUz+uI4aTicrpA9dhQfHDVJOoO1PU8rsM1moFwGXY6RXqS3bejs9PBaRXQOTvy8uUeSg5ASObNaIIfxNSpP59kqQe8plS57NYouM=
X-Microsoft-Exchange-Diagnostics: 1; AM4PR0701MB2132; 6:xUZIaNBf7xJUEEscDCq9sMFge1BvGpa0gSvO9cieVikj2WqQ/xyMGf2T7pctndaOuLyG982fsMryWfGEk7IwTIBW0piEWJevnl8oLFujDDwzRXD2GpgOKBQ7nBEg85CtphtBXANKbQF7wFXOwRxl0UHBD1L4kNhu1koLgFg5Zu+8f9vEZGQ+vIOXSQ8N8I5UFB3eZWBMVuBRTTYIg87PpYxZB/YFFhrvXMXX/PeL/zV3ZXYNfB3xikX3a7VmjSsr1M4oaEICJ93LN1Oi42tDdLJj83HQS7YcwH1nfTifR/WRHyWhXXM0J/9hwgbG8VtEnC6JL3YR3SEyBS8bYS0L+mW4fBqJAkSEZVlugWLPKDs=; 5:69JR1a/1dLAEearEqvoKxeFkq8FM3unRvJMj8j5h3ne0LgaGE1Lx+3Q8uOcPJgsgywXPJiXCV1/wG59CB/giyDxS9pNPpfEGomiRZcuS1ye3gGVBJhlvwzrz+hHiY6h0zNF5DYn/Y1Nkfa7g3QhCDCM4hBcvNSwSmX4pWM9WRJw=; 24:xw5dMH/9Sa9BLuusg9pt/sdCO1MgJwrwVRph7UnrorSoRT0rRr/0o+9oNb8G8jBISgDMMuDExuUiQdn1eDYqiuN/OSVcebovT/Op9seM6PQ=; 7:ZsuOiR/Q2Z+z3lPjEuGlNwoIYgGqqCJ0MeUODg49WDs7sri/LZ3FAT6O8s4fK2R/wM6FJS36xFFkrjrFzfz9jtR7389mEHgPvSWDoyScf4Ib0k5Za4pREIans4ibAEJguaCzkNYJlI7nVPcTGZFVGoP6X8LiO5R4XR2VE73MNsW7bGl/0F6/EJ23QeWxTqnjnv6UyqchCgHkpsf0qNTG0ffiKx/J1FxeBbEqGJE3PTIuKF3eAUC/ms9LxKBGTLf8
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2017 10:34:11.6524 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: eb4a11aa-4a65-4b32-b1a6-08d53bcbb9a5
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0701MB2132
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/cYc7u9_KAiozxCsbwVa2_95vv8c>
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 10:34:20 -0000

Hello Alvaro,

thanks for your review.
Please see in-line regarding the two first points.

-m

Le 04/12/2017 à 22:49, Alvaro Retana a écrit :
> Dear Authors:
>
> I just finished reading this document (finally!).  I have a some
> comments (see below) which I think should be easy to address.
>
> I also have some bigger issues that we’ll need the Chairs’ help to solve:
>
> (1) Coordination with nv03
>
> For the Chairs:  Except for some clarification comments [1] related to
> the current version, I see no other traffic in the nvo3 list related to
> this document.  Was there some other coordination that I’m missing?   I
> am not questioning having this document in bess (that’s perfectly fine);
> I’m just raising the needed coordination with other WGs, from the
> Charter: "The working group will also coordinate with...NVO3 working
> group for coordination of protocols to support data center VPNs.”
>
>
> What about Geneve (draft-ietf-nvo3-geneve)?  The nvo3 WG is focusing on
> Geneve as the Standard encapsulation, but this document doesn’t
> even mention it.

Indeed. But The decision by NVO3 to work on Geneve is fairly recent.
I have indicated in the BESS report that we'll likely be working closeer 
with NVO3 from now on. An individual draft on the applicability of EVPN 
to NVO3 networks is targeting NVO3 WG. Conversely, an individual draft 
on EVPN extensions for Geneve is targeting BESS. We have agreed that 
we'll do cross reviews at the important milestones of these docs.

> (2) Document Status
>
>
> Why is this a Standards Track document?  The Abstract/Introduction say
> that “this document describes how Ethernet VPN (EVPN) can be used as an
> NVO solution and explores applicability of EVPN functions and
> procedures.”  -- if it’s just a description (as the text clearly is),
> and not a technical specification, then why it is not Informational?

> I can see how we could call it an Applicability Statement (rfc2026) and
> still publish it in the Standards Track.  If we want to go that way, we
> would need some minor updates to make it clear that this is an
> Applicability Statement and is not intended to stand in for a Technical
> Specification.  I am not clear on the process as it related to possible
> DownRefs (see below), but I’m willing to Last Call an Applicability
> Statement in the Standards Track…if that is what you want.

Maybe the authors should s/describes/specifies/ to better reflect the 
content of the document.
On the other hand, rfc2026 says "A Technical Specification is any 
description of a protocol, service, procedure, convention, or format."
It seems to match as well.

>
>
>
> Thanks!
>
>
> Alvaro.
>
>
>
>
> [1]
> https://mailarchive.ietf.org/arch/msg/nvo3/cd0hOfb966ROcL4t8JCrBD28bBg/?qid=c9f632dc5d6aab5e4b22972bb242baf0
>
>
>
>
> Major:
>
>
> M1. Section 5.1.2.1 (Auto Derivation of RT) shows a “packet format” to
> illustrate how the RT can be auto-derived.  Without any context, the
> description doesn’t make much sense: the fields are not described in
> order, the reader is expected to know about global and
> local administrative fields, the “A-bit” (or the Type field) are not
> mentioned in the description, people could probably guess that “D-ID”
> means “domain-id”, there’s no indication of what to do with that “packet
> format”, etc.  Please clean the description up, include clearer
> explanations and some references can’t hurt.
>
>
> M1.2. What about 4-byte ASNs?
>
>
>
> M2. From 5.1.3 (Constructing EVPN BGP Routes): “...routes MAY be
> advertised with multiple encapsulation types as long as they use the
> same EVPN multi-homing procedures (section 8.3.1, Split Horizon)…”. Is
> Split Horizon an example, or the only multi-homing procedure that should
> be considered?  Please be clear.
>
>
>
> 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?
>
>
> M3.2. "The Checksum and Sequence Number fields are not needed and their
> corresponding C and S bits MUST be set to zero.”  This is different than
> what rfc4023 specifies (not a problem).  If you’re specifying the
> setting of the bits, then you should be more prescriptive with whether
> the fields are included of not; suggestion: "The Checksum and Sequence
> Number fields MUST NOT be included and the corresponding C and S bits in
> the GRE Packet Header MUST be set to zero.”
>
>
>
> M4. In 7.1 (Impact on EVPN BGP Routes & Attributes for VXLAN/NVGRE
> Encapsulation)
>
>
> M4.1. These 2 MUSTs seem out of place as they are used to explain, and
> not in a Normative way: “ ..the RD must be a unique value per EVI or per
> NVE as described in [RFC7432]. In other words, whenever there is more
> than one administrative domain for global VNI, then a unique RD MUST
> be used, or whenever the VNI value have local significance, then
> a unique RD MUST be used.”  s/MUST/must
>
>
> M4.2. This SHOULD is also out of place because the standardization was
> already done in rfc7432 (this document is just mentioning it): “...as
> noted in section 8.6 of [RFC7432]...the single-homing ingress NVE SHOULD
> be able to…”. s/SHOULD/should
>
>
> M4.3. Section 10.2.1 then points back at the text in 7.1 using another
> SHOULD…again, s/SHOULD/should
>
>
>
> M5. 7.2 (Impact on EVPN Procedures for VXLAN/NVGRE Encapsulation) also
> includes a superfluous SHOULD: “...as noted in section 8.6 of
> [RFC7432]...a single-homing ingress NVE SHOULD implement…”.  s/SHOULD/should
>
>
>
> M6. The introductory paragraph in Section 8.1 (EVPN Multi-Homing
> Features) says that it is used to "recap the multi-homing features of
> EVPN to highlight the encapsulation dependencies. The section only
> describes the features and functions at a high-level. For more details,
> the reader is to refer to [RFC7432].”  However some of the 8.1.*
> sub-sections contain Normative language.  Is that Normative language
> specifying new behavior introduced in this document, or highlighting the
> recap from rfc7432?  If there’s no new behavior, then please use lower
> cases.  If there is new behavior, then it would be nice to clarify that
> in 8.1.
>
>
>
> M7. In 8.3.1 (Split Horizon), this MUST is out of place because it is
> not specifying anything: “...other means of performing the split-horizon
> filtering function MUST be devised.” s/MUST/must
>
>
>
> 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.
>
>
> M8.2. These should also be Normative: RFC7348, NVGRE, VXLAN-GPE, RFC4023
>
>
>
>
> Minor:
>
>
> P1. Please use the new Normative Language boilerplate (rfc8174).
>
>
>
> P2. From 7.1 (Impact on EVPN BGP Routes & Attributes for VXLAN/NVGRE
> Encapsulation): “...reduces the required routes and attributes to the
> following subset of four out of eight”.  Please either list the
> attributes that are not needed, or put in a reference to where those can
> be found. (rfc7432 ??)
>
>
>
> P3. From 8.3.1 (Split Horizon): "In order to prevent unhealthy
> interactions…”. I would really like to see more here: what does
> “unhealthy interactions” mean?  Can it result in loops or lost traffic
> or some other “bad” thing?   I note that even through you “prohibit” the
> configuration, you don’t go as far as mandating that it not to be used
> (MUST NOT), which makes me want to understand more the potential
> effects…if it happens, what are the risks?
>
>
>
> P4. In 8.3.3 (Unknown Unicast Traffic Designation): “...the ingress PE
> MAY use a flag-bit in the VxLAN header to indicate BUM traffic type. Bit
> 6 of flag field in the VxLAN header is used for this purpose per section
> 3.1 of [VXLAN-GPE].”  Suggestion: “…the ingress PE MAY set the BUM
> Traffic Bit (B bit) [VXLAN-GPE] to indicate BUM traffic.”
>
>
>
> P5. Security Considerations:  I find that the suggestion of IPSec may be
> out of place in this document; this document pretty much just talks
> about how to use EVPN, it doesn’t really introduce new capabilities, so
> unless IPSec is mentioned in rfc7432 (which is not — and not even
> mentioned in this section), or recommended in rfc4271 (which is not)
> then I would refrain from including such recommendation here.  In fact,
> I think that pointing at the Security Considerations of existing RFCs
> should be enough.
>
>
> P5.1. The reference to rfc4301 (beyond what VXLAN/NVGRE) mention seems
> like you’re trying too hard.  I would just put explicit references to
> the encapsulations since they should be dealing with security themselves.
>
>
>
> P6. References: [KEYWORDS] shows up twice.  I think that the reference
> to rfc4271 can be made Informative.
>
>
>
>
>
> Nits:
>
>
> N1. Section 3 (Terminology) literally transcribes several definitions
> from rfc7432/rfc7365 — while it is ok, I personally prefer just pointing
> at the definitions: it’s just easier to have the other RFCs be the
> authoritative source and not rely on maintaining the definitions in sync
> should they ever change.  Suggestion: “The reader is expected to be
> familiar with the terminology in …”.
>
>
> N2. s/the VNI value have local significance/the VNI value has local
> significance
>
>
>
> N3. s/it is recommend/it is recommended
>
>
> N4. Please be consistent in naming references, some list the RFC number,
> while others a name...
>