Scott, All,
On Dec 10, 2008, at 10:23 AM, Scott Brim wrote:
Excerpts from Noel Chiappa on Wed, Dec 10, 2008 09:23:07AM -0500:
From: Scott Brim <[EMAIL PROTECTED]>
A LISP EID names a network attachment point.
Well.... sort of. (And there are two kinds, IPv4 EIDs and IPv6
EIDs.) What
the IPv4 EID really names is whatever a vanilla 'IPv4 address'
names, which
is somewhat ambiguous itself.
It definitely names an entity with a collection of higher-level
protocols and
their ports (UDP, ICMP, TCP, etc). It also seems to name an interface
(because to get packets to a different interface on a dual-homed
host, you
need to use a different IPv4 address). This is another 'axis of
confusion'
with IPv4 addresses (which are also muddied on the location/
identity axis).
First I admit I wrote too quickly, because an EID might be
virtualized. We may be disentangling identifier and locator but we
still will not have disentanbled locator and "forwarding directive".
Second, the reason I said it names a network attachment point is that
from the point of view of the network -- which is what matters here --
it knows attachment points, not stacks or interfaces. But that's a
nit.
Related to your second point, I've also started to ponder the longer
term "flexibility" of a map-and-encaps approach. More specifically:
1) First, as time progresses, will components within/of the network
become more virtualized? In other words, isn't it increasingly likely
that we'll want to "name" not only network attachment points, but also
stacks, interfaces, virtual machines, processes, etc.?
2) Assuming that #1 is desirable (or required), how would the current
crop of map-and-encaps proposals (easily) accommodate that? For
example, are we reliant on both mapping and encapsulation (and, within
what "scopes") to accommodate the above, or not?
In summary, I'm asking: what is the roadmap beyond this "first-gen"
set of map-and-encaps proposals to attain those goals, (assuming
people agree they are valid goals)?
Although there's been a lot of emphasis on the feasibility & speed of
deployment related to specific (classes of) proposals, there doesn't
seem to have been much, if any, detailed discussion related to their
flexibility to accommodate, say, #1 among other things that we can
reasonably predict might happen in the near future. In the end, a
"roadmap" should also be given serious consideration when evaluating
all of the (classes of) proposals.
Thoughts?
-shane
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
