RE: Identification, layering, transactions and universal connectivity

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

|    I don't think that's good enough. Today having multiple 
|    addresses from 
|    different ISPs doesn't work if the ISP does ingress 
|    filtering. To solve 
|    this, we need to be able to change addresses for existing 
|    sessions, and 
|    we need to figure out the right source address reasonably 
|    fast. But we 
|    also need to figure out the right destination address 
|    pretty quickly or 
|    publishing addresses that may not be reachable (for 
|    everyone) becomes 
|    too expensive. This is an integral part of the multihoming 
|    package so 
|    we must deliver on it.


Good point.  I consider that to be a different problem, however:
insuring that the packet departs via the ISP matching the source
locator.  We'd really like routing to choose the right ISP once
the host has chosen its source locator.  Unfortunately, we don't
have a great deal of control.  Most enterprises simply have an
internal default that points 'thataway' and may or may not fail
over when an SBR or its link fails.

[Aside: solving this with the 'little' proposal was actually
a bit easier.  The SBR simply changed the locator to match the
ISP as the packet exited.]

A simple approach here would be to give the host a 'hint' as to
the source locator preference.  These hints would be set up so
that they match the most common state of routing, but would
allow a host to rotate amongst its locators.

For the destination locator, I see only one tractable solution.
Since we're already doing a lookup to get the locators, we could
also publish a 'hint' about the order that the source should
try destination locators.  By analogy, look what we do for
preferences of mail servers in MX records.  

Will this suffice?

Tony