I have read draft-xu-ipsecme-esp-in-udp-lb-15. I have no major objections to adopting this document. It clearly is a short-term solution to the problems that ESPv3 also tries to address, and I'm okay with that.
I found some of the justification confusing/inaccurate. I think that it's a wording problem, not a technical problem. The document also lacks an IKEv2 part. 1. Why does it require public IP addresses? >As a result, many cloud service >providers allow customers to establish multiple IPsec VPN tunnels in >parallel to enable ECMP and increase aggregate bandwidth. However, >this approach is not ideal, as each tunnel typically requires its own >public IP address, leading to higher public IP consumption and >increased operational overhead It seems a pretty naive solution to add IP addresess. Anyway, there are 2^64 addresses per LAN, so maybe this is about legacy v4 stuff? 2. >[RFC6438]. However, as stated in [RFC6936], the end-to-end use of >flow labels for load balancing is a long-term solution and therefore >the use of load balancing using the transport header fields would >continue until any widespread deployment is finally achieved. As RFC6438 was 15 years ago. It's long past the "long-term" solution, and what I'm hearing is that despite 15+ years of requests, (ToR) switch vendors haven't bothered to implement this. Given that this document comes from a few vendors that make such silicon, this really rings hollow to me. Despite the comments about how this use of UDP encapsulation differs from RFC3948, I think it's exactly the same. I would expect the same silicon to be able to process both. The "Dest port=TBD1" is incorrect, and I do not think a UDP prot allocation is needed, or even desireable. What is different is that when the source port *changes*, that the change should *not* be communicated to upper layers to change where corresponding traffic is sent. That's really the key part of doing this. I also expect that this document will define an IKEv2 method of signaling the desired behaviour. Specifically, 1. "NAT is detected", but do not move IKEv2 from port 500. 2. Send my UDP traffic to port XYX. 3. Ignore changes in my source UDP port. I'm also unclear if more than one SA (SPI#) can be sent over the same UDP tuple. I think that a single SA be spread across multiple UDP streams, and this solves the ECMP side of the problem, but not the multi-core problem. I'm unclear if the single SA can *also* be sent via multiple IP destination addresses. That potentially also allows for ECMP via different IPv6 providers using PA prefixes. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ** My working hours and your working hours may be different. ** ** Please do not feel obligated to reply outside your normal working hours **
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
