(multi6) Requirement document last call /edit (let's focus!)

["Michel Py" <michel@arneill-py.sacramento.ca.us>]

multi6 folk,

I tried to summarize below the possible changes to the requirements
document, based on Christian's last postingl hoping that I do not
step on the authors' toes.
PLEASE DO send changes/comments/opinions.

>> Sean Doran wrote:
>> Remember that this WG is charterd to solve SITE multihoming,
>> rather than host multihoming.   If the former, which implies
>> simultaneous connectivity and/or migration for a collection of
>> hosts from a few to a vast number, can be done using the mechanisms
>> of the latter (e.g. multi-addressed hosts, MIP6), that's fine and
>> dandy.  However, first, the charter documents need to be pushed
>> along the standards track, as discussed in SLC.


> Christian Huitema wrote:
> Seconded!
> Let's first achieve the goal of the current charter, which is to
> publish the requirement document. And let's not try to tailor the
> requirement to a specific solution: this is the known way to not
> make progress.

Agreed!

> Could someone summarize the actual modifications to the requirement
> document that surfaced during this last call?

I will try to do that below, and you just summarized the
discussion about it, for the most part.

> Do you agree that this is a fair summary of the discussion on the
> requirements draft? I yes, we should maybe have a short editing pass,
> and then proceed towards publication of the requirements and
> rechartering of this group.

Agreed.

There is something else we have to deal with in the current charter:
"Produce a document describing how multihoming is done today, including an explanation of both the advantages and limitations of the approaches".

I do not intend to send a blow to the authors in any way, but does anybody
really care about it? I wonder how the chairs and the WG would feel about
taking that one out as part of the re-chartering. It never seemed to trigger
much interest. In SLC there was not even a handful of people that raised
their hand when asked if they have read it.

Michel.


-------------------------------------------------------------
  Tentative summary of edits to the requirements documents:
-------------------------------------------------------------


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. Please send text

Opinions on it:

Christian Huitema:
I personally don't agree with Tony, and believe the solution must
enable the site to balance traffic, and must also enable the site
to not do so if it chooses.

Michel Py:
I don't think 3.1.2 should be changed.

Add yours here:



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.

Possible modifications:
1. Reference in new charter
2. Please send text.
3. Do nothing

Opinions on it:

Christian Huitema:
Don't know whether that should be part of the requirement document.

Michel Py:
I think this should be part of the new charter rather than the
requirements documents. The new charter could say something like:
"Since it is unlikely that a proposal will cover all possible IPv6
multihomed sites, the working group will consider solutions targeted
at a certain class of sites, and foster interoperability between the
different proposed solutions".

Add yours here:



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. Please send text
4. Do nothing

Opinions on it:

Brian Carpenter:
I think we have a missing requirement:
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.

Michel Py:
I am not sure that I would go as far as Christian does. Although I do
agree that each solution MUST clearly document the impact on DNS, and
I also think as he does that the solution should be compatible with DNS
as we know it today, I do not think that we should block future
developments based on a new breed of DNS.

Add yours here:



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 on 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.

Add yours here:



5. About cooperation
--------------------
> Michel Py proposes to change 3.2.6 Cooperation between Transit Providers

Possible modifications:
1. change 3.2.6 from:
A multihoming strategy MAY require cooperation between a
site and its transit providers, but MUST NOT require
cooperation directly between the transit providers.
to:
  A multihoming strategy MAY require cooperation between a
| site and its transit providers, but MUST NOT require SITE-SPECIFIC
  cooperation directly between the transit providers.
Inspired by Pekka Savola's definition of cooperation.
2. Please send text
3. Do nothing.

Opinions on it:

Add yours here: