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