[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: please indicate whether you are content with the proposed edits w/1.09
Would something like the table below help?
If you think so, please check/send your vote (I voted for a few
of you based on your comments).
----------------------------------------------------------------
Tentative summary of edits to the requirements documents v1.09
----------------------------------------------------------------
+----------------------------------------+
! Topic !
+---+---+---+---+---+---+---+---+---+----+
! 1 ! 2 ! 3 ! 4 ! 5 ! 6 ! 7 ! 8 ! 9 ! 10 !
+-------------------+---+---+---+---+---+---+---+---+---+----+
! Christian Huitema ! 4 ! 5 ! 3 ! 2 ! 1 ! ! ! ! ! !
+-------------------+---+---+---+---+---+---+---+---+---+----+
! Michel Py ! 1 ! 5 ! 6 ! 2 ! 1 ! 1 ! ! ! 2 ! 4 !
+-------------------+---+---+---+---+---+---+---+---+---+----+
! Rob Rockell ! 1 ! 5 ! 3 ! 2 ! ! 1 ! ! ! ! !
+-------------------+---+---+---+---+---+---+---+---+---+----+
! RJ Atkinson ! ! ! 3 ! 2 ! 1 ! ! ! ! ! !
+-------------------+---+---+---+---+---+---+---+---+---+----+
! Tony Hain ! 4 ! ! ! ! ! ! ! ! ! !
+-------------------+---+---+---+---+---+---+---+---+---+----+
! Eliot Lear ! ! ! ! ! ! ! ! ! ! 4 !
+-------------------+---+---+---+---+---+---+---+---+---+----+
! Brian Carpenter ! 4 ! ! ! ! ! ! ! ! ! !
+-------------------+---+---+---+---+---+---+---+---+---+----+
! Vijay Gill ! ! ! ! ! ! 3 ! ! ! ! !
+-------------------+---+---+---+---+---+---+---+---+---+----+
! ! ! ! ! ! ! ! ! ! ! !
+-------------------+---+---+---+---+---+---+---+---+---+----+
! ! ! ! ! ! ! ! ! ! ! !
+-------------------+---+---+---+---+---+---+---+---+---+----+
! ! ! ! ! ! ! ! ! ! ! !
+-------------------+---+---+---+---+---+---+---+---+---+----+
! ! ! ! ! ! ! ! ! ! ! !
+-------------------+---+---+---+---+---+---+---+---+---+----+
! Gathered 5 votes ! ! ! ! ! ! ! ! ! ! !
+-------------------+---+---+---+---+---+---+---+---+---+----+
Revision history:
-----------------
1.09 Feb-07-2002 Added 5. in Topic 1.
1.08 Jan-30-2002 Added Eliot Lear's comments for topic 10.
1.07 Jan-29-2002 Replaced topic 10 text with RJ Atkinson's text.
1.06 Jan-29-2002 Added new requirement (RPF).
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
10) Reverse Path Forwarding / filtering
11) Time to go to last call
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
5. Add the following text combined from RJ Atkison and Rob Rockell:
"There might be more than one multihoming approach, provided the several
approaches address different segments of the site multihoming problem.
adopted solutions SHOULD attempt to cover as many multi-homing scenarios
as possible".
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:
10. Reverse Path Forwarding / filtering
---------------------------------------
> Michel Py proposes to add a new requirement
[original text] "IPv6 multihoming solutions MUST be compatible with
sites that implement RPF checks or filtering that prevents traffic to be
sent back from a different interface it came in."
After reading Ran's text Michel decides to withdraw his and support Ran's
text that is a lot better.
Text from RJ Atkinson:
"IPv6 multihoming solutions MUST NOT preclude filtering out packets with
obviously forged Source IP Address values at the administrative boundary
of the multi-homed site. The details of how such filtering is implemented
MAY vary depending on the IPv6 multihoming solution, provided there is
some mechanism for performing such filtering that works with the
multihoming solution proposed."
Possible modifications:
1. Please send text
2. Do nothing
3. add new requirement per RJ Atkinson's text.
4. add new requirement without the word "obviously"
Opinions about it:
RJ Atkinson:
The above text [refers to Michel's original proposal] is too specific and
thus unduly narrows the range of solutions to the underlying issue. The
underlying issue in this case is blocking obviously forged source addresses
from leaving/entering an given administrative domain.
Michel Py:
Concur with Ran.
Eliot Lear:
I agree with Ran's comment, with the exception that I would strike the
word "obviously". If you can tell that it's forged, whether it's obvious
or not, that's good enough for me ;-)
Add yours here: