re: draft-huitema-multi6-hosts-03

["Ayyasamy, Senthilkumar \(UMKC-Student\)" <saq66@umkc.edu>]

   > 3.2 Source address selection
   > [...] 
   > Choosing the source address will affect the reverse path of the
   > connection, as the source address of the message will become the
   > destination address of the responses.


    +-- ISPA --+
S --+          +-- ISPC
    +-- ISPB --+

S is MH to A&B; A, B and C are inter-connected and engage in private peering. 
remember C is not a transit between A and B (although, it is fairly common to 
have C accidentally misconfigured as a transit.) The site S lacks a PI space.
S picks a prefix allocated by A, as it gives better performance.

In this case, A's aggregation is not broken and hence, it just announces its
prefix to both B and C. B's aggregation is broken and it announces both
its own prefix & S's prefix Sa to A&C (assuming we avoided the ingress 
filtering problem by the magic stuff mentioned in the draft.)  ISP C, on the
other hand, will choose a route to S through B and not A (due to longest
prefix match.) So, the traffic route can disagree with the AS path advertised 
by BGP. It may be due to routine removal of routing information at ISP level 
in the name of aggregation, filtering and local policy setting. hence, it is 
not possible to predict the reverse path based on the source address (unless, 
if we depend on an external measurement system.)

As for dest address selection, trying every other prefix is the only current
option. Alternatively, one can think in terms of router level feedback to
end systems about path coditions ( sally floyd's Quickstart proposal can be 
easily extended to support such a feature.) But, I presume, we don't have 
enough machinery to predict path reliability at router level.

If we observe closely, it is hard to do address selection at user level
(although, it has more incentive.) else, an external measurement system (in
the form of overlay) can routinely measure the Internet space and can provide
path reliability details. but, it is still hard due to provider centric 
routing policy control. So, how about this? Lets relegate the address 
selection problem to providers and just work on multi addressing at transport
level ( for it can act as a hint to provider based selection.) It will also
allow a limited form of user control.