Hi Tom, See inline below. Regards Lizhong
> -----Original Message----- > From: Tom Herbert [mailto:[email protected]] > Sent: 2015年4月9日 8:20 > To: Lizhong Jin > Cc: Erik Nordmark; [email protected] > Subject: Re: [nvo3] Encapsulation considerations > > On Tue, Apr 7, 2015 at 12:02 AM, Lizhong Jin <[email protected]> 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. > > > This is a problem common to IP fragmentation. If the NVE is doing the > fragmentation, we have the option (like in > draft-herbert-gue-fragmentation-00) of fragmenting before the packet before > encapsulating, so that each fragment still uses the same encapsulation and > entropy value. [Lizhong] NVE fragmentation could work if we could prevent the tenant from fragmenting the packet. But if NVE is separated from tenant, we need additional mechanism to notify the tenant. > > > 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. > > > Yes, that is the intent. There is some risk in that over a single tunnel we > would > only have 14 bits of entropy but possibly many thousands of flows so that > there > are collisions. This shouldn't be any issues as long as the implementation > take > collisions into account and the cost of collisions is low enough. Some > alternatives are use IPv6 flow label for addiotnal 20 bits of entropy, or > parse the > inner packet if we really need to uniquely identify the flow. [Lizhong] Yes, 14bit could only provide 16k flows. But I have already seen some design of 32k or more flows for hardware flow steering. > > Tom > > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
