Thomas, I completely agree. This is an excellent way to provide linkage with the tunnel encaps draft.
Yours Irrespectively, John > -----Original Message----- > From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Thomas Morin > Sent: Monday, June 13, 2016 11:49 AM > To: bess@ietf.org > Subject: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. > draft-ietf-idr-tunnel-encaps > > 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-boun...@ietf.org on behalf of martin.vigour...@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:saja...@cisco.com] > >>> *Sent:* Tuesday, May 24, 2016 3:05 AM > >>> *To:* John E Drake; EXT -thomas.mo...@orange.com; IDR; BESS; > >>> draft-ietf-bess-evpn-over...@tools.ietf.org; Rabadan, Jorge (Nokia - > >>> US);draft-ietf-idr-tunnel-en...@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 > >>> > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
