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

["Tony Hain" <alh-ietf@tndh.net>]

Tony Li wrote:
> 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.  

The IETF consensus process != democratic, and rarely comes close. The
point was more to make sure there is someone that can give a first-hand
defense of the requirements so they are not easily dismissed by those
with other priorities.

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

I don't expect them to understand inter-domain routing details any more
than I expect inter-domain routing experts to understand the business &
policy decisions that result in the unrealistic topologies. 

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

There are additional costs to the renumbering plans like, increased
difficulty in diagnosing problem reports, increased effort for
applications to deal with dynamic locators, churn in name resolution, or
the edge mapping systems that restore the dns values, etc ... 

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

Just keep in mind we are squeezing on a balloon here, and if one aspect
is minimized, another has just been expanded, and frequently
disproportionately so. A group that is intensely focused on inter-domain
routing is unlikely to appreciate the ramifications on the application
development community, or those who have to operate at layer 8 or 9.
Yes, we are here to focus on layer 3 scaling, but we can't loose sight
of the wider impact.

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

You are if you subscribe to a vanity 800 number; and since those are
portable the system appears to flat route underneath you. 

> The freeways that I drive on go where some traffic 
> engineer says that they should go, not where I want.  

If the traffic engineer has done his job though, they go where the
majority of your neighbors have shown they want to go. If not,
congestion will persist alongside an empty freeway. 

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

That question deserves a firsthand answer from a current enterprise
network manager. 

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

But since there is no way to ensure that an identifier is globally
unique, the only way to accomplish the goal is to couple them to
describe 'this identifier at this location'. If the location is not
stable, the static description is not stable. 

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

Shipped code is hard to change. For something as significant as this, it
takes two years from the point of agreement to get new code shipped,
then it takes an additional 3-7 years to get the prior code retired. We
will need a multi-homing solution well before that, so we need to find
something that is incremental.

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

Because the identifier is not stable & globally unique, and even if we
had a way to ensure that, the privacy advocate's alarms would be going
off. Despite the desire to avoid it, the current reality is that to
create a globally unique identifier we bound the problem by coupling it
with its locator.

Tony

> 
> Tony
>