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

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

|   > My point is that when the external locators are configured in
|   > a very small number of places and internal addressing is 
|   independent
|   > of external addressing, renumbering is very simple.  In 16+16,
|   > I'd propose that the external locator be only in the 
|   border router.
|   
|   I have looked, but can't find a reference to the 16+16 draft, please
|   send a pointer so I can get into the context.


You've been reading all that there is of it.  We've been poking holes
in GSE, so when Ran proposed a 16B identifier, I went with it.

So no, there is no ID yet.  I'm trying to do this the old fashioned
way: get consensus and THEN write it down.  Yes, this makes for
less argument, so this might be less fun, but it might cause us to
converge more quickly.


|   > |   Well, for the general case that one 'system' needs to 
|   > |   include the border
|   > |   router, dns, firewall, ids, partner access lists, etc...
|   > 
|   > 
|   > Hmmm...  why?  The only thing that the border router does is
|   > to add or remove the locators from the L3 header.  Access 
|   > lists should be operating on the identifier, not the locator,
|   > correct?
|   
|   Once we figure out how to verify that the indetifier is 
|   really unique.


I have problems with crypto for that level of security.  But 
shouldn't that be something like the IPSEC AH header to authenticate
the identifier?  [Like others here, I don't know anything about security
and don't claim to.]


|   > |   In fact we have an existence proof in both DNS & IEEE EUI that
|   > |   inadvertent & intentional duplication happens. So those 
|   > |   mechanisms can't
|   > |   be used as 'globally unique' identifiers as they are. If 
|   > we add some
|   > |   cryptographic properties, we can probably improve that.
|   > 
|   > 
|   > Ok, but do we need actual perfect uniqueness?  Or just 
|   'pretty close'?
|   > Operationally, 'pretty close' is a whole lot easier.
|   
|   For RFC3041 addresses, the argument is that they are 'very close' to
|   unique, but we still require backing that up with DAD to minimize
|   confusion when collisions do occur.


Ok, I have no issues for doing this for part of the 16B identifier.  
Could you deal with some high order bits being internal to site routing?


|   > |   > I submit to you that if folks are unwilling to change to an
|   > |   > architecture that scales, then IPv6 is already doomed.
|   > |   
|   > |   If the changes are contained to the routers, the timeframe 
|   > |   is reduced
|   > |   from 7 years to 3. In any case a drastic change will take 
|   > |   two years to
|   > |   get vendor shipments and another year for service providers 
|   > |   to deploy. 
|   > 
|   > 
|   > Well, if the changes are confined to the routers, then that
|   > pretty much precludes transport changes and DNS changes.
|   > 
|   > I guess we're done.
|   
|   If a 5-10 year solution is what we really need, now is the time to
|   start. At the same time, I suspect we are a couple years 
|   from an IRTF
|   result that will take a few more to work through the IETF, so the
|   dev/deployment cycle can start. While that is working its 
|   way through
|   the system though, we need to find a way to fit an expanded set of
|   multihome sites into the existing mechanisms. 


An IRTF result from whom?  The routing research group?


|   My approach has been that we draw a line between those that 
|   need to be
|   in the global table for business/policy reasons, and those that are
|   looking for local alternate service. We aggregate the latter group
|   through exchanges, and simply eat the pain of the first group. This
|   becomes a self correcting situation when financial feedback 
|   is applied
|   to the number of prefixes that get injected into the global table. 


Ok, for a temporary hack, that's a fine start.  However, we've seen 
that there is no way to get financial feedback applied to the DFZ table.
Otherwise we would have long ago in IPv4.


Tony