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
