[nvo3] Magnus Westerlund's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS)

[Magnus Westerlund via Datatracker <[e-mail]>]

Magnus Westerlund has entered the following ballot position for
draft-ietf-nvo3-geneve-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I want to discuss the implications of the source port usage and if that needs a
bit more consideration of failure cases and ICMP. So Section 3.3 says:

   Source port:  A source port selected by the originating tunnel
      endpoint.  This source port SHOULD be the same for all packets
      belonging to a single encapsulated flow to prevent reordering due
      to the use of different paths.  To encourage an even distribution
      of flows across multiple links, the source port SHOULD be
      calculated using a hash of the encapsulated packet headers using,
      for example, a traditional 5-tuple.  Since the port represents a
      flow identifier rather than a true UDP connection, the entire
      16-bit range MAY be used to maximize entropy.

I think using the different source ports to enable flow hashing is a nice idea.
However, I am a bit worried over the implications of using the full 16-bit
range without caveats. Specifically in cases where a network error or other
failure to forward the Geneve encapsulated packet and that result in any form a
return traffic towards the tunnel ingress. Such as ICMP Packet Too Big messages
or Port / Host unreachable. These messages needs to be consumed by the Geneve
tunneling endpoint to affect the right response to them. However, if the source
port is corresponding to any port where there exist a listenser or
bi-directional server on the tunnel ingress host, such as SSH, Echo etc. the
ICMP messages may be consumed by the wrong entity that only filter on source
port and not the destination port.

I believe this issue may require at least a explicit consideration in the
document.

Otherwise thanks for thinking through many transport issues for tunnels.