Hi Eric, |My point is that wherever one discusses distributed |enclaves map-and-encaps is usually involved.
Thanks for your reply. I agree that for solving the particular problems that you're confronting, map-&-encap is appealing. Because it is apparently easy it would seem to have immediate attractiveness. Real estate brokers call this "curb appeal". Unfortunately, for those of us working a bit deeper into the architecture, our primary concern should be less about the exterior view of the edifice and more about its fundamental underpinnings. If the foundation of the building is unstable, no amount of glitzy exterior is going to turn the result into an acceptable outcome. A relevant famous computer science quote is: "Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem." (David Wheeler) All of the Loc/ID split solutions are precisely adding another layer of indirection and thus it behooves us to truly understand what problems we are creating. My concern is that if we turn towards map-&-encap solutions, where we can no longer actually run hosts in the native Internet architecture (i.e., without encapsulation), we have, in some sense, fundamentally given up on the ability of the host to act as a first class element in that architecture. Instead, it must now be shielded, protected from reality and encased in its private bubble of non-reality. Put another way: I see the strong appeal of a recursive architecture and I embrace that portion of the goal. However, all recursion starts with a base case, and it troubles me that the host cannot be an element of that base case. It implies that the base is flawed and has limitations in its functionality. Noel likes to say that the measure of an architecture is its ability to adapt to new requirements that are not yet forseen. What new requirements will arise in the base architecture where the fundamental lack of host participation will cripple us? Regards, Tony _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
