Hi Tom and Lizhong, I the strongest terms agree with your view that intermediate nodes should not use DPI to do flow steering. Decisions should be based on information expressed in the transport layer, not derived from the payload. Otherwise, active OAM cannot be viewed as in-band thus making interpretation of defects and performance metrics less accurate.
Regards, Greg On Sat, May 6, 2017 at 8:24 AM, Tom Herbert <t...@herbertland.com> wrote: > On Fri, May 5, 2017 at 6:39 PM, lizho.jin <lizho....@gmail.com> wrote: > > Tom, thanks for the reply, see inline below. > > > > Regards > > Lizhong > > > > On 05/6/2017 00:14，Tom Herbert<t...@herbertland.com> wrote： > > > > [Lizhong] Total option length will not solve the parser buffer issue. > > The parser buffer is located before parser, and for Geneve, implement > > 512Byte is the only way since the longest of Geneve header is > > 260Bytes. At least in some implementations as I know, hardware will > > firstly receive enough 512Bytes per packets, and send the 512Bytes to > > parser. Then parse will be able to skip over options to get inner > > payload. Did I have any misunderstanding? > > > > [Tom] Skipping header is useful so that transit devices can find the > > inner headers. The fact that there is no way to skip over an IPv6 > > extension header chain to find the transport headers of a packet has > > been a source of unhappiness. > > > > > > [Lizhong] That's correct, and if we have not any working around way, > > > > some device may fail to get inner header, just like IPv6 with too many > > > > extension headers fails to parse transport header. Currently many chips > > > > have this IPv6 extension header limitation. > > > > > > [Tom] The parser buffer limit applies to all headers a device wishes > > to inspect (some devices still may have less than 512 byte buffers > > also). The best way to deal with this is to minimize the length of > > headers. Geneve TLVs each have four bytes of overhead so they are less > > compact that other TLVs at similar layer (IP options, TCP options, > > IPv6 options each have two bytes overhead). The tradeoff made here is > > probably to simply alignment (I really don't see any rationale for > > needing 24 bits to identify options). Bit-fields are still better in > > this regard for being compact since there is no additional overhead > > per each option. > > > > > > [Lizhong] I suspect, a 260Bytes long Geneve header is an overload design. > > > > Since one of the purpose of NIC to parse inner header is to get a hash > value > > > > to do flow steering, one way is to define a Geneve TLV which SHOULD be > > > > at the first one to carry the hash value of inner 5-tuple, and also hash > > algorithm. > > > > Then NIC may only need to parse to the first Geneve TLV. > > > > Note that the source UDP port could not serve that purpose since that > port > > > > number could not be able to be predicted by the receiver. > > > Using the entropy in the UDP port number works perfectly well to get > ECMP or RSS for any UDP encapsulation including Geneve, VXLAN, GUE, > etc. If the UDP port number weren't good enough then the IPv6 flow > label can be used (and that works for _any_ protocol not just UDP!). > > The goal should be to discourage intermediate devices from doing DPI > into transport layer payloads. It requires a bunch of protocol > specific logic and any interpretation may be completely wrong since > port numbers don't have global meaning (e.g. if a device see a UDP > port destined to port 6081 in the network it may or may not be > Geneve). > > Tom > > > > > > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 >
_______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
