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

From: Tony Li <[email-masked]>
Date: Fri, 20 Apr 2007 12:55:53 -0700

FYI...

Begin forwarded message:

> From: [email-masked]
> Date: April 20, 2007 12:50:01 PM PDT
> To: [email-masked]
> Subject: I-D ACTION:draft-irtf-rrg-design-goals-00.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: Design Goals for Scalable Internet Routing
> 	Author(s)	: T. Li
> 	Filename	: draft-irtf-rrg-design-goals-00.txt
> 	Pages		: 9
> 	Date		: 2007-4-20
> 	
>    It is commonly recognized that the Internet routing and addressing
>    architecture is facing challenges in scalability, mobility, multi-
>    homing, and inter-domain traffic engineering.  The RRG is designing
>    an alternate architecture to meet these challenges.  This document
>    consists of a prioritized list of design goals for the  
> architecture.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-irtf-rrg-design-goals-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-irtf-rrg-design-goals-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-irtf-rrg-design-goals-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: "Ricardo V. Oliveira" <[email-masked]>
Date: Tue, 24 Apr 2007 18:07:10 -0700

Hi,

I just a brief comment about sec 3.8, Routing Quality.
In the space dimension, "Path inflation" has been used to describe  
how much the selected route is longer than the shortest geographic  
distance of all alternative routes between a pair of nodes, e.g.
http://www.sigcomm.org/sigcomm2003/papers/p113-spring.pdf
In the time dimension, routing quality can also be measured by its  
stability, i.e. the time routing keeps it state.
Convergence is a factor that affects routing stability, e.g. http:// 
www.cs.ucla.edu/~rveloso/papers/imc175f-oliveira.pdf

--Ricardo

--
to unsubscribe send a message to [email-masked] 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

---

From: Tony Li <[email-masked]>
Date: Wed, 25 Apr 2007 10:21:58 -0700

Hi Ricardo,

> http://www.sigcomm.org/sigcomm2003/papers/p113-spring.pdf

Thanks for the reference.  As far as I know, 'stretch' is the  
commonly used, accepted terminology and unless there's some  
compelling reason not to do so, we should probably use that.

> www.cs.ucla.edu/~rveloso/papers/imc175f-oliveira.pdf

Good point, I'll add stability to the list.  Any objections?

Tony

---

From: Pekka Savola <[email-masked]>
Date: Wed, 30 May 2007 11:12:46 +0300 (EEST)

Hi,

Comments on the design goals.

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

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.

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)?

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.

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?

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.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: [email-masked]
Date: Wed, 30 May 2007 13:26:53 EDT

In einer eMail vom 30.05.2007 10:15:59 Westeuropäische Normalzeit schreibt  
[email-masked]:

.... 

==> 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 question. Compatibility: IMHO, the solution must  provide a  next-hop 
too. And this should at first be the only compatibility  constraint. Otherwise 
it wouldn't be research.
 
Will say: while searching for a new solution, the compatibility issue  should 
be ignored. However after a solution has been found, it is appropriate to  
look for a migration path and deal with compatibility issues.
 
Heiner

---

From: Tony Li <[email-masked]>
Date: Wed, 30 May 2007 14:15:28 -0700

Hi Pekka,

Thank you very much for your comments.

> right now that would need to be added...

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

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

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

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

> ==> 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?

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

> 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