Hi Heiner,
> A shim is needed anyway.
Is this statement a general statement or only referring to to network
based solutions ? What do you call a "shim" in host based solutions ?
I would not call ILNP's splitting address space to provide a clear
division between ID/Loc as a shim or encapsulation.
Cheers,
R.
In einer eMail vom 06.01.2010 09:11:05 Westeuropäische Normalzeit
schreibt sh...@castlepoint.net:
The point of mentioning all of the above is that you appear to be
focusing mostly/solely on the rearview mirror when thinking about a
future Internet Architecture, specifically designing a solution
based around traditional fixed/wired devices that use traditional
multihoming techniques, (while potentially placing significant
amounts of complexity in the network to do so). While we certainly
can't forget about the embedded base that's out there today, it
seems false to believe that host O/S'es are completely static, nor
ever get upgraded. Finally, I would assert that we potentially are
at a crossroads where the composition of the Internet may
fundamentally be changing, as we speak, away from pre-dominantly
wired hosts to mobile, disposable devices (if it hasn't already).
It would be very unfortunate if we didn't provide a well designed,
host-based ID-Loc solution out-of-the-gate (perhaps/likely as not
the only solution, but certainly as a key part of the overall
recommended
solution) to get us on a better trajectory for scaling, not to
mention putting more intelligence in the hosts to let them
decide/control their own application's fate while at the same time
keeping the network as dumb, inexpensive and [relatively] easy to run.
Thanks for this very interesting email. I too believe that most people
see the current task while viewing backwards.re-ECN folks still believe
that congestions stem from TCP-based services and can be handled
by telling the source to slow down the transmission rate. They do not
envision video and tv to eventually millions of receivers to be /become
the true reason for congestions (BTW: Multicast popped up in the
RRG-list discussion and disappeared again :-( )
I also thought that what TARA enabled wrt mobility as an additional
benefit is such fundamental that it would overscore whichever
alternative: scoped broadcasting in search of the current xTR's
location in case of an outdated respective DNS-location data (BTW
accurate broadcasting i.e.not flooding).
Two days ago I responded to DY saying that a TARA-locator would not
identify the location of the end user device. Shane, you are also for
host-based solutions (quote from above:"it would be very unfortunate if
we didn't provide a well designed host-based ID-loc solution..."). The
end point of TARA-forwarding might be extended towards the end user
device , peu à peu: by enhancing OSPF accordingly, too.
And in case the enduser shall become part of the topology as well, then
it might take additional granularity (square milliseconds :-) plus
extra-data for enduser differentiation (to be evaluated only closest to
the destination). And "multihoming" in case TARA-locator indicated the
location of the enduser device itself? Well, then it would take
additional "via"-TARA-locators - easy as pie.
My "IETF-recommendation":
Let LISP proceed as a short-term solution.
Conceive the TARA-locator as a globally significant label ( as opposed
to locally significant MPLS-labels)
and let's do TARA as a different, and much more beneficial kind of MPLS.
A shim is needed anyway.
Heiner
------------------------------------------------------------------------
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
