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

[John E Drake <[e-mail]>]

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:[e-mail]] On Behalf Of Thomas Morin
> Sent: Monday, June 13, 2016 11:49 AM
> To: [e-mail]
> 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"
> > <[e-mail] on behalf of [e-mail]>  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:[e-mail]]
> >>> *Sent:* Tuesday, May 24, 2016 3:05 AM
> >>> *To:* John E Drake; EXT [e-mail]; IDR; BESS;
> >>> [e-mail]; Rabadan, Jorge (Nokia -
> >>> US);[e-mail]
> >>> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess