Subject: Re: [rrg] Critique - ILNP and the other 5 core-edge elimination proposals

From: [email-masked]
Date: Wed, 6 Jan 2010 05:24:30 EST

In einer eMail vom 06.01.2010 09:11:05 Westeuropäische Normalzeit schreibt  
[email-masked]:

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 06 Jan 2010 12:22:20 +0100

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 [email-masked]:
> 
>     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).
>  
> 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.
>  
> 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
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg