[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Fwd: I-D ACTION:draft-irtf-rrg-design-goals-00.txt


Hi Pekka,

Thank you very much for your comments.

On May 30, 2007, at 1:12 AM, Pekka Savola wrote:
As a meta-issue I didn't see many requirements on operations and management aspects, but some of those are implictly lurking beneath the "deployability" subsection. But I couldn't think of anything right now that would need to be added... 


When you do think of some, please feel free to propose text.



substantial
-----------

   RFC 1958 [RFC1958] provides an excellent list of the original
   architectural principles of the Internet.  We incorporate them here
   by reference, as part of our desired design goals.
==> I do not think this is sufficient. RFC1958 seems include two kinds of material; general principles and discussion and specific guidelines. Are you referring to the both or just the latter? However, even the specific guidelines use a different encoding for 'Priorities' so a) it's not clear what the RFC1958's design goals are wrt this document, and b) it's not clear what their priorities are.
If we want to include design goals from RFC1958 I believe it's necessary to at least mention them one by one as bullet points and assign them priorities or specify a prioprity mapping function. 


A fair point.  Care to propose a mapping?
(Aside: I'm trying to ensure that this document is a collaborative effort, not just an objection-neutralized version of my inputs. Towards that end, I'm trying to follow the excellent example of Phil Almquist when working on RFC 1812. Thus, your contributions are strongly encouraged and preferred over my inputs.) 



3.6.  Decoupling location and identification
...
Solutions to both problems, i.e. (1) the decoupling of
   host location and identification information and (2) a scalable
global routing system (whose solution may, or may not, depend on the second decoupling) are needed and it is required that their solutions 
   are compatible with each other.
==> the only requirement (using the language described in section 1.2) I see in this subsection that that the solutions are compatible with each other. Is that the intent? In particular was 'are needed' above meant to be some priority? What does solution compatibility requirement even mean (in practice)?
Good catch, thanks. Yes, that should probably read "are required" rather than "are needed". Change accepted.
Informally, I would say that the solutions are compatible if we can do both at the same time and not have complexity blow up in our faces. If you feel we need to say something formal here, please propose text. 



3.7.  First-class elements

   If a solution makes use of a mechanism, it is strongly desired that
   the mechanism be a first-class element in the architecture
[FirstClass]. More specifically, if a tunneling mechanism is used to 
   provide network layering, connectivity virtualization, or a
   connection-oriented mode, then it is strongly desired that the
   tunneling mechanism be a first-class element in the architecture.
==> I don't disagree with this, yet I wonder why this is listed as a goal. Some justification should be added. This seems written like an implementation detail. Maybe what you actually have as a goal is something else, e.g., that mechanisms of the architecture should be usable by other pieces of the architecture.
I've added this because over the years, tunneling has been a "cobbler's son" portion of the architecture: it's been absolutely necessary, used frequently, and gotten short shrift in the architecture. Consider, for example, the lack of traceroute and other management tools for MPLS LSPs at the onset. (This isn't meant to be throwing stones, I was on the wrong side of that one.)
Yes, being a first-class element means that it can be reused by other pieces of the architecture. Moreover, it should not need reinvention or modification for each application. It should come complete with management tools, MTU mechanisms, layering and recursion prevention. 

In short, if we're going to tunnel, let's do it right.

Care to propose textual changes?



3.9.  Routing security

   Currently, the routing subsystem is secured through a number of
   protocol specific mechanisms of varying strength and applicability.
   Any new architecture is required to provide at least the current
   level of security.
==> is the 'current level of security' intended to be a punt? As we've seen on RAM/arch-d lists, some people feel that RFC4218 described the current level, yet others seemed to disagree with that. Should this be stated more clearly, or do we want to defer the debates on what the 'current level of 
security' is until later?
It's not intended to be a punt, but it is meant to be one level of indirection. We recognize that the state of security will evolve over time and hopefully progress beyond where it is today while we conduct our work. We would like to see a new architecture "keep up", while not requiring it to break new ground. 

Proposed rewording of the last sentence:
Any new architecture is required to provide at least the same level of security as is deployed 
	as of when the new architecture is deployed.



3.10.  Deployability

   Since solutions that are not deployable are simply academic
   exercises, solutions are required to be deployable.  Furthermore,
given the extensive deployed base of today's Internet, a solution is 
   required to be incrementally deployable.

==> I don't think this is quite explicit enough.  'Required to be
deployable' -- deployable by whom? That's a very critical question. All 
sorts of solutions can be proposed which are deployable by some
organizations involved in the network, but whether those have any incentive to deploy it is another question altogether. Did you mean to include the latter 
(incentives and actual deployments) in your requirement?
The same applies to incremental deployments.
I don't think there is much use in designing solutions that are deployable, even incrementally deployable, if those people who would need to deploy them are not interested in doing so. Rather I'd like to require that those people who feel the pain will also need to take responsibility of mitigating it, not try to push it around to someone else.
Dave Thaler and I have already had that discussion on the RAM list. If one perceives the issue as a 'routing' problem, then the only acceptable solutions are going to be changes to the routing infrastructure. However, if you take the real issue to be one of addressing, then it is a broader problem. Getting consensus on the appropriate viewpoint seems to be challenging.
From my perspective, it's an Internet problem, and doing what's best for the overall architecture of the Internet is the only reasonable approach. Anything else is simply silo politics and is not in the best interests of the user community.
As far as the intent of section is concerned, the gist was more technical than political or economic. Please recall that our goal, as a group, is to perform research and make a recommendation to the IETF. While a result that is acceptable to a broad audience is the preferred outcome, a result that does not equally serve all parties (especially in the short term) is not out of the question. In fact, perfect equality is very unlikely to be achievable. Our primary goal must be to do what's best for the Internet as a whole and it really is the province of the IETF leadership to encourage all parties to step up for the greater good. 

That said, let me propose the following rewording:

	Since solutions that are not deployable are simply academic
	exercises, solutions are required to be deployable from a technical
	perspective. Furthermore, given the extensive deployed base of
	today's Internet, a solution is required to be incrementally
	deployable.

Does that work for you?

Regards,
Tony

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg