RE: please indicate whether you are content with the proposed editsw/1.09

[Iljitsch van Beijnum <iljitsch@muada.com>]

I just read 3 months worth of email on this list...

Is draft-ietf-multi6-multihoming-requirements-02.txt the most recent text?

On Thu, 7 Feb 2002, Michel Py wrote:

> 1) About 3.1.2
> --------------
> > Christian Huitema wrote:
> > Tony Hain sent several detailed comments, one of which generated a
> > strong debate, i.e. his objection to a part of section 3.1.2 that
> > stated that "a site MUST be able to distribute ... outbound traffic
> > between multiple transit providers," arguing that this was a site
> > policy matter.

> Possible modifications:
> 1. Leave 3.1.2 as-is.
> 2. Suppress 3.1.2.
> 3. Replace with following text from Masataka Ohta
> "A proposal MAY allow site weakly control inbound traffic but it
> MUST NOT increase the amount of global routing/signalling
> information traffic."
> 4. replace "both inbound and outbound" with "outbound".
> 5. Please send text.

A situation where the receiving site has absolutely no say over which
interface traffic comes in over wouldn't be acceptable: a slow backup
connection may receive all the traffic. Performance would be worse with
than without the backup. I'd change it to:

By multihoming, a site MUST be able to distribute both inbound and
outbound traffic between multiple transit providers, such that the
majority of traffic flows over the desired transit provider. More
fine-grained control SHOULD be available. This requirement is for
concurrent use of the multiple transit providers, not just the usage of
one provider over one interval of time and another provider over a
different interval.


> 2) About multihoming classes
> ----------------------------
> > Christian Huitema wrote:
> > I pointed out that different classes of solutions have different
> > scaling properties, which implies that the solution for multi-homing
> > my home network to cable and DSL may not be the same as the solution
> > for multi-homing Microsoft's network.

[...]

> Add yours here:

Obviously, Microsoft can afford to multihome, whatever we do. Any solution
that doesn't allow at least a million multihomers with current hardware
and linear growth after that isn't good enough, and more multihomers now
coupled with less growth in hardware requirements is better.

> 3) About DNS
> ------------
> > Christian Huitema wrote:
> > The discussion on renumbering and EID pointed out the need to add a
> > requirement that "the solution shall not depend on instant updating of
> > the domain name system", or if you prefer that "the solution should be
> > compatible with the observed dynamics of the current DNS system."

> Possible modifications:
> 1. Add the following requirement from Brian Carpenter:
> "The solutions must include an analysis of their effects, if any, on
> DNS updates, including consideration of load for the global updating of
> the DNS, and interactions with DNS TTL and caching".

> 2. Add the following requirement from Christian Huitema:
> "The solution should be compatible with the observed dynamics of the
> current DNS system".

> 3. Add the following requirement from RJ Atkinson:
> "The multihoming approach should be compatible with the current DNS
> system and technology xor the proposed approach needs to have convincing
> rationale on why a modified name resolution system to support that
> approach is readily deployable".

> 4. Please send text.

"The solution SHALL NOT depend on dynamic DNS updates."

I see no harm in using the DNS to find out static information which may be
required at the beginning of a session, but the DNS must be able to cache,
otherwise the system will break down.

> 4) About EIDs
> -------------
> > Christian Huitema wrote:
> > 4) Naïve implementations of EID and MIPv6 tend to introduce a
> > dependency on a name server or a home agent, i.e. another point of
> > failure. If people want to pursue this path, we should make sure
> > they do it the smart way, i.e. do not introduce a dependency on
> > another system beside the site-exit router and the multiple providers.
> > That may be worth spelling out in a requirement.

> Possible modifications:
> 1. Please send text
> 2. Do nothing

> Opinions about it:

> Michel Py:
> I think I will take the words out of Brian Carpenter's mouth here and
> say that there is no reason to specifically forbid it in the
> requirements draft. Let's not close doors we might need later.

> RJ Atkinson:
> Concur that there is no reason to add Christian's proposed text, because
> it closes options off prematurely.

> Rob Rockell: Agreed with Py and Atkinson.

> Add yours here:

Good point. Still, we don't want SINGLE points of failure. So if any
dependency should be necessary, it must relate to something that is very
robust in its own right (without depending on multihoming), such as the
DNS system.

> "IPv6 multihoming solutions MUST NOT preclude filtering out packets with
> obviously forged Source IP Address values at the administrative boundary
> of the multi-homed site. The details of how such filtering is implemented
> MAY vary depending on the IPv6 multihoming solution, provided there is
> some mechanism for performing such filtering that works with the
> multihoming solution proposed."

We shouldn't refer to the RPF check since that one doesn't always work
(asymmetric routing).

A side note: it occurs to me when a user holds an IP address, he has the
"right" to use it, even over a connection which wouldn't normally be
associated with this IP address. But we need filtering to prevent address
spoofing. The solution could be a protocol the user could use to show ISP
B he got ISP A's address legitemately so he can use it as the source
address for packets going out over B.

Shouldn't we say a bit more about mobility? It pretty much solves a lot of
the problems we need to solve for a host-based solution, but it can't work
around failures to the degree we need.

And how about this:

"If there is any processing associated with being multihomed or
interacting with multihomed hosts, it SHOULD be possible to offload this
processing to one or more proxy devices in such a manner a current IPv6
implementation can be multihomed and/or interact with multihomed hosts
with full multihoming benefits. If several proxy devices are used, failure
of a single device MUST NOT terminate ongoing communication."

Iljitsch van Beijnum