> On Apr 8, 2015, at 8:19 PM, Tom Herbert <[email protected]> wrote: > > 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.
Yes, although the solution space is richer, and the same is possible without defining encapsulation-layer fragmentation. Basically, when encapsulating, there are three potential options for fragmentation: Fragmentation after encapsulation — what we are trying to avoid. Encap and payload info is not carried after the fragmentation function. Fragmentation of the payload before encapsulation. The same encap fields can be used for all fragments. Fragmentation at the encapsulation header. #1 and #3 imply reassembly at the tunnel tailed/decapsulator (either at the IP or encap layers respectively). #2 pushes reassembly towards the receiving host. And fragmentation is cheap, what’s expensive is to reassemble. There is one more variable — I think the most important element in this, which has not been mentioned, is figuring out the path MTU (with PMTUD, etc) — because if you want to fragment at the encapsulation layer, which value do you use? An exemplary definition and description of these three can be found with L2TPv3: https://tools.ietf.org/html/rfc3931#section-4.1.4 <https://tools.ietf.org/html/rfc3931#section-4.1.4> specification of #1 and #2, plus generic description http://tools.ietf.org/html/rfc4623#section-5 <http://tools.ietf.org/html/rfc4623#section-5> specification of #3 (fragmentation at the L2TPv3 layer) Thanks, — Carlos. > >> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
