[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(multi6) Requirements document last call / edit v1.01
----------------------------------------------------------------
Tentative summary of edits to the requirements documents v1.01
----------------------------------------------------------------
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. 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 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 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. Please send text
4. 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.
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.
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:
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 this, 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 this.
Add yours here: