RE: [RRG] some musings on PI v. PA, and assumptions, requirements, and tradeoffs

["Medhi, Deep" <DMedhi@umkc.edu>]

> 
> > Haven't we been round this particular mulberry bush a few times  
> > already?   Yes, the routing system offers the path of least  
> > resistance when attempting to solve a number of issues, and thats 
> > because routing solutions are invariable simple and (today) cheap.
> > And the Loc/ID split seems to be a pretty massive solution for 
> > something that does not appear to be a commonly accepted problem in 
> > the first place. So yes, we continue to use the routing system for 
> > multi-homing, traffic engineering and similar. It just works.
> 
> To connect to stationary hosts yes. But if they are moving 
> around and keep their addresses regardless if those addresses 
> are from PI or PA space, then location needs to be 
> topological. Furthermore, moving around a lot and injecting 
> and withdrawing more specifics is just going to add churn in 
> a major way.
> 
> > The only concern I've heard voiced that seems to me to be a 
> real issue 
> > in all this is the question "what if we all did that?" Are there 
> > numbers for "we all" that appear to be beyond the capability of the 
> > technology curve? Are there numbers for "we all" that might even be 
> > beyond the capability of the protocol? If so, then we probably need 
> > some
> 
> All valid questions with no magic answers. But if we are 
> concerned with churn and convergence of control-plane tables 
> into forward-plane tables and looking at 10^6 sites plus the 
> mobility aspect, the numbers are getting large. But this is 
> not scientific but just gut feel.
> 
> > kind of plan B, and it does appear to me that if you want 
> to get out 
> > of the tyranny of incrementalism then you need to consider 
> something a 
> > little more fundamental in terms of network architectures when you 
> > start to look at what would make a Plan B effective. For me 
> this path 
> > is where the split loc/ID approaches start to gain 
> traction. But to be 
> > clear, the split loc/ID approach does not appear to me to 
> be a viable 
> > tactical response to routing inflation in the near term future.
> 
> As I have said before Geoff, solving the routing table size 
> problem is just a side benefit if we first solve the 
> "non-search-site"  
> multihoming problem. That is to allow them to use both of 
> their links (I believe you said that 80% of all multi-homed 
> sites have exactly 2
> connections) and to be able to tell hosts returning packets 
> to them which link to use and how to failover.
> 
> A level of indirection can solve this but the big question is 
> it too much of a solution. That is, do we have the guts to 
> just brute-force and continue to send in PI prefixes.
> 


The above exchange between Geoff and Dino is quite interesting. 

Loc/ID split is an important issue; but, somehow it seems to get grayed
regarding "end" for real end users or PI independent address blocks
(thanks to Lixia, for her nice presentation clarifying the Terminology,
HIP research meeting, March 23, 2007).

I don't believe real end users mostly care what their IP address is
(except, perhaps us 'net-geeks). If they get their service they are
fine. Note that to make TCP-based service work, the end system requires
an IP address (i.e. layer-4 "port" address relates to layer-3
address)--mosty this is accomplished through the end system
implemenation stack. The real question is: should this end IP address
come from the same globally defined addressing mechanism, or should this
end IP address be 'elevated' to make TCP and end services still work,
while a separate addressing is used for the global routing system; for
the time being, I'll call the former "layer-3.5 IP address" for the
purpose of end system service, while I'll call the latter "layer-3 IP
address" for the purpose of global routing system. Whether these two
addressing may look the same or different is something interesting to
think about. 

As a different case, I'll draw the example of local number portability
(LNP), as well as cell phones. Users get their E.164 address (the
telephone number), they can keep it, yet change providers; they are
happy. Although E.164 addressing has its origin in geographic routing,
there has been a clear separation between E.164 for the purpose of
service and how the routing work in PSTN. Partly it was possible to do
so because in the very first place, the end telephone numbering and
nodes numbering (switches) in PSTN didn't come from the same address
space. 

Now when it comes to cell phones, we already know that providers with
newer generation wireless systems assign IP addresses, which may or may
not be locked into the E.164 address. What matters to the end user is
still E.164 address (it's not what is the IP address of the device);
they are happy to get their TV show clips, music download etc etc, and
certainly happy to have a globally unique identifier in the form of
E.164 address so that they can receive/make calls. It doesn't matter to
them if the IP address is different when they are physically in a
different location. Rather, it's the headache of the provider to do such
IP address assignment (which might be different, depending on the
current location); i.e., the provider-independence issue doesn't arise
in this scenario.

Thus, the critical question is: are we willing to have an IP address for
the purpose of the end system service (layer-3.5 address), and another
address for the purpose of routing system (layer-3). If we do so, we'll
need a lookup function much like DNS (perhaps more closer to ARP?),
between layer-3.5 and layer-3 addresses (a level of indirection); this
will then avoid breaking the current global routing system, and in fact,
might allow it to evolve in its own course; similarly, the end system
(and implementation) can evolve separately as well without breaking it.

Whether this is good or bad, remains to be seen and understood. At the
end of the day, this is as much a philosophical question as it is a
system scalability question with potential economic implications. I'll
be the first one to admit that I don't have the far reaching answers.
At this point I'm just pondering the possible issues and implications...


    Thanks.


       -- Deep
          http://www.csee.umkc.edu/~dmedhi

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg