Lucy, I don't doubt I'm missing something. But deleting the very statement that I wanted a clarification for and asking me to study hashing functions is not going to help me get the point.
The draft in question doesn't describe any specific hashing function either. It only claims that core routers cannot load-balance adequately for GRE packets. Depending on the definition of "core" routers and the timeline, the claim might be true. But it is not relevant because these core routers are not the ones people use to build large data centers today and tomorrow. Now please allow me bring your original statement back again, 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. So what is a large enough space to generate an entropy, by what kind of hashing function, and for what size of a network, if 8 bits is not sufficient? Numbers will work much better for me. Thanks. -- Yiqun From: Lucy yong [mailto:[email protected]] Sent: Monday, December 10, 2012 10:37 AM To: Yiqun Cai; Ali Sajassi (sajassi); Aldrin Isaac; Melinda Shore Cc: [email protected] Subject: RE: [nvo3] [mpls] MPLS-RT review of draft-xu-mpls-in-udp-03 [Yiqun Cai] If handled properly, 8 bits of flow entropy allows one to support 256-way ECMP. I'm not aware of any network that built using 256 way ECMP (or even close to it). Even accounting for polarization, I still fail to see why it is not large enough. Would you care to provide an analysis here? [Lucy] please read hashing function. You miss the point. Lucy Thanks. 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
