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. 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. In addition, since the IP of packets change through NAPT device, it can mess up the learning of the peer NVE used in encapsulation. STUN can be used to get changed IP and port from NAPT device, but it requires NAPT device support STUN. 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, but IPSec brings up to 88 bytes of overhead plus the key distribution management, which can lower the efficiency. 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://www.ietf.org/mailman/listinfo/nvo3
