Sounds perfect.
Thanks,
-Thomas
---- Ali Sajassi (sajassi) a écrit ----
Hi Thomas,
Referencing the section 8 of idr-tunnel-encap draft is too wide a scope
IMHO and maybe confusing, thus I'd like to narrow it down. I went over the
both sections 3.5 and 8 of the idr-tunnel-encap draft and with respect to
your comment, I’d like to narrow it to only section 8.2.2.2. ("When a
Valid VNI has not been Signaled”) with regard to its applicability to
evpn-overlay draft - to be more precise is the 2nd bullet of section
8.2.2.2. So, I’d like to change your suggested text to:
"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
section 8.2.2.2 of [tunnel-encap] (“When a Valid VNI has not been
Signaled”).
Cheers,
Ali
On 6/13/16, 8:49 AM, "BESS on behalf of Thomas Morin"
<bess-boun...@ietf.org on behalf of thomas.mo...@orange.com> wrote:
>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
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
