Eric,
|My personal belief is that I'd like us to converge soon on a |routing-only solution. I think that it is time to begin to wrap the |theoretical discussions up and proceed to modeling and simulation and |limited deployment experimentation. | |Failing that, I would like to better understand why the RRG community |hasn't yet converged on the desirability of map-and-encaps as a |desirable RRG vector. There is a portion of the community (significant, IMHO) that feels that there are significant drawbacks to the map-&-encap strategy. While I can't claim to represent all of them or even a significant breadth of their opinions, there are some issues that have been raised. - Map-&-encap doesn't solve the problem where it truly occurs: at the host. The convolution of locator and identifier happens precisely because the transport layer has reused the address as part of the connection identifier. Until we change this, we're simply band-aiding around the problem. And band-aids really aren't the way to create a lasting architecture. Please note that this also implies that routing-only solutions aren't the correct direction. - Map-&-encap comes with significant overhead. It adds another network layer header, and some additional per packet overhead. In changing the MTU, it requires additional mechanisms that some (tho I appear to be alone in this ;-) find concerning. - Map-&-encap creates some attack vectors. If an attacker sends you a packet from a forged (and possibly random) EID, and that causes you to respond and perform a mapping lookup on the forged EID, then the attacker can cause you to fill your mapping cache and thus create a significant performance issue. While it's already difficult in the Internet today to trace forged source addresses, it would seem like tracking forged EIDs will be even harder, as they are likely to come with addresses from forged ITR addresses. There are probably ways to address this, but they would seem to come with Even More Mechanisms. - Is virtualization really the right approach? It's been noted that map-&-encap is basically equivalent to running the entire Internet inside of a VPN, where the mapping function conveys the edge of the 'primary' infrastructure that terminates the VPN tunnels. Some find it architecturally disquieting to run our most essential function virtually when we find that we cannot run it natively. There are probably many other issues, but these are some of the ones that have been raised. Regards, Tony _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
