> On Jul 13, 2017, at 6:52 AM, Joe Touch <[email protected]> wrote: > > FWIW, why not just add the entropy in the IPv6 flow ID rather than > expecting it at the transport layer? Intermediate network devices should > be relying only on the flow ID for that entropy anyway.
I don't know if IPv6 routers do ECMP using flow ID, and I don't know if physical NICs do RSS CPU load balancing based on IPv6 flow ID. > (and yes, that doesn't solve the problem for IPv4, but perhaps that's a > good reason to encourage use of IPv6) Yeah, for v4 we're stuck with using source UDP port to provide the ECMP and receiver benefit. What of NAT64? -d > Joe > > > On 7/12/2017 4:08 PM, Dan Wing wrote: >>> On Jul 12, 2017, at 12:37 PM, Linda Dunbar <[email protected]> wrote: >>> >>> Sami, et al, >>> >>> >>> >>> The draft-ietf-nvo3-encap-00 is written very clear. >>> >>> >>> >>> However, the Section 6 (Common Encapsulation Considerations) should add a >>> sub-section on the consideration of traversing NAPT. Encapsulated traffic >>> could go to different data centers or WAN, which could go through Network >>> Address Port Translation devices >>> >>> >>> >>> Using VxLAN as an example: VxLAN specification [RFC 7348] uses a set of >>> Port numbers to achieve better traffic distribution among multiple paths, >>> which is fine within one data center, but causing trouble when traversing >>> NAPT. >> You're describing a problem with Geneve, which mimics VXLAN in that both of >> them suggest using a wide range of UDP ports to help underlay ECMP and to >> help receiver CPU load balancing, specifically this text of >> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnvo3-2Dgeneve-3A&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=uud2CHHWYVN8GxM5H4uIwsteqFFoakAhWdD8nCVDJKA&s=J0Hb0SpNIBjHmMAaoXKIM0W89HrWqzozPsq5n3qmD00&e= >> >> >> 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. >> >> If a reduced set of source ports is used instead, as you propose, the ECMP >> and CPU load balancing benefits are lost. That seems problematic. >> >>> NAPT use Port number to map back the source address. With a set of port >>> numbers, NAPT can’t easily figure out the reverse direction traffic’s final >>> IP addresses. >> The reverse traffic doesn't use the inverted 5-tuple. The reverse traffic >> is sent to the Geneve destination port (6081), and a firewall or NAT or NAPT >> mapping is necessary for UDP/6081 traffic -- on both datacenters, which both >> probably have their own underlay NAPTs. Those firewalls (or NATs or NAPTs) >> need to have appropriate pinholes for UDP/6081. >> >>> In addition, since the IP of packets change through NAPT device, it can >>> mess up the learning of the peer NVE used in encapsulation. >> The underlay did the NAPT, so I don't see a problem with the NVE overlay >> getting confused. Could you explain in more detail? >> >>> STUN can be used to get changed IP and port from NAPT device, but it >>> requires NAPT device support STUN. >> NAPT devices are not expected to implement STUN. STUN is expected to be >> implemented in the hosts behind the NAT and on a server on the other side of >> the NAT (usually on a server on the Internet). See Figure 1 on page 6 of >> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5389-23page-2D6&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=uud2CHHWYVN8GxM5H4uIwsteqFFoakAhWdD8nCVDJKA&s=TCHbljyS6SjK00_hvov-AWPmrDHVbyhVuV7ldIdWQoc&e= >> . >> >>> That’s not available in some scenarios. Furthermore, it can’t solve the >>> aforementioned five-tuple issue. >>> >>> >>> >>> VXLAN over IPSec may be used to deal with the above problems, >> Both Geneve and VXLAN run over UDP, and both use a fixed destination port >> (rather than inverted 5-tuple) for return traffic. Not sure how VXLAN >> succeeds at dealing with the above problems, but I would love to learn. >> >>> but IPSec brings up to 88 bytes of overhead plus the key distribution >>> management, which can lower the efficiency. >> Should be able to use IPsec transport mode, which is more around 40 bytes >> overhead. >> >> -d >> >> >>> >>> >>> >>> >>> Suggestion: Add Section 6.10 Traversing NAPT consideration. >>> >>> I can help to provide the text if you all think the suggestion is >>> acceptable. >>> >>> >>> >>> We can discuss more in Prague. >>> >>> >>> >>> Thanks, Linda Dunbar >>> >>> >>> >>> Huawei USA IP Technology Lab >>> >>> 5340 Legacy Drive, >>> >>> Plano, TX 75024 >>> >>> Tel: +1 469-277 - 5840 >>> >>> Fax: +1 469 -277 - 5900 >>> >>> >>> >>> _______________________________________________ >>> nvo3 mailing list >>> [email protected] >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_nvo3&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=60T3yKN2I7oCxe8OH9mfZix-2ykSSjL-P-RoXCkZGdg&s=q7A_LzZuDp-yZnlA7Xw_N7yuLk4HO7K07jgl3Z78Ixg&e= >>> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_nvo3&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=uud2CHHWYVN8GxM5H4uIwsteqFFoakAhWdD8nCVDJKA&s=rLTq8CpFk2GwGniHCqktWbL0-O8O-nNXMIfE0k5iodw&e= >> > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
