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

["Tony Li" <Tony.Li@procket.com>]

Tony,

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


That is certainly fair and welcome.


|   Yes, we are here to focus on layer 3 scaling, but we can't 
|   loose sight of the wider impact.


Please remember that my interest is the growth of the net as a whole,
not just scalability.


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


So it may surprise you to learn that I used to be a network operator
some time ago [Los Nettos, 1987-1990] and an enterprise network manager
for my company and of course my own home.  We happened to recently change
providers at my company and, because we are behind a NAT system, found
the change to be quite trivial.  Of course, we only needed to renumber the
NAT box.

In a 16+16 environment, where only the border routers are configured with
the global locators for the enterprise, renumbering amounts to reconfiguring
only one system.


|   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 can assign an identifier based purely on the administrative hierarchy.
We have an existance proof that we can do this, because we've done so 
already in DNS.


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


I submit to you that if folks are unwilling to change to an
architecture that scales, then IPv6 is already doomed.


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


That is certainly true today.  However, there is no requirement for
that.  Consider that host foo.cisco.com already has a globally 
unique and fixed hostname.  We allocated this in a hierarchical
fashion that requires no aggregation.  We simply do the same for
the identifier space.

Tony