Re: [nvo3] Carrying entropy, was: draft-ietf-nvo3-encap-00 should add considerations of traversing NAPT

[Dan Wing <[e-mail]>]

> On Jul 20, 2017, at 7:19 PM, Dale R. Worley <[e-mail]> wrote:
> 
> Dan Wing <[e-mail]> writes:
>> Using Geneve VNI doesn't take us towards that goal, though.  On a
>> simple network, there is only one VNI (one virtual network), and if we
>> used solely VNI for underlay ECMP, all tunneled packets would go over
>> the same ECMP path.  We want each tunneled TCP flow to take one path,
>> and ideally the next tunneled TCP flow taking another ECMP path.
> 
> I'm mixing a number of points here.  In order from what I consider most
> important to least:
> 
> - It would be desirable to have a Geneve option to contain entropy, so
>  that in situations where outer headers don't provide a good place for
>  entropy, devices don't have to look further than the Geneve header.
> 
> - There is an unused octet in the Geneve header.  It might be useful to
>  define it to contain entropy for ECMP.  (Unfortunately, it's only one
>  byte.(

For both points above:   are there cases where the outer header can't provide entropy of the inner headers?  With IPv4, Geneve is carried over UDP and the UDP source port works fine.  With IPv6, Geneve is carried over UDP and the UDP source port and IPv6 flow label can both be used.  Is Geneve carried over something that isn't UDP?  Said another way, do we want to burn Geneve option bits (and MTU) with this entropy information?

> - ECMP can use as entropy any field which is "flow identification", that
>  is, where intermediate devices are allowed to disorder packets which
>  have different values of the flow identification field.  In
>  particular, any virtual network identifier serves as flow
>  identification.  Thus, we can specify in Geneve that any device
>  handling packets with Geneve headers can disorder packets with
>  different values of the VNI field.  But a consequence of *that* is
>  that in situations where the VNI field is not used to communicate
>  useful information (presumably the additional options are the reason
>  Geneve is being used), the VNI field can be used for entropy.

Feels like a lot of rules for a Geneve-aware router to follow for ECMP.  But it would be worth elaborating on this idea some more to see if it can become a simple rule for the Geneve-aware router.  I'm thinking:

  If packet is IPv6 and flow-label > 0 then EMCP hash of [ source IP || destination IP || flow-label ]
  elseif packet is UDP
      and packet is Geneve then ECMP using hash of [ source IP || Geneve VNI || Geneve-entropy option ]
      else ECMP using hash of [ source IP || destination IP || source UDP port || destination UDP port ]
  elseif packet is TCP or SCTP or DCCP
      ECMP hash of [ source IP || destination IP || source TCP/SCTP/DCCP port || destination TCP/SCTP/DCCP port ]
  else
      don't ECMP

(This is starting down the path of a Router Requirements spec.)

-d