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

From: "Ganga, Ilango S" <[email-masked]>
Date: Wed, 15 Jan 2020 23:32:33 +0000

Hello Magnus,

Thanks for your review and comments. Please see below for our responses inline, enclosed within <Response> </Response>.  Let us know if you are satisfied with this resolution.

Regards,

Ilango Ganga

Geneve Editor

-----Original Message-----
From: nvo3 <[email-masked]> On Behalf Of Magnus Westerlund via Datatracker
Sent: Thursday, December 5, 2019 6:16 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [nvo3] Magnus Westerlund's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS)

Magnus Westerlund has entered the following ballot position for

draft-ietf-nvo3-geneve-14: Discuss

----------------------------------------------------------------------

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.

IG>> <Response> In Geneve, the source port is used to encode an entropy value and the destination port is used to identify Geneve tunnel.  We will add the following text to the end of this paragraph in Section 3.3 to address your point that the generation of source port value and handling of return traffic should be managed by the tunnel end point implementation:

"The generation of the UDP source port (e.g. hash value) and the handling of return traffic to appropriate entity within the end point is managed by the tunnel end point implementation. Actual mechanisms to manage this is out of scope of this document."

</Response>

<End of Responses>

_______________________________________________

nvo3 mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/nvo3

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 16 Jan 2020 10:25:24 +0000

Hi,

Please see below. 

On Wed, 2020-01-15 at 23:32 +0000, Ganga, Ilango S wrote:
> Hello Magnus,
>  
> Thanks for your review and comments. Please see below for our responses
> inline, enclosed within <Response> </Response>.  Let us know if you are
> satisfied with this resolution.
>  
> Regards,
> Ilango Ganga
> Geneve Editor
>  
>  
> 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:
>  
> 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.
>  
> IG>> <Response> In Geneve, the source port is used to encode an entropy value
> and the destination port is used to identify Geneve tunnel.  We will add the
> following text to the end of this paragraph in Section 3.3 to address your
> point that the generation of source port value and handling of return traffic
> should be managed by the tunnel end point implementation:
>  
> “The generation of the UDP source port (e.g. hash value) and the handling of
> return traffic to appropriate entity within the end point is managed by the
> tunnel end point implementation. Actual mechanisms to manage this is out of
> scope of this document.”
> </Response>
>  

I think the above text is not particullar clear on what the issue is. Just to
make sure I am not missunderstanding anything. So the Geneve encapsulating
source node to avoid this issue has basically two possible implementation path
to correctly handle ICMP messages or any other return path traffic that reverses
the outer IP/UDP headers. Either it has a general listener that first try to
determine if the packet incoming is return traffic, or one only uses "free" UDP
ports on the outer IP address used when encapsulating. 

I am fine with you leaving how to solve this up to the implementations, but you
at least need to make the issue clear to the implementer. Also, I think it is
dangerouse to make assumption that the outer IP address will not be used for
anything else then GENEVE encapsulated tunnel traffic. 
 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ganga, Ilango S" <[email-masked]>
Date: Fri, 24 Jan 2020 23:30:37 +0000

Hi Magnus,

Thanks for your comments. Please see below for revised text that is more specific. We hope this addresses your concerns.

Thanks,

Ilango

-----Original Message-----
From: Magnus Westerlund <[email-masked]>
Sent: Thursday, January 16, 2020 2:25 AM
To: Ganga, Ilango S <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [nvo3] Magnus Westerlund's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS)

Hi,

Please see below.

> From: nvo3 <[email-masked]<mailto:[email-masked]>> On Behalf Of Magnus Westerlund via

> Datatracker

> To: The IESG <[email-masked]<mailto:[email-masked]>>

> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;

> [email-masked]<mailto:[email-masked]>

> Subject: [nvo3] Magnus Westerlund's Discuss on draft-ietf-nvo3-geneve-14:

> (with DISCUSS)

> I think using the different source ports to enable flow hashing is a nice

> idea.

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

> document.

Magnus>> I think the above text is not particullar clear on what the issue is. Just to

IG>> <Response> Instead of the previously suggested text, we will replace with the revised text below that is more specific in addressing the issue.

Add the following text to end of Section 3.3 source port definition (new paragraph):

“If Geneve traffic is shared with other UDP listeners on the same IP address, tunnel endpoints SHOULD implement a mechanism to ensure ICMP return traffic arising from network errors is directed to the correct listener. Actual definition of the mechanism is beyond the scope of this document.”

</Response>

Cheers

Magnus Westerlund

SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Jan 2020 09:14:00 +0000

Hi,

On Fri, 2020-01-24 at 23:30 +0000, Ganga, Ilango S wrote:
> IG>> <Response> Instead of the previously suggested text, we will replace with
> the revised text below that is more specific in addressing the issue.
>  
> “If Geneve traffic is shared with other UDP listeners on the same IP address,
> tunnel endpoints SHOULD implement a mechanism to ensure ICMP return traffic
> arising from network errors is directed to the correct listener. Actual
> definition of the mechanism is beyond the scope of this document.”
> </Response>
> 

The above works for me. Ship it and I will clear.

Cheers

Magnus Westerlund