Hi Lucy, With respect to your two points:
1. I was saying that the ASICs that support ECMP for NVGRE, also support ECMP for MPLSoGRE because in both cases, they need to hash the GRE key. The MPLSoGRE key is 32 bit long compare to MPLSoUDP which is 16 bit long. So, if you think longer has value provides better ECMP, MPLSoGRE should perform better than MPLSoUPD. 2. Regarding your 2nd point, MPLSoGRE as well as VXLAN also provide the same separation between underly and overlay network layers. In all these cases, you have tunnel header (IP header), flow entropy (UDP header or GRE key), and client layer (MPLS VPN labels in case of MPLS client, or VNI in VXLAN header). So, MPLSoUDP doesn't provide anything extra here. Cheers, Ali From: Lucy yong <[email protected]<mailto:[email protected]>> Date: Monday, December 10, 2012 6:18 AM To: Cisco Employee <[email protected]<mailto:[email protected]>>, Aldrin Isaac <[email protected]<mailto:[email protected]>>, Melinda Shore <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 Hi Ali, I agree with Aldrin’s assessment as well. Regarding another encapsulation, here is other justification points. 1) When using NVGRE, there are only 8 bit flow entropy, this is not large enough for the flow space for a large tenant virtual network. 2) UPD encapsulation not only provides flow entropy but also makes a good architecture in decoupling overlay network from underlay network. In UDP encapsulation, the outer header contains underlying tunneling encoding (IP) and flow entropy (in UDP) and overlay data type (UDP). It does not include any overlay specific information such as virtual network ID, flow ID, etc. underlying network only processes the outer header and can perform the forwarding and load balancing. In short, that underling network do not use any overlay header at all. This is great metric from the architecture perspective. Regards, Lucy From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Ali Sajassi (sajassi) Sent: Sunday, December 09, 2012 1:05 PM To: Aldrin Isaac; Melinda Shore Cc: [email protected]<mailto:[email protected]> Subject: Re: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 Hi Aldrin, I agree with your statements on the application of MPLS and MPLSoIP in DC network, but my question is that do we need yet another new encapsulation. As you know and worked with us, we have successfully shown how E-VPN control-plane can be applied to VXLAN and NVGRE data-plane even without MPLS client layer and still maintaining the features/functionality in E-VPN. We also currently have a standard based for doing MPLSoIP using GRE encap and keeping MPLS client layer intact. So, in light of the above, do we need another encap? At one point I was myself thinking of MPLSoUPD but considering that any new silicons that support NVGRE also will support ECMP based on GRE key, I cannot justify another new encap anymore. Cheers, Ali From: Aldrin Isaac <[email protected]<mailto:[email protected]>> Date: Saturday, December 8, 2012 9:51 PM To: Melinda Shore <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 Historically there really was no MPLS enabled products that hit the right price points and/or features needed for the DC -- but some of us operators *have* implemented MPLS in the DC very successfully. My observation is that some vendors don't do MPLS/MPBGP very well and aggressively discourage its adoption, while other vendors reserve them for their SP products for which they need reasons to charge a premium. Now with support for MPLS in merchant silicon, I don't see any good reason why MPLS-based DCVPN solutions (IPVPN, E-VPN) should be held back, particularly if the overlay tunnel is IP-based and MPLS labels are used for VPN context, split-horizon, etc. On Thursday, November 29, 2012, Melinda Shore wrote: On 11/29/12 5:14 PM, S. Davari wrote: > Regarding Technical merits, all these solutions are technically > sound, the issue is that we don't want to have a dozen solution to > the same problem. Traditionally the IETF has let the market sort out competing technologies rather than try to deem one "best," but there's got to be at least some evidence that a technology will be adopted. I have to agree that MPLS in data centers is a tough sell. It would be great to see some input from data center operators to help sort this out. Melinda _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
