Re: (multi6) Requirement document last edit

[RJ Atkinson <rja@inet.org>]

At 14:36 03/01/02, Michel Py wrote:
>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".

Option 2)  Proposed additional text:
          "There might be more than one multihoming approach,
          provided the several approaches address different
          segments of the site multihoming problem."
          (edit to taste)


>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

Option 3)
        "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."
        (edit to taste)

The underlying issue really is not whether an approach compatible 
with the current DNS.  The real issue is deployability.  Something 
compatible with the current DNS (including DNS Dynamic Update, 
which is current technology) is more easily believed to be deployable.
Something incompatible needs to have a convincing argument that the
DNS-incompatible approach could realistically be built and deployed.

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

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

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

Above proposal (1) seems reasonable.


Ran
rja@inet.org