Hi Tom, see inline below. Regards Lizhong
> -----Original Message----- > From: Tom Herbert [mailto:[email protected]] > Sent: 2014年3月7日 0:42 > To: Lizhong Jin > Cc: [email protected]; [email protected] > Subject: Re: [nvo3] Fwd: New Version Notification for draft-herbert-gue- > 01.txt > > Hi Lizhong, thanks for the comments! > > On Wed, Mar 5, 2014 at 11:53 PM, Lizhong Jin <[email protected]> wrote: > > Hi Tom, > > In section 2.3, the 16bit 0s is redundant for a packet. I prefer the format > > like > below: > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | 0x0 | Hlen |V|SEC|R|R|P|P|E| Protocol | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > When Ebit = 0, protocol = 8bit IP protocol number. > > When Ebit = 1, protocol = 16bit EtherType. > > Then the ASIC could always use the combined 17bit (1bit Ebit + 16bit > Protocol) as an index to parse the payload. > > > We considered combining Ethertype and IP protocol into one field, but came > to the conclusion this isn't such a good idea. The points are: > > 1) Encapsulation of IPv4, IPv6, and EtherIP covers the vast majority of use > cases, so encapsulating L3 protocols is the point to optimize > 2) As you can see in your modified header format, EtherType needs an > additional 8 bits of core header. This only leaves 2 bits for future > extensions, > based on the rate at which fields were added to GRE that does not seem like > enough. [Lizhong] R-bits number is indeed an issue. But follow the definition rule of the security and private options in current draft, it is not extensible enough. It seems every new option will occupy some R-bits. Why not change the options to TLV like Geneve? The current definition of VNI is OK, but the security and private options could be TLV. If we change these options to TLV, then we could have more R-bits in the GUE header. > 3) Lookup of Ethertype is more complex than IP protocol because of the > larger space. A 64K lookup table (or in your proposal a 128K lookup > table) is prohibitive in many environments. For instance, on a 64 bit host > this > becomes a 1/2M (and 1M) of memory. The 256 entry IP protocol table is only > 2K memory. In fact, in Linux the EtherType lookup uses a hash table smaller > than 64K, while IP protocol is directly indexed in a 256 entry table. Note, > this > will also be issue with NSH. [Lizhong] as you said, 64k/128k table will not be implemented, and hash table with supported type number will be used instead. The 17bit I suggested is the hash key, and does not implicitly indicate the table size. > 4) I want to encourage that IP protocol = ESP becomes a common case :-) > 5) Allowing encap of GRE header for other L2 protocols doesn't seem > unreasonable. [Lizhong] my concern is the 16 redundant bits. At current header definition stage, it would be better if we could optimize the header. If GUE has been widely deployed, then by using GRE would be a compatible method. > 6) If you remove the UDP part of the encapsulation it looks a lot like an IP > extension header. This is not a coincidence! > > > In my mind, one of the potential use cases of the private fields is > congestion control. Currently, there is only TCP have congestion control > mechanism. Some other non-TCP traffics in DC also require flow based > congestion control. > > > On CC and encap: > > 1) It is extremely important to consider! The obvious need is for non- > conformant CC traffic-- basically anything from an untrusted guest > 2) It's very likely that an untrusted guest and host will both be doing CC, so > we need CC that doesn't interact poorly. > 3) DCCP is an possible option (IP protocol = DCCP) without needing to add > new fields, although it would be verbose (many fields, like ports, are > probably unnecessary). > 4) So congestion control probably warrants an additional field. I suspect it > should be variable length field like SEC to allow pluggable CC. > > Thanks, > Tom > > > Regards > > Lizhong > > > >> -----Original Message----- > >> From: Tom Herbert [mailto:[email protected]] > >> Sent: 2014年3月5日 4:05 > >> To: [email protected] > >> Cc: [email protected] > >> Subject: [nvo3] Fwd: New Version Notification for > >> draft-herbert-gue-01.txt > >> > >> Hi, > >> > >> i posted a new version of GUE (Generic UDP Encpasulation). I > >> appreciate comments, however please bear in mind: > >> > >> 1) This is not just for network visualization, we anticipate other use > >> cases. > >> Network virtualization is a very important use case. > >> 2) I do not claim that this solves all of the problems or addresses > >> all requirements of encapsulation or networking virtualization. As > >> far as I can tell, it does satisfy most of our needs for a generic > >> and ubiquitous encapsulation (in one large data center environment). > >> Even so, we still have need for other encapsulation protocols in different > contexts. > >> 3) Please take this as input for some requirements and potential > >> solutions when contemplating standard encap protocols. > >> 4) We did consider many alternate encapsulation protocols (see > >> motivation section). GRE was the closest to what we need, and in fact > >> the basic concepts of GUE are derived from GRE. GRE is very simple, > >> generic, stateless, allows for extensions, is amenable to efficient > >> HW implementation, and is suitable for high PPS applications. We > >> can't use directly GRE because adding new fields (extensibility) > >> breaks middleboxes which need to parse inner headers (header length > >> ambiguity with new fields). So in GUE we have a header length field > >> that can allow a device to skip over unknown options. Also, we chose > >> to encapsulate by IP protocol as opposed to the EtherType which is > >> more efficient and appropriate when doing L3oL3 encap (our majority use > case). > >> 6) GRE-like flag-fields are very limited and constrained compared to > >> something like TLVs which allow open ended extensibility. Their use > >> represents a trade-off. To their advantage flag-fields are very > >> efficient and simple to to parse. They are very compact, order of > >> fields in the packet is fixed, each field type occurs at most once in > >> the packet, and random access of specific fields is possible. I don't > >> foresee the need to add a whole bunch of new fields, and those add will > likely be generic supporting "pluggable" > >> semantics (like the security field in the draft). Other similar > >> generic fields we've contemplated are a long inner flow identifier, > >> QoS/classification, and congestion control. > >> 7) We have deployed a variant of this protocol at scale and it is > >> working pretty well! > >> 8) I have posted patches for the initial GUE draft on Linux netdev. > >> These implement IPIP/GUE, SIT/GUE, and GRE/GUE (also implements > >> GRE/UDP draft). In testing we did demonstrate the value of UDP > >> encapsulation to improve load balancing and steering in the network. > >> > >> Thanks, > >> Tom > >> > >> ---------- Forwarded message ---------- > >> From: <[email protected]> > >> Date: Tue, Mar 4, 2014 at 11:02 AM > >> Subject: New Version Notification for draft-herbert-gue-01.txt > >> To: Tom Herbert <[email protected]> > >> > >> > >> > >> A new version of I-D, draft-herbert-gue-01.txt has been successfully > >> submitted by Tom Herbert and posted to the IETF repository. > >> > >> Name: draft-herbert-gue > >> Revision: 01 > >> Title: Generic UDP Encapsulation > >> Document date: 2014-03-05 > >> Group: Individual Submission > >> Pages: 20 > >> URL: > >> http://www.ietf.org/internet-drafts/draft-herbert-gue-01.txt > >> Status: https://datatracker.ietf.org/doc/draft-herbert-gue/ > >> Htmlized: http://tools.ietf.org/html/draft-herbert-gue-01 > >> Diff: http://www.ietf.org/rfcdiff?url2=draft-herbert-gue-01 > >> > >> Abstract: > >> This specification describes Generic UDP Encapsulation (GUE), which > >> is a scheme for using UDP to encapsulate packets of arbitrary IP > >> protocols for transport across layer 3 networks. By encapsulating > >> packets in UDP, specialized capabilities in networking hardware for > >> efficient handling of UDP packets can be leveraged. GUE specifies > >> basic encapsulation methods upon which higher level constructs, such > >> tunnels and overlay networks, can be constructed. > >> > >> > >> > >> > >> 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
