Brian Carpenter wrote a paper (and had some slideware) indicating how
we can iterate the map-n-encap designs. So for each level of
encapsulation you have another x-to-y mapping with a separate mapping
database system.
I believe LISP can do this and is documented in the main LISP Internet
Draft. This is how we allow Loc/ID split to be done in site-based ITRs/
ETRs as well as by core-based TE-ITRs/TE-ETRs for ISP based Traffic
Engineering.
This is an example of "recursive tunneling" much like MPLS has a VC-
label inside of a transport-label.
We also see cases for "re-encapsulate tunneling" where an ETR sits on
a Data Center edge decapsulates for Loc/ID split purposes but is also
an ITR to add encapsulation for ETRs that are directly connected to
server host clusters. This is desirable for implementing server load
balancing where a virtual IP address (i.e. known as VIPs in the SLB
community) is used as an EID to lookup a set of RLOCs which have
measured load against them.
Dino
On Dec 10, 2008, at 11:35 AM, Shane Amante wrote:
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
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
