Re: [RRG] Long term clean-slate only for the RRG?

[David Conrad <drc@virtualized.org>]

Yakov,

On Jun 27, 2008, at 2:25 PM, Yakov Rekhter wrote:
> (a) what are the benefits of separating location and identity,


To state the obvious, by divorcing the identity from the location, you  
allow that identity to "easily" change location.  Conceptually, the  
benefits of such a split would include:

- end users/sites having multiple providers (multihoming) without  
having to participate in the locator routing system
- end users/sites changing from one provider to another over a long  
time period (i.e., changing ISPs)
- end users/sites changing from one provider to another over short  
time periods (i.e., mobility, depending on how the mapping is performed)
- ISPs being able to rearrange network topology without significantly  
impacting network users
- ISPs being able to migrate to IPngng without significantly impacting  
network users
- removing the need for end users/sites to renumber (ever again)
- reducing or removing the need to assign end user/sites address space  
in a hierarchical manner
- avoiding the need of ISPs and end users/sites to deal with  
potentially multiple layers of NAT

There are probably other benefits I'm forgetting right now.

> (b) who is going to benefit and who is going to bear the cost (both  
> in the short and in the

> long term),

Both end users/sites and ISPs would benefit (see above).

There are multiple costs that would need to be born, varying depending  
on implementation.  In general, there would be the capital cost of the  
deployment of ITR/ETR devices or redeployment of network stacks.   
There would also be the cost of implementing, managing, and  
distributing the locator/identifier mappings, potentially including  
the cost of the mapping device(s).  In non-capital costs, depending on  
how the mapping was implemented, you would have either increased  
latency for at least the first packet in a new transaction (in a  
"pull" model) or increased traffic and memory requirements (in a  
"push" model).

There are probably other costs I'm forgetting right now.

> (c) could one benefit with only a partial deployment,

I suppose it depends on what you mean by partial deployment.  One can  
imagine scenarios where you have incremental deployment amongst  
cooperating ISPs, but one of the hardest problems to solve is how you  
have asymmetrical deployment (that is, where an end/user site has  
migrated to the new system and wants to communicate with an end/user  
site that hasn't yet migrated).  Obviously, NAT deals with the  
asymmetrical deployment problem, but brings with it its own costs.

> etc...


While I agree that a cost/benefit analysis needs to be done, I think  
it worthwhile to keep in mind the alternatives.  The alternatives (as  
far as I am aware) are:

a) PI for everyone
b) NAT

I hope you'll agree that alternative (a) alone is not scalable in the  
long term.  One can imagine a scenario where you have a universe of  
NATs connected via PA assigned end points, however I'd argue this is  
actually a locator/ID split where the IDs are not globally unique.

Am I missing an alternative?

Regards,
-drc


--
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