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.
> 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. 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
