Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps

Thomas Morin <thomas.morin@orange.com> Mon, 13 June 2016 15:49 UTC

Return-Path: <thomas.morin@orange.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 BF3BD12D549 for <bess@ietfa.amsl.com>; Mon, 13 Jun 2016 08:49:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.66
X-Spam-Level:
X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-1.426, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
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 OLodgxXX59kh for <bess@ietfa.amsl.com>; Mon, 13 Jun 2016 08:49:13 -0700 (PDT)
Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id CD86C12D112 for <bess@ietf.org>; Mon, 13 Jun 2016 08:49:12 -0700 (PDT)
Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 24A79E30090 for <bess@ietf.org>; Mon, 13 Jun 2016 17:49:12 +0200 (CEST)
Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id BB700E30088 for <bess@ietf.org>; Mon, 13 Jun 2016 17:49:11 +0200 (CEST)
Received: from [10.193.71.12] (10.193.71.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Mon, 13 Jun 2016 17:49:11 +0200
From: Thomas Morin <thomas.morin@orange.com>
To: bess@ietf.org
References: <5729F1C3.1030605@orange.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <SN1PR0501MB1709E1AF8C398791421E2123C77B0@SN1PR0501MB1709.namprd05.prod.outlook.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <SN1PR0501MB17099CA0122BA8B4C3F99E7EC77C0@SN1PR0501MB1709.namprd05.prod.outlook.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> <SN1PR0501MB170976E947BEABC8FD591ED8C77C0@SN1PR0501MB1709.namprd05.prod.outlook.com> <28175_1463566739_573C4192_28175_2444_1_613f729b-d12e-5c48-29a1-ff000c1184a1@orange.com> <SN1PR0501MB17090A6F0AC5D3D447E21C28C7490@SN1PR0501MB1709.namprd05.prod.outlook.com> <D369475E.1A2CD7%sajassi@cisco.com> <SN1PR0501MB1709EA8CE5E1B3C52862015DC74F0@SN1PR0501MB1709.namprd05.prod.outlook.com> <575680F5.2030101@alcatel-lucent.com> <D37C3C0F.1A9A44%sajassi@cisco.com>
Organization: Orange
Message-ID: <786b038a-bccb-28a7-30b9-73100e8f64f3@orange.com>
Date: Mon, 13 Jun 2016 17:49:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <D37C3C0F.1A9A44%sajassi@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/sAw7T68XOlHtJw9mj0ebge01ue4>
Subject: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 13 Jun 2016 15:49:15 -0000

Hi Ali,

The changes in -04 look good.

I would have one suggestion: say explicitly that the "use the label as 
the VNI" behavior is  the same as what the tunnel encap says.

This could be done by adding something like the following to section  
5.1.3 :

Note that the procedure defined here to use the MPLS Label field to 
carry the VNI in the presence
    of a Tunnel Encapsulation Extended Community specifying the use of a 
VNI, is
    aligned with the procedures described in [tunnel-encap] (Section 
"Use of Virtual Network
    Identifiers and Embedded Labels when Imposing a Tunnel Encapsulation 
" for "Labeled Address Families").

Best,

-Thomas



Le 07/06/2016 à 18:04, Ali Sajassi (sajassi) a écrit :
> Hi Martin,
>
> 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.
>
> Regards,
> Ali
>
> On 6/7/16, 1:08 AM, "BESS on behalf of Martin Vigoureux"
> <bess-bounces@ietf.org on behalf of martin.vigoureux@nokia.com>  wrote:
>
>> Hi,
>>
>> We are fine with keeping 5512 as the Normative reference for now.
>> We would think it wise if the editors can add an Informative reference
>> to draft-ietf-idr-tunnel-encaps (with some text indicating that both
>> specs provide the required support for the procedures).
>> The ideal situation would be that tunnel-encaps progresses fast enough
>> so that in the last stages before publishing evpn-overlay we can be in a
>> situation to make tunnel-encaps the Normative reference. RFC 4897 would
>> facilitate that by the way.
>>
>> If the WG has specific opinions on that matter, they are welcome.
>>
>> We take good note of the shepherd suggestion. We'll confirm who will
>> shepherd the document after WG LC (we'll also call for volunteers during
>> WG Last Call).
>>
>> Reviews are highly welcome anyway, in particular from people
>> close to the topic or implementations, and ideally from more than one
>> person, the best time being now or at least before the WG LC ends.
>>
>> We'll start the WG LC in a couple of days.
>>
>> Martin & Thomas
>>
>>
>> Le 24/05/2016 15:39, John E Drake a écrit :
>>> Hi,
>>>
>>> Ali and I decided to keep the normative reference to RFC 5512 rather
>>> than changing it to Eric¹s tunnel encapsulation draft because the
>>> normative reference pre-dates Eric¹s draft and because our draft does
>>> not use any of the new capabilities introduced in Eric¹s draft.
>>>
>>> Ali and I would also like to request that Jorge be the document shepherd
>>> for this draft.
>>>
>>> Yours Irrespectively,
>>>
>>> John
>>>
>>> *From:*Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
>>> *Sent:* Tuesday, May 24, 2016 3:05 AM
>>> *To:* John E Drake; EXT -thomas.morin@orange.com; IDR; BESS;
>>> draft-ietf-bess-evpn-overlay@tools.ietf.org; Rabadan, Jorge (Nokia -
>>> US);draft-ietf-idr-tunnel-encap@tools.ietf.org
>>> *Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs.
>>> draft-ietf-idr-tunnel-encaps
>>>
>>> Folks,
>>>
>>> I have updated and published rev03 of even-overlay draft.
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/
>>>
>>> The main changes are:
>>>
>>>   1. section 10.2 ­ DCI using ASBR
>>>   2. The setting of Ethernet tag and VNI fields ­ there were some
>>>      inconsistencies in different sections. Section 5.1.3 captures the
>>>      setting of these fields for different type of services in pretty
>>>      good details. All other sections were cleaned up and now refer to
>>>      section 5.1.3.
>>>
>>> Thomas,
>>>
>>> The draft is ready for its long-overdue WG LC considering how long its
>>> has been around and its multi-vendor implementation status.
>>>
>>> Regards,
>>>
>>> Ali
>>>