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

From: "Tony Li" <[email-masked]>
Date: Fri, 1 Nov 2002 14:37:56 -0800

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

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 1 Nov 2002 16:00:57 -0800

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

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

> 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

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

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

> |   tweaking the pseudoheader can even be on the table. 

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.

> 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

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 4 Nov 2002 14:34:53 -0500

> stable, the static description is not stable.

Current identifiers are not globally unique either.  www.<foo>.com
where it is implemented as a set of servers behind a load balancer
is a trivial counter-example.

So I submit that we don't need "globally unique" identifiers".  We do 
need
"probabilistically unique" identifiers with a sufficiently high (<< 1) 
probability.

This is an *important* point.

Ran

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 6 Nov 2002 06:46:58 +0859 ()

Ran;

> is a trivial counter-example.

The point of the load balancer is that, viewed from the other end
of the communication, the entity corresponding to www.<foo>.com
behaves as if it is globally unique, 100% of the time.

A single entity consistently maintains TCP/HTTP state that the other
end assumes that the ID is globally unique.

> "probabilistically unique" identifiers with a sufficiently high (<< 1) 

It is not a probability issue.

							Masataka Ohta

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 5 Nov 2002 17:04:26 -0500

> behaves as if it is globally unique, 100% of the time.

But many of them do NOT behave that way...

> end assumes that the ID is globally unique.

Not true of a lot of such systems deployed today.

Ran

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 6 Nov 2002 07:55:50 +0859 ()

> Not true of a lot of such systems deployed today.

For example?

						Masataka Ohta