For example, suppose the pure aggregation/no hole-punching addressing
and route advertisement scheme is strictly adhered to, and the effect
of multi-homing is to number each interface with an address from each
transit provider. Further suppose that the TCP endpoint address
selection algorithm can be influenced by some hierarchical policy
signalling mechanism. In that case, inbound traffic towards a TCP
endpoint could be moved between transit providers without resorting
to CIDR abuse.
You still need either:
- BOTH ends to have their IP address for this application in a separate
range, or
This happens by virtue of the fact that each transit provider delegates
a block of space to the multi-homed site. If the site is single-homed,
it only has one transit provider, and hence only one IP address. The
fictional address selection criteria might apply to both ends of the
session. Yes, there are big holes in this approach :)When we get basic multihoming working for IPv6, there is probably a lot
we
can do to optimize load balancing while providing differentiated
services
(and/or the other way around).
More generally, you seem to be saying that the requirement as stated
reduces to something trivial, which of course should be supported by
any adequate multihoming architecture. If I have got that right, then
what's the harm in letting the requirement stand in the document?
There is not much harm. Still, my original point remains: the wording
could lead to confusion about current IPv4 capabilities.
I will look at the words. The requirement I was trying to describe is
most certainly met by the current v4 regime; it's a description of an
approach which is already in widespread use.