Subject: RE: Most recent version (of requirements doc edits) is 1.04

From: "Michel Py" <[email-masked]>
Date: Fri, 11 Jan 2002 20:12:05 -0800

> Alex Zinin wrote:
> Michel,
> Since you assumed the role of the document editor,
> could you send the latest version to the list (or is
> there a URL?) I'm lost with all the changes.

Certainly, here it is.

Multi6 folk, please note that the fact I assumed the role of
the document editor does NOT mean that three other fellows and
myself should be the only ones contributing to it.
Actually, I am strongly thinking about abusing my position of
document editor to add a new requirement that people that did
NOT contribute to the document MUST be flogged in Minneapolis.

Michel.

----------------------------------------------------------------
 Tentative summary of edits to the requirements documents v1.04
----------------------------------------------------------------

Revision history:
-----------------
1.04 Jan-10-2002 Added comments from Brian Carpenter and Michel Py.
1.03 Jan-07-2002 Added text from Masataka Ohta
1.02 Jan-05-2002 Added RJ Atkinson's comments.
1.01 Jan-03-2002 Added Eliot Lear's comments.
1.00 Jan-03-2002 Based on Christian Huitema's summary,
Michel Py's comments.

Topics:
-------
1) About 3.1.2
2) About multihoming classes
3) About DNS
4) About EIDs
5) About cooperation
6) About 3.1.3 Performance
7) About 3.2.5
8) About 4. Security Considerations

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.

Opinions about 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 am opposed to deleting the load balancing requirement, but
removing the ingress part that stirred up all this discussion
seems acceptable to me, if it does speed up the requirements
draft process (although I would vote to keep it as it is now).
Load balancing is one of the building blocks of multihoming.

Brian Carpenter:
What is clear is that no RFC (especially a requirements RFC)
will settle this. It will be settled in the real world as
IPv6 routing and load balancing practices emerge.
I suggest that we either delete the language, or make it so
vague as to avoid the argument. Deleting it seems simpler.

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. Add the following text from RJ Atkinson:
"There might be more than one multihoming approach, provided the several
approaches address different segments of the site multihoming problem."
3. Please send text.
4. Do nothing

Opinions about 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. 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.
5. Concatenate 1 and 2.
6. Concatenate 1 and 3.
7. Do nothing.

Opinions about 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. I like RJ's text.

RJ Atkinson:
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.

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

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 about it:

RJ Atkinson:
Above proposal (1) seems reasonable.

Add yours here:

6) About 3.1.3 Performance
--------------------------
> For example, suppose site E obtains transit from transit providers
> T1 and T2, and there is long-term congestion between T1 and T2. The 
> multihoming architecture MUST allow E to ensure that in normal 
> operation none of its traffic is carried over the congested 
> interconnection T1-T2.  The process by which this is achieved MAY be
> a manual one.
> Eliot Lear wrote:
> Why are we adding the caveat of the last sentence?  Manual anything
> is bad.

Possible modifications:
1. Remove last sentence
2. Please send text
3. Do nothing

Opinions about it:

Vijay Gill:
Unfortunately, while we may like to say manual anything is bad, there
always will be circumstances where some tweaking will have to be done.
There are just no getting around that fact.

Michel Py:
Although I agree with Vijay above, I think the last sentence should be
removed. Let's try to define things right, if tweaking is needed we can
close our eyes.

Add yours here:

7) About 3.2.5
--------------
> Eliot Lear Wrote:
> Section 3.2.5 also sounds either redundant or unworkable.  If what
> you mean is that you must be able to retrieve routing information from
> a router, then fine.  If what you mean is that administrators should
> be able to remotely manage and monitor end systems for purposes of 
> multihoming, that's a whole other kettle of fish.

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

Opinions about it:

Michel Py:
I'm fine with the existing text, I read it as "you must be able to
retrieve routing information from a router".

Add yours here:

8) About 4. Security Considerations
-----------------------------------
> Eliot Lear Wrote:
> This seems overly broad.  I think what you mean is the following: It 
> MUST be theoretically possible to deploy a multihomed site that is no 
> less secure than a single-homed site. Anytime a routing protocol is 
> involved there are bound to be more sensitive points of attack (like 
> DDOS, for instance).  Just like anything else, multihoming can be
> done poorly.

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

Opinions about it:

Vijay Gill:
I'm fine with this.

Michel Py:
I'm fine with the existing text.

Add yours here: