[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: PI/metro/geo [Re: The state of IPv6 multihoming development]




Tony,

|   > Instead, I want to help all parties by growing the net in a 
|   > reasonable and scalable way.  That should be what we're all 
|   > trying to do here.
|   
|   I believe it is, I was just asking if we have the appropriate
|   representation to make a balanced choice when the hard 
|   trade-offs start being made.


I appreciate that you're trying to do this as fairly as possible,
but technical decisions should not be made by a democratic 
process.  Yes, we all need to understand the issues that our
users will face, but for those users to in turn understand the
details of inter-domain routing is asking a bit much, don't you
think?


|   > Operational issues instead 
|   > favor a haphazard, need driven, cost optimized topology.  
|   > Yes, ok it's chaotic, but it's the result of capitalism 
|   at its finest.
|   
|   It is the 'cost optimized' part that makes the difference. 
|   Which pockets
|   are we talking about protecting? I am not saying we should favor any
|   particular pocket, just asking if we are doing it 
|   unintentionally by the
|   representatives around the table.


Ultimately, it is always going to come down to the end user.  The
ISP, as a business, is always going to pass costs along to the 
end user.  If we raise ISP link costs to minimize renumbering
costs, the end user will pay for those links.  If we minimize
link costs and force people to renumber, then the end user pays
directly and in proportion to their address space utilization.

Note that under the 16+16 proposal, you get the situation where
renumbering is cheap and easy AND the link costs are minimized.


|   > Provider independence isn't necessarily helped only by PI 
|   > space. There are other ways.  The real point is to avoid the 
|   > pain and anguish of renumbering. 
|   
|   That is one reason; simply being in control of your own destiny is
|   another. 


Specifically what are you referring to?  I am not in control of
my phone number.  If the area code splits, mine changes without
my control.  The freeways that I drive on go where some traffic 
engineer says that they should go, not where I want.  The end
user is going to have a prefix that reflects their topology,
even in the single homed case.  If we can do the renumbering
only at the border and reduce renumbering costs that way, does
the end user still care what his prefix is?


|   This argument is continually shot at using the multi-prefix 
|   model as not
|   workable because there are too many static tables inside enterprises
|   that 'need' to carry the real address for access control. I am not
|   arguing it is valid or correct, just that the viewpoint exists.


I'm glad that you're not agreeing.  I'd argue that if you wanted
to do access control, you care about the identifier, not the locator.


|   > You are also assuming that aggregation and multihoming 
|   are somehow 
|   > at odds.  They are not.  All you have to do is to disconnect 
|   > the locator and the identifier as GSE does and aggregate only the 
|   > locators.  Each host in a multihomed domain has a single 
|   > identifier, but multiple locators.  No deaggregation happens 
|   > because the locators are bound to the provider and thus we 
|   > have good topological 'addressing'.  The enterprise doesn't 
|   > lose because we tweak the transport to base the pseudoheader 
|   > on the host identifier and then let the locator be free to be 
|   > replaced by border routers.  Connections flip back and forth 
|   > between locators easily.
|   
|   This model was probably possible 4 years ago, but at this 
|   point I doubt
|   tweaking the pseudoheader can even be on the table. 


Why?


|   Also, 'freely
|   replaced' usually sets off the alarm bells of the spoof-sensitive
|   security types. 


If that was the entire address, I would agree.  However, as long as
the identifier is stable, I don't see their point.

Tony