Subject: additional requirement: cooperation

From: Joe Abley <[email-masked]>
Date: Mon, 12 Nov 2001 09:33:19 -0500

A multihoming strategy MAY require cooperation between a site
and its transit providers, but MUST NOT require cooperation
directly between the transit providers.

---

From: "Michel Py" <[email-masked]>
Date: Mon, 12 Nov 2001 10:21:45 -0800

>> I think your modified version is more restrictive than the original.
>> Multihoming today does not require cooperation at all between
>> transit providers in the general case (although it can be
>> necessary to achieve certain goals, e.g. load sharing between
>> providers without PI address space).

The purpose of my posting was that I think the original text has some
restrictions in the following sense:

A new multihoming solution might require a new protocol, let's call it
"xyz". The original text allows "xyz" to be configured between a site
and its transit providers, but not between transit providers. If "xyz"
needs to flow over the entire Internet, which is a reasonable scenario
for global multihoming, "xyz" would likely need to be configured between
transit providers.

>> How about:
>>  Two sites are "direct neighbours" if they are able to exchange
>>  traffic betwen their sites directly, without IP datagrams being
>>  processed by a router located at some third site.

>> That avoids the routing connotations, but accommodates traffic
>> carried over tunnels (since the encapsulated packets' IP datagrams
>> are unmolested by the routers involved in providing tunnel
transport).

You might want to be more specific, because it could be argued that IP
datagrams crossing routers providing tunnel transport are "unmolested"
but are "processed", indeed.
 
Otherwise the sentence is a lot better than mine ;-)

> "A multihoming strategy MAY require cooperation between a site
> directly between the transit providers except for direct neighbors".

---

From: "Michel Py" <[email-masked]>
Date: Mon, 12 Nov 2001 11:04:37 -0800

>> How about we leave the "except" off and revisit it if it seems really
>> necessary later on?  I worry that any protocol that requires
>> coordination between competitors is doomed to failure.  :(

Well, BGP does require some coordination between competitors and it
would be foolish to require that an IPv6 solution could do without. The
purpose of that "except" is to restrict the amount of cooperation
required between competitors to where it is really necessary, which is
when these competitors are directly connected to one another.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Mon, 12 Nov 2001 11:58:04 -0800

I will think of Multi6 as a failure if there is no solution developed
because the requirements are too specific. Let's stop dreaming and keep
in mind that the requirements' goals are to be guidelines to actual
solutions, not to wishes.

As mentioned in 3.1.5, "the current multihoming solution is quite
straightforward to deploy and maintain" which includes the necessary
peering and provider cooperation. There would be an inconsistency if the
requirements draft was to say that it is too bad to prohibit the use of
a similar solution in IPv6.

Michel.