Re: draft-ietf-multi6-multihoming-requirements-03

[Joe Abley <jabley@automagic.org>]

On Monday, July 1, 2002, at 05:40 , Iljitsch van Beijnum wrote:

> Then there is:
>
> 3.1.4 Policy
>
>    A customer may choose to multihome for a variety of policy reasons
>    beyond technical scope (e.g.  cost, acceptable use conditions, etc.)
>    For example, customer C homed to ISP A may wish to shift traffic of a
>    certain class or application, NNTP, for example, to ISP B as matter
>    of policy.  A new IPv6 multihoming proposal MUST provide support for
>    site-multihoming for external policy reasons.
>
> I don't think this is the intention, but it _can_ be read as if IPv4
> multihoming has the capability to direct traffic for certain 
> applications
> over one link and traffic for other applications over another link. 
> Since
> this is certainly not the case, at least the example should go, possibly
> the whole thing. (Does it require anything useful anyway?)
The example I have used for this before concerns people who operate 
networks in places where satellite communications are substantially 
cheaper than terrestrial communications (this is most of the planet, by 
area).

It is common practice to number news, mail, and HTTP proxy servers 
(tuned for retrieval of objects over satellite-like latencies) within 
subnets which can be advertised such that inbound traffic from the rest 
of the world arrives on those servers via a satellite link, whereas all 
other traffic (including traffic directly aimed at subscriber addresses) 
arrives via terrestrial fibre.

This crude approach takes the traffic load of asynchronous, 
latency-tolerant services off the expensive terrestrial fibre, and 
leaves it (the fibre) for use by more interactive, latency-intolerant 
traffic. Costs are reduced, performance for customers remains acceptable.

Often, satellite bandwidth is bundled by satellite operators with 
transit. ISPs who buy such satellite transit are very unlikely to use 
the satellite provider for their terrestrial transit. Being multi-homed 
in this fashion is common practice today in many parts of the world.

I agree that existing IPv4 multihoming practices/CIDR abuse do not 
inherently provide mechanisms for making routing decisions based on 
criteria encapsulated *within* IP. However, changing the requirements to 
specify something else (like segregation of different parts of an 
address space over different transit circuits) seems to me a bit too 
much like presupposing a solution.

I think the basic requirement should stay. I am not married to the words 
currently in 3.1.4, however, so if you have better ones I'd be glad to 
hear them.


Joe