I fully agree with Dino's points. Before picking one of the three WG docs as a candidate to publish, we'd better evaluate whether those already published, implemented and deployed NVo3 technologies (see below) are good enough from the TECHNICAL point of view:
1. VXLAN (RFC7348 Informational) 2. NVGRE (RFC7637 Informational) 3. MPLS-in-GRE (RFC4023 Standards Track) 4. MPLS-in-UDP (RFC7510 Standards Track) My observation of the above four options is as follows: VXLAN: it was originally designed for Layer2 overlay only. That's the reason why it's called Virtual Extended LAN. However, due to the real demand for distributed gateways, Layer3 overlay is becoming more and more important. Although VXLAN can be used for Layer3 overlay by inserting fake MAC addresses, it seems a bit complex. That's the reason why VXLAN-GPE was proposed. NVGRE: it can be used for both Layer2 and Layer3 overlays. However, its ECMP capability is not good enough due to the following two reasons:1) the GRE key field based load-balancing is not widely supported; 2) the length of the entropy field (one-byte) is not enough. That may be one of the major technical reasons why VXLAN is more popular than NVGRE as an MPLS-free NVo3 encapsulation. MPLS-in-GRE: it can be used for both Layer2 and Layer3 overlays. More importantly, it can be used for interconnecting DC VPN and WAN VPN (i.e., MPLS-based VPN) in a much scalable and seamless way (i.e., by using inter-AS option B). This is a significant advantage of those MPLS-based NVo3 approaches (e.g., MPLS-in-GRE and MPLS-in-UDP) over those MPLS-free NVo3 approaches (e.g., VXLAN and NVGRE) in the hybrid cloud scenario. That's the reason why many DC network vendors recommend using MPLS-in-GRE rather than VXLAN/NVGRE for the traffic moving across DC gateways in their DC solution whitepapers. However, its ECMP capability is almost the same as NVGRE (i.e., the GRE-key based LB is not widely supported). It seems a bit pity that the NVo3 WG didn't pay enough attention to the hybrid cloud scenario where it's much desirable to interconnect the DC VPN and WAN VPN in a much scalable and seamless way. MPLS-in-UDP: Similar to MPLS-in-GRE, it can be used for both Layer2 and Layer3 overlays, and can be used for interconnecting DC VPN and WAN VPN in a scalable and seamless way (i.e., by using inter-AS option B). In addition, the use of the UDP tunnel could leverage the UDP five-tuple based load-balancing capability very well. Best regards, Xiaohu > -----Original Message----- > From: nvo3 [mailto:[email protected]] On Behalf Of Dino Farinacci > Sent: Wednesday, July 27, 2016 12:31 AM > To: Michael Smith (michsmit) > Cc: Tom Herbert; [email protected]; Alia Atlas; Matthew Bocci; Paul Quinn; Jesse > Gross; Larry Kreeger > Subject: Re: [nvo3] Consensus call on encap proposals > > The IETF should not encourage more options. Standards are suppose to unify > interoperability not cause more combinations. > > And every decade IETF picks 3 options. Just think if the IETF could produce > fast? ;-) > > Stop the bleeding, > Dino > > > On Jul 26, 2016, at 9:26 AM, Michael Smith (michsmit) <[email protected]> > wrote: > > > > Users already have to deal with multiple solutions for network > > overlays in the form of VXLAN and NVGRE. Neither of which is listed as an > option here. > > Picking 1 more solution or 3 more solutions won¹t improve that. > > > > On 7/25/16, 6:57 PM, "nvo3 on behalf of Tom Herbert" > > <[email protected] on behalf of [email protected]> wrote: > > > >>> I believe that others are in a similar position but opposite with > >>> regards to technical choices. The net result is that there are > >>> almost certain to be multiple formats in the wild regardless of what > >>> is decided here. Yes, that means letting the market decide rather > >>> than the IETF. I honestly don't necessarily see that as a negative > >>> since it means that it will be based on experience rather than > >>> theoretical arguments. I don't even think that it will cause more > >>> confusion or set back the industry given that timescales of > >>> ~5 years are being talked about for a new compromise encap if that > >>> were to come to be. > >>> > >> I would like to meet the user who thinks having multiple > >> interoperable solutions that do pretty make the same thing is a good idea. > >> > >> _______________________________________________ > >> 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
