Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09

"Ali Sajassi (sajassi)" <> Fri, 23 June 2017 00:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9AF5E129BAC; Thu, 22 Jun 2017 17:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Status: No, score=-14.522 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 uBIfUNZ1hznt; Thu, 22 Jun 2017 17:02:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7ECBD126BFD; Thu, 22 Jun 2017 17:02:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=10460; q=dns/txt; s=iport; t=1498176163; x=1499385763; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QUGHHKHschZjojemoPef5yv6jDoehOV2lXqhY7h0fjo=; b=e4CUxKV37LC3X9SowAZqI+nWOCTeqXQa21Dzt1BPJGFL3Oxhx2mh4C46 qTzEpylC7CnlI9R431Op8bcg9YRaLol5Tq8ay1IAKE5/oHPHMI0yXnZwE ijK/lnIa+Qnhhp1H3J3gZwsuxFe/+4fgG9QZ3IT+QqxHynFpnDJsCk4RU M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.39,375,1493683200"; d="scan'208,217";a="442323809"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jun 2017 00:02:42 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v5N02gsa030017 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 23 Jun 2017 00:02:42 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 22 Jun 2017 20:02:41 -0400
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Thu, 22 Jun 2017 20:02:41 -0400
From: "Ali Sajassi (sajassi)" <>
To: "Alvaro Retana (aretana)" <>, "" <>
CC: "" <>, "" <>, Thomas Morin <>
Thread-Topic: AD Review of draft-ietf-bess-evpn-etree-09
Thread-Index: AQHSrYuq8cG6jBFZoU6tpElXD7ib+aHswcQAgASc/gCAAA/rAIAoVP2AgAAz9wCAAHg2gIAXatKA
Date: Fri, 23 Jun 2017 00:02:41 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D571A38E20C47Esajassiciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-etree-09
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, 23 Jun 2017 00:02:50 -0000

Hi Alvaro,

I captured the IANA registry request for E-Tree flags in the latest rev of the draft (along with other comment resolutions):

This was your last AI to be completed.


From: "Alvaro Retana (aretana)" <<>>
Date: Wednesday, June 7, 2017 at 3:26 PM
To: Cisco Employee <<>>, "<>" <<>>
Cc: "<>" <<>>, "<>" <<>>, Thomas Morin <<>>
Subject: Re: AD Review of draft-ietf-bess-evpn-etree-09

On 6/7/17, 3:16 PM, "Ali Sajassi (sajassi)" <<>> wrote:



> 1)  I will get a registry for them set up when there will be more than one flag. Currently, there is only a
> single flag defined and we do not anticipate any additional flags at this point.

To be clear: without the registry defined the specification is incomplete.  If possible, consider the case where someone else (not one of the authors) wants to use one of the flags, what should be the policy for them to define it?  Should it be first come first served, or would the WG prefer a Designated Expert to review the potential assignment, is it ok for an experimental draft to request assignment, or is a Standards Track document the only way?

We've probably already written more text than the actual policy definition would take... <sigh>

> 2) regarding removing P2MP mention (so that it get generalized to MP2MP), I will do that but will
> add a sentence to say the other tunnel types that are supported by EVPN - e.g., currently P2MP are
> supported but in the future MP2MP can also be supported. So, I don't wan to exclude MP2MP. I can
> add his sentence during the RFC editing phase, is that OK?

That is ok with me.