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

"Ali Sajassi (sajassi)" <> Fri, 08 December 2017 03:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39B70128B44; Thu, 7 Dec 2017 19:01:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AGd52WbUVN0P; Thu, 7 Dec 2017 19:01:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4412E12894A; Thu, 7 Dec 2017 19:01:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=28094; q=dns/txt; s=iport; t=1512702116; x=1513911716; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RiBpZ2AWW0YbuJpxo02bUdQPVmRVpxBwYYQhBQEpbh0=; b=eUTFCi3wmHf+Q25Yf2GZsr+yg17ap0A9Q6DZwQInfRdO9vO2hdcKOrrw GJZszTw9Bc+R2ONpaNQKBxgY5bsUkNOmMVSvqU+UmwOyqviOSG3py2tJ7 KMaRmRVEoptxG5/Tb7wr+zP3x3UpFDjM0mwXliLGCiq9N24chw6y9BhP0 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.45,376,1508803200"; d="scan'208,217";a="328027958"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Dec 2017 03:01:54 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id vB831saF021314 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Dec 2017 03:01:54 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 7 Dec 2017 22:01:53 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Thu, 7 Dec 2017 22:01:53 -0500
From: "Ali Sajassi (sajassi)" <>
To: Alvaro Retana <>, "" <>
CC: Thomas Morin <>, "" <>
Thread-Topic: [bess] AD Review of draft-ietf-bess-evpn-overlay-08
Thread-Index: AQHTbUnIE1F0wt2PNkWhZhKoHul01KM1focAgALDooCAAFLEAA==
Date: Fri, 08 Dec 2017 03:01:52 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.28.0.171108
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_A8721DD2C7434E4F843B86F1671A9170ciscocom_"
MIME-Version: 1.0
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: Fri, 08 Dec 2017 03:01:59 -0000

Hi Alvaro,

I took care of your remaining comments and published rev10 of the document just now. For more details please see my replies inline.


From: Alvaro Retana <>
Date: Thursday, December 7, 2017 at 6:07 AM
To: "" <>, Cisco Employee <>
Cc: Thomas Morin <>, "" <>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

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


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.

[Ali2] Done.




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?

[Ali2] Yes, I modified it to the following:

“…it is recommended that the GRE key field be present and be used to provide a 32-bit entropy value only if the P nodes can perform ECMP hashing based on the GRE key; otherwise, the GRE header should not include the GRE key.”

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.

[Ali2] Got rid off rfc5512 and moved the idr-tunnel-encap to normative.

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.

[Ali2] Done.