I agree. We should be discussing whether or not we need:
1) yet another encapsulation.
2) how/if/why metadata
Incidentally point 2 is under discussion and part of the proposed
architecture in NSC.
--Tom
On Mar 10, 2014:10:10 AM, at 10:10 AM, Anton Ivanov (antivano)
<[email protected]> wrote:
> On 10/03/14 17:04, Lucy yong wrote:
>> Sorry, “Gross” in my previous mail means draft-gross-geneve-00.
>> The metadata is what is described in this draft.
>
> That is a "ready-baked" solution. It is not requirements.
>
> In order to "face off" GRE, VXLAN, Geneve (and L2TPv3 for that matter) you
> need to set the field.
>
> If you do not set the field by having requirements you can claim anyone being
> the winner - it stops being an engineering standards process.
>
> A.
>>
>> From: nvo3 [mailto:[email protected]] On Behalf Of Anton Ivanov
>> (antivano)
>> Sent: Monday, March 10, 2014 11:46 AM
>> To: [email protected]
>> Subject: Re: [nvo3] enhancing VXLAN/NVGRE vs creating an new encap
>>
>> Requirements draft? For metadata?
>>
>> Document id please?
>>
>> A.
>>
>>
>> On 10/03/14 16:32, Lucy yong wrote:
>> Hi All,
>>
>> GROSS brings a lot of attentions in this IETF meeting. VXLAN and NVGRE
>> defects for Network Virtualization Overlay (NVO) technology were extensively
>> discussed on nvo3 mailing list last year
>> (http://www.ietf.org/mail-archive/web/nvo3/current/msg02779.html) and the
>> enhancements on VXLAN and NVGRE for the technology were also proposed in the
>> draft-yong-l3vpn-nvgre-vxlan-encap-03 and draft-ietf-tsvwg-gre-in-udp-00.
>>
>> If we look at the geneve proposal, it addresses the defects identified in
>> VXLAN and NVGRE for NVO and has the essential key elements required by NVO
>> in the encapsulation header.
>>
>> Should we enhance VXLAN and NVGRE for NVO technology or create a new
>> encapsulation protocol for NVO? Industry (or major vendors (authors in
>> gross) in NVO) seems prefer the latter choice now. The benefit of the latter
>> is that having one encapsulation protocol for the NVO technology, which is
>> good for both vendors and operators. The “cons” is that we have a new
>> encapsulation protocol, which is not compliant with either VXLAN or NVGRE.
>>
>> So the question is should we quickly face out VXLAN and NVGRE with GENEVE
>> and have one encap. for NVO or we live with this pain ( enhance both VXLAN
>> and NVGRE for NVO and use both in NVO). IMHO: Having two encapsulation
>> semantics for the same technology is not good, the only reason we do it is
>> for the reality. Is this reality not true anymore by seeing the authors in
>> geneve?
>>
>> What should IETF do for NVO technology development? With current NVO3 WG
>> progress pace, it is not much except discussing the technology and solution
>> pieces on the mailing list. In the meanwhile, IETF keeps receiving these
>> informational drafts from the industry (precisely, the nvo leader vendors).
>> Which one will IETF publish as informational?
>> Does IETF really want working on NVO technology?
>>
>> Regarding medadata option in geneve header, I’ll express my opinion in a
>> separated mail.
>>
>> Thanks,
>> Lucy
>>
>>
>>
>>
>> _______________________________________________
>> nvo3 mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>>
>>
>> _______________________________________________
>> nvo3 mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/nvo3
>
> _______________________________________________
> nvo3 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nvo3
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
