[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Requirements document edit 1.05
----------------------------------------------------------------
Tentative summary of edits to the requirements documents v1.05
----------------------------------------------------------------
Revision history:
-----------------
1.05 Jan-21-2002 Added comments and text from Rob Rockell
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
9) comment on 3.2.2, and 3.2.3
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.
#2 (after (4) was proposed): (4) above is a good compromise.
Rob Rockell:
Whether a site policy matter or not, the ability to load-balance must be
retained, bi-directionally... Granted, this is tricky with global
aggregation of ones prefixes, but it seems obvious that this requirement
MUST stay. I vote to keep it as is. I like the verbage as is.
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".
Rob Rockell:
Multiple Solutions=ok. Just a management nightmare for IESG and our
Chairs. Add verbage to draft to this effect, with MAY. However,
something to the effect of "adopted solution SHOULD attempt to cover as
many multi-homing scenarios as possible" (prettied up for RFC, of
course, but you get the point).
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.
Rob Rockell:
In full concurence of RJA's proposed Text add (#3 above).
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.
Rob Rockell: Agreed with Py and Atkinson.
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.
Rob Rockell: I am ok with Either. Proposal (1) above seems to keep
things as flexible as possible.
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.
Rob Rockell:
Agree with Michel here.
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".
Rob Rockell:
I would be more explicit here. If the requirement is to retain the
ability to extract routing information from the router, then explicitly
say that.
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
3. Replace with the following text inspired by Rob Rockell
"An IPv6 multihomed site MUST NOT be more vulnerable to security
breaches and security problems than a traditionaly IPv4 multi-homed
site".
Opinions about it:
Vijay Gill:
I'm fine with this.
Michel Py:
I'm fine with the existing text.
#2 (after Rob's contribution): Favors (3) above.
Rob Rockell:
The addition of dynamic routing protocols (like BGP in today's IPv4
world) makes ALL multi-homed sites more susceptible to DOS or security
problems than singly-homed sites (think about faking BGP packets).
Might be nice to make this more explicitly stated that the topology and
the mechanism MUST NOT make the multi-homed site more vulnerable to
security problems than a traditionaly IPv4 multi-homed site....
Add yours here:
9. Comment on 3.2.2 and 3.2.3.
------------------------------
> Rob Rockell wrote:
> The concept of "minor" change is too qualitative for IETF... Something
> along the lines of RJA's comments about "any major structural change
> to router implementation or host stack MUST have convincing rationale
> to justify it, and SHOULD be implemented as separate functions added
> to the existing functions" Not sure of this text, but some bounds
> should be put on the requirement, while allowing the possibility to
> exist for something radical. We don't want to hold back the right
> solution because people are lazy to rebuild implementations.. :)
Possible modifications:
1. Please send text
2. Do nothing
Opinions about it:
Add yours here: