I am in favor to publish three as informational because of existing implementations.
If the WG get consensus to work on one standards track encap., We should work out one IETF quality protocol that can last for a while and do not intend to match an existing implementation. Thus, I prefer use of GUE as the reference base for WG to work on. GUE has the best semantics among three: simple, extensible, complimentary for hardware and software implementation, and already specifies security, fragmentation, checksum-offload features. Objection to VXLAN-GPE: VXLAN-GPE format is wired and use of VXLAN-GPE+NSH to provide extensibility adds quite complex and burden. For example, NSH is designed for SFC, it has its own ver, OAM bit indication and SFC header. It is not clear that when VXLAN is used to carry SFC traffic, will Mandatory context header be used to carry SFC related meta data or for VXLAN related features. I don’t think it is good idea to bundle NVO3 encap. and SFC encaps. Together although SFC may exist in a NVO3 instance. Objection to Geneve: Geneve design is in favor of software implementation. Without specify TLVs, not sure what hardware can implement. Of course, we may have many pure software applications without interworking with a hardware component, which can benefit from the TLV design. GUE has a private field (optional) that can be used for this purpose in future. Thus we can avoid to specify two protocols in this WG. Regards, Lucy From: nvo3 [mailto:[email protected]] On Behalf Of Alia Atlas Sent: Tuesday, July 26, 2016 3:05 PM To: Joe Touch Cc: Tom Herbert; Michael Smith (michsmit); [email protected]; Matthew Bocci; Paul Quinn; Dino Farinacci; Jesse Gross; Larry Kreeger Subject: Re: [nvo3] Consensus call on encap proposals On Tue, Jul 26, 2016 at 3:50 PM, Joe Touch <[email protected]<mailto:[email protected]>> wrote: On 7/26/2016 12:42 PM, Alia Atlas wrote: ... The question is: (1) Should the WG move forward with one standards track encap? I've heard a lot of concern that we just can't do it, that it's too late, etc. I don't think it's ever "too late", but I also don't see consensus forming either. It may be that many folks are recovering from IETF and not responding yet. ... We can always flip a coin - if the solutions are technically equivalent and so is the support. That defines "random", not "consensus". It's not a preferred way - but it's a way of breaking a deadlock. Of course, the WG would have to have consensus on that being the decision process. Take a read through RFC 7282. I keep praising it because it gives really good perspectives. Joe
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
