Thanks Nabil, I think in general there is a 'possible' requirement which adds a bit more clarity to the entropy question. You guys do not touch on this in your document but its 'possibly' implied by 3.4 "External NVO3 Connectivity".
Up until now the tunnels are assumed to begin and end inside the DC at the Vswitches , Gateways, etc. but to tunnel out using the same encapsulation they will encounter NAT .. so .... Possible Requirement: The NVO3 (where 3=IPV4) encapsulation MUST operates through NAT and ... entropy MUST be preserved. **if** indeed the above is a requirement I think that it it highlights issues with several of the candidate encapsulations over V4 as follows: * I suppose VXLAN would have problems through 1:N NAT because the source port (which is the source of entropy) would get overwritten. So the NAT would polarize VXLAN traffic? * Likewise I guess NVGRE would have problems because it does not support 1:N and in 1:1 mode (where the address bits=f(entropy)) it would affect global routing? V6 is looking better and better! Cheers Peter ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Bitar, Nabil N Sent: Thursday, May 24, 2012 8:06 AM To: AshwoodsmithPeter; Balus, Florin Stelian (Florin) Cc: [email protected]; LASSERRE, MARC (MARC); Bitar, Nabil N; Lizhong Jin Subject: Re: [nvo3] New dataplane requirements draft Hi Peter, Agree with Florin that we are not excluding solutions nor specifying a solution. Having said that and just a note, in the NVGRE case, I believe that the discussion twas hat the reserved field in the GRE header after the TNI could be used for entropy. Point talen on your comment. However, in your mind based on your comment, would using multiple IP addresses per NVE, effectively multiple tunnels between a pair NVEs and hashing flows to these tunnels be a solution that results in sufficient entropy for instance without having an explicit field in the encapsulation header for entropy? I think that could work but it comes at a disadvantage that can be avoided by having a field that can be use for entropy. We wiill look at the wording in the next rev. Thanks, Nabil From: AshwoodsmithPeter <[email protected]<mailto:[email protected]>> Date: Wed, 23 May 2012 13:55:51 -0400 To: "Balus, Florin Stelian (Florin)" <[email protected]<mailto:[email protected]>> Cc: Lizhong Jin <[email protected]<mailto:[email protected]>>, "LASSERRE, MARC (MARC)" <[email protected]<mailto:[email protected]>>, "Bitar, Nabil N" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: [nvo3] New dataplane requirements draft Hey Florin, Its just the wording to me implies a requirement for an explicit field or label that contains the entropy. Personally I agree its a good idea (its exactly what we did with 802.1Qbp), but perhaps dropping the 'field'/'label' wording and just indicating that 'the encapsulation MUST result in sufficient entropy to exercise all paths through several LAG/ECMP hops' is more inclusive at the moment? I don't think anybody will argue that entropy through a few LAG/ECMP hops is a MUST but you never know ;) Peter ________________________________ From: Balus, Florin Stelian (Florin) [mailto:[email protected]] Sent: Wednesday, May 23, 2012 1:20 PM To: AshwoodsmithPeter Cc: Lizhong Jin; LASSERRE, MARC (MARC); [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [nvo3] New dataplane requirements draft Peter, We were not trying to exclude any solutions, we tried to really focus on what the requirements should be. Note that the text does not exclude NVGRE anyhow.. We said "...and/or tunnelling methods" and I believe there was a NVGRE thread on this list where the authors discussed how this can be done using tunneling header. There was also some hall discussion in IETF on how this can be done with part of a GRE key. On the other hand we would like to hear from cloud providers on this: i.e. Is it a MUST or a SHOULD? Florin On May 23, 2012, at 8:38 AM, "AshwoodsmithPeter" <[email protected]<mailto:[email protected]>> wrote: In section 3.3.2.1 LAG and ECMP "encpsulation headers and/or tunneling methods MUST contain a 'entropy field' or 'entropy label' " This of course explicitly excludes NVGRE. I suppose for VXLAN the UDP SourcePort would be considered the entropy field. Was it the intention to exclude NVGRE? Peter _______________________________________________ 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
