Hi Fred, |I haven't been tracking the host-based discussions all that |closely, but AFAICT they should be compatible with map/encap.
No doubt, but Occam's razor suggests that if we have one solution that fulfills our requirements, that that would be preferable to the juxtaposition of two solutions. |The Internet today is entering a transition phase in which |links with 1500 byte or smaller MTUs may soon be considered |legacy equipment in need of replacement - especially within |the core. The problem is less at the core than at the edge, where we are more bandwidth constrained and the scale of upgrade is much harder and where we are already talking about adding a significant overhead with the v6 transition. And the transition (as with all transitions in networking) never actually ends. |But, the mapping system gives the ETR a means for determining |the set of RLOCs from which packets that use specific EIDs may |originate. Do you seriously think that an ETR is going to verify the source EID against the source RLOC? Even after significant efforts today, we can't get source address anti-spoof filtering implemented to a significant extent. |>- 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. | |I'm not sure I get this; one of the key features of map/encap |is to arrest (and preferably reduce) routing table sizes which |AFAICT it does very nicely. Is that what you mean? Not at all. Let me see if I can try an aviation analogy. Today we have ample amounts of technology to construct UAVs that allow us to perform numerous hazardous missions while the pilot is safe, secure and comfortable. At the same time, we have most flights today where we actually spend multiple pilots per flight physically at the controls. One can easily imagine that we will, over time, find it more efficient to transition more air freight (e.g., FedEx) to UAV based flights. However, are we really going to move to passengers flown on UAV's? In some ways (and I admit that this is an imperfect analogy), map-&-encap asks our hosts to trust their transport to a technology that they can no longer interact with. How do we manage the underlying network? What happens when a host needs some exceptional service from the network? This seems problematic and complicated, when the root architecture of the network must be truly simple and elegant. Tony _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
