>> - I believe this would conflict with the proposal to add a protocol >> field to the VXLAN header. Overloading one field in a fixed header is >> not an adequate substitute for a truly extensible header. In the best >> case we could only use one or the other functionality in a given >> packet. In the worse case, overloading opens the door to backwards >> compatibility issues and the potential for misinterpretation of >> fields. >> > > I agree that we'd better avoid field overloading. But as stated in section 3, > it is not conflict with VXLAN-gpe, because when segmentation offloading > is enabled the encapsulated packet should always be Ethernet, and in > such case prototype is not needed. But you reminded me that, it should > be defined clearly that P bit specified by VXLAN-gpe MUST be set to 0 > when S bit is 1. We will address that in version 01. > > Or if you know any real (or potential) scenarios of conflict between > VXLAN-soe and VXLAN-gpe, please kindly point out and we can consider > using the remaining space in the header instead of overloading it. > If I were using VXLAN then I'd most likely use VXLAN-gpe and the common case would be protocol=0x800 (IPv4). I'm sure I'd want the full benefits of any offload capability, so it seems like using your feature in that case isn't feasible because of the field overloading.
Adding a bit for each interpretation of a fixed field illustrates another problem. Each use of the field must be mutually exclusively of the other uses. In this case the possible values for P and S bit are 00, 10, 01-- however 11 is nonsensical. If someone adds another interpretation of the field (related to OAM bit maybe), then this results in four legitimate values (000 100 010 001) in the three bits and four nonsensical values (110 011 101 111). For a fourth interpretation, there's 5 good values and so 11 bad values, and so on. It is an inefficient use of bit fields to design in invalid combinations of bits. I would suggest instead that three or four bits be grouped together as a type field. For example, in three bits 7 unique uses of the fixed field can be expressed. Tom >> Tom >> >> > So this is a practical yet generic proposal, which extends the offloading >> > concept >> > to from kernel stacks to remote end-points of overlay networks. >> > >> > The metadata for offloading is very similar to STT. There difference is >> > that: >> > 1. it doesn’t add fake TCP header to utilize NIC TSO. >> > 2. it doesn't include helper fields - just to save the limited VXLAN >> > header space >> for >> > other possible purpose in the future. >> > 3. VXLAN is widely adopted and this is only a minor extension backward >> compatible >> > >> > Based on this, it is highly recommended to add segmentation metadata in >> VXLAN >> > header as proposed in this draft. >> > >> > Any comments are appreciated! >> > >> > Best regards, >> > Han Zhou >> > >> > -----Original Message----- >> > From: [email protected] [mailto:[email protected]] >> > Sent: Thursday, March 13, 2014 10:29 PM >> > To: Zhou, Han; Li, Chengyuan; Li, Chengyuan; Zhou, Han >> > Subject: New Version Notification for draft-zhou-li-vxlan-soe-00.txt >> > >> > >> > A new version of I-D, draft-zhou-li-vxlan-soe-00.txt >> > has been successfully submitted by Han Zhou and posted to the >> > IETF repository. >> > >> > Name: draft-zhou-li-vxlan-soe >> > Revision: 00 >> > Title: Segmentation Offloading Extension for VxLAN >> > Document date: 2014-03-13 >> > Group: Individual Submission >> > Pages: 7 >> > URL: >> http://www.ietf.org/internet-drafts/draft-zhou-li-vxlan-soe-00.txt >> > Status: https://datatracker.ietf.org/doc/draft-zhou-li-vxlan-soe/ >> > Htmlized: http://tools.ietf.org/html/draft-zhou-li-vxlan-soe-00 >> > >> > >> > Abstract: >> > Segmentation offloading is nowadays common in network stack >> > implementation and well supported by para-virtualized network device >> > drivers for virtual machine (VM)s. This draft describes an extension >> > to Virtual eXtensible Local Area Network (VXLAN) so that segmentation >> > can be decoupled from physical/underlay networks and offloaded >> > further to the remote end-point thus improving data-plane performance >> > for VMs running on top of overlay networks. >> > >> > >> > >> > >> > Please note that it may take a couple of minutes from the time of >> > submission >> > until the htmlized version and diff are available at tools.ietf.org. >> > >> > The IETF Secretariat >> > >> > _______________________________________________ >> > nvo3 mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
