[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On Wednesday, July 3, 2002, at 07:49 , Iljitsch van Beijnum wrote:
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 :)
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
- use policy routing based on address or protocol/port to select the
I have usually seen this deployed without policy routing to manipulate
the path of outbound traffic. Frequently the satellite channels used are
uni-directional in order to save money on (or avoid regulatory hassles
with) an uplink from the multi-homed site.
The former is workable for things like NNTP, where the traffic flow is
easily predicted and some optimization in IP addressing is well worth
The latter is a dirty hack IMO, because it breaks hop-by-hop forwarding.
When we get basic multihoming working for IPv6, there is probably a lot
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.
can do to optimize load balancing while providing differentiated
(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.
There is actually a separate (probably now expired) v4 capabilities
draft which requires content. It needs more work, but I've had zero
contributions to it; I will try to review it and propose a path forward
with it in the next week or so.