On Jul 13, 2017, at 12:31 PM, Linda Dunbar <[email protected]> wrote: > Dan, > > Thanks for pointing out the Geneve's processing for traversing VxLAN. > > First of all I wasn't proposing using reduced set of source ports. I think > that the general document needs to add the consideration for traversing NAT > because it is an issue for IPv4. Joe Touch suggested adding the entropy in > the IPv6 flow ID as a solution for IPv6. > > As for your suggested approach in Geneve: > 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. > > Does it mean all reverse traffic only use UDP port 6081?
Right, the reverse traffic is sent using destination UDP port 6081, and does not flip the 5-tuple. If it flipped the 5-tuple, then one NVE would have to start transmitting first, or we would have to build ICE (RFC5245) and add a signaling protocol between the datacenters (which ICE requires). > Or all the NAT device convert the NVE’s UDP port 6081 to multiple port > numbers? I don't understand 'convert ... to multiple port numbers'. -d > > Thanks, > Linda > > -----Original Message----- > From: Dan Wing [mailto:[email protected]] > Sent: Wednesday, July 12, 2017 6:09 PM > To: Linda Dunbar <[email protected]> > Cc: NVO3 <[email protected]>; [email protected] > Subject: Re: [nvo3] draft-ietf-nvo3-encap-00 should add considerations of > traversing NAPT > > > > 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
