> -----Original Message----- > From: Erik Nordmark [mailto:[email protected]] > Sent: 2015年4月9日 8:27 > To: Lizhong Jin; [email protected] > Subject: Re: [nvo3] Encapsulation considerations > > On 4/7/15 12:02 AM, Lizhong Jin wrote: > > Hi Erik, > > Thanks for the draft. I suggest to add one consideration: the > > generation of entropy value. > > 1. When the node receive an UDP/TCP packet from the tenant, then > > entropy value could be a hash value of 5-tuple. > > 2. When the node receive an IP packet from the tenant, then entropy > > value could be a hash value of 2-tuple. > > 3. When the node receive an Ethernet packet from the tenant, then > > entropy value could be a hash value of MAC address. > > 4. When the node receive an IP fragmented packet from the tenant, the > > first fragment is UDP/TCP, and entropy will be from 5-tuple. But the > > second and subsequent segments will generate entropy from 2-tuple, > > which will have different entropy value with the first segment. The > > issue could not be resolved currently if NVE is separated from tenant > > into two physical devices. > > Lizhong, > I've been assuming that the above issues are well-known, since entropy is > generated and used locally for LAGs and L3 ECMP even when there is no encaps. > Taking that entropy result and sticking it in a field in the packet doesn't > add to > the issues AFAICT. > I don't know if there is a document we can reference that states the above > general considerations for flow entropy/hashing. Has anybody seen such a > document? If so we can definitely reference it. [Lizhong] If the NVE and tenant is integrated into one device, then the issue could be solved by implementation. Because tenant know the entropy value of the first segment, and use the same value to the subsequent segment. So different implementation model could provide different entropy value. Or do we need other mechanism to mitigate this issue, e.g., fragment on NVE in draft-herbert-gue-fragmentation.
> > > > For section 18.1.1, I suggest RFS should be analyzed. E.g., if NIC > > want to do flow steering based on the inner header information, then > > it could use entropy value instead of the inner header information. > Did you mean Receive Side Scaling (RSS)? That is mentioned in the document - > section 18.1.1 . Perhaps the RSS text can be improved. > Receive Flow Scaling is the name of a Linux software technique to take into > account the CPU on which the application is running, which is different. [Lizhong] I am referring to hardware based flow steering, similar with Accelerated RFS (Receive Flow Steering). In the NIC I/O virtualization, the NIC will directly trigger interrupt to the CPU where application is running by looking up a flow table. We will use the inner header to do the flow table lookup, if hardware could not parse the inner header, then entropy value in the encapsulation is required. Any design of hiding inner header information should consider above implementation. Regards Lizhong Jin > > Thanks, > Erik > > > > > > Regards > > Lizhong > > > > > >> -----Original Message----- > >> From: Erik Nordmark [mailto:[email protected]] > >> Sent: 2015年3月26日 5:01 > >> To: [email protected] > >> Subject: [nvo3] Encapsulation considerations > >> > >> > >> I presented part of this at the most recent NVO3 interim meeting.The > >> full > > 12 > >> areas of considerations where presented at RTGWG earlier this week. > >> The draft is > >> http://datatracker.ietf.org/doc/draft-rtg-dt-encap/ > >> and the slides are at > >> http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-8.pdf > >> > >> There is probably additional things in there to consider for NVO3, > >> and > > advice > >> that can be reused to make it easier to move NVO3 forward. > >> > >> Regards, > >> Erik > >> > >> > >> > > > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
