FW: Mail delivery failed: returning message to sender

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

Retransmitting due to mail bounce... apologies if it's a 
duplicate.

|    Erik,
|    
|    |    To me this is a no brainer because I can't see how there
|    |    can exist a scalable approach to multihoming that doesn't
|    |    separate identifiers and locators.
|    
|    
|    Excellent, welcome to the club.
|    
|       =20
|    |    At some level one could argue that host multi-addressing=20
|    |    is scalable
|    |    (at the expense of moving complexity to the hosts and=20
|    |    applications).but
|    |    my concern is that host multi-addressing will more or 
|    less have
|    |    the hosts track with source/destination combinations=20
|    |    (which approximate
|    |    routing paths at some rough level) work vs. doesn't.
|    
|    
|    Yes, that's going to happen.
|    
|    
|    |    To get fast failover this essentially turns into doing=20
|    |    end-to-end "hello"
|    |    traffic instead of relying on the local hello traffic=20
|    |    performed by the routing
|    |    protocols. So I think there are severe limitations in=20
|    |    making this scale.
|    |    (And trying to aggregate this end-to-end "hello" 
|    traffic will just
|    |    cause a reinvention of routing.)
|    
|    
|    As Iljitsch seemed to hint at, there is no need to add protocol to
|    do this.  For example, a TCP implementation can simply watch the
|    RTT, compare it to the sRTT and consider switching locators anytime
|    it needs to retransmit.
|    
|    I don't know of a requirement that asks us to react faster 
|    than that
|    timeframe, just that we not drop TCP connections.  So why not use
|    what's there?
|    
|    Tony
|