> 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://tools.ietf.org/html/draft-ietf-nvo3-geneve: 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://tools.ietf.org/html/rfc5389#page-6. > 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://www.ietf.org/mailman/listinfo/nvo3
