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]; [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
