Hi Tony,
>-----Original Message-----
>From: Tony Li [mailto:[EMAIL PROTECTED]
>Sent: Thursday, November 27, 2008 1:12 AM
>To: Fleischman, Eric; 'Brian E Carpenter'
>Cc: [email protected]; 'Noel Chiappa'
>Subject: Re: [rrg] Map and Encaps
>
>
>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.
With RANGER/VET/SEAL, hosts can play in several ways:
1) They can connect to a link behind an ITR/ETR
2) They can perform encapsulation/decapsulation themselves
3) They can connect directly to the native IPv4 Internet in
Exactly the same way as they do today.
4) They can connect to an IPv4 enterprise, and connect to
the IPv4 Internet through a NAT in exactly the same way
as they do today.
So, we don't see a full departure from the current architecture
at all. To the contrary, we see the extant IPv4 model carried
forward in next-generation enterprises and we see IPv6 coming
on line to satisfy the address scaling as well as map-encaps
coming on line to satisfy the routing scaling.
Fred
[EMAIL PROTECTED]
>
>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
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
