Subject: [rrg] Last call: Design goals

From: Tony Li <[email-masked]>
Date: Tue, 19 Oct 2010 09:24:31 -0700

Hi all,

I'd like to issue a last call for the design goals document: http://tools.ietf.org/html/draft-irtf-rrg-design-goals-02

As I'm expecting some discussion, I'd like to make this a bit longer than usual. Therefore, the last call will close in two weeks.

Thanks,
Tony

---

From: [email-masked]
Date: Wed, 20 Oct 2010 06:56:04 -0400

3.1.Improved routing scalability 
Itlacks naming the two aspects in the first place: memory consumption andCPU-performance (update churn). Only thereafter it makes sense to requestindependency from the internet user population. Why is the control planementioned specifically? I don’t understand. It is neither necessary norcorrect.
 
3.2.Scalable support for traffic engineering
BadEnglish: The solutions should also be scalable also wrt detouring routes. ( andnot wrt to traffic engineering).
  
3.3.Scalable support for multi-homing
Itwouldn’t be bad to mention that multi-homing is just a particular aspect ofmultipath. 
3.4.Scalable support for mobility 
Weshould also mention support of PRIVACY (where is the roaming user at thismoment). Privacy can always be supported (i.e. by any solution) by employing ahome agent who will or who will not relay. We may need to deal with bothoptions. The current text fosters the belief that   some solution  
mayprovide both concurrently.
 
3.5.Simplified renumbering 
Thebest of all is not mentioned: solutions which do not require any renumbering. 
3.6.Decoupling location and identification 
Ihave strong doubts that this community has fully understood what loc/id-splitmay mean. 
3.7.First-class elements 
Halfof this paragraph is used to explain this weir headline.
Whatis really intended here, should be expressed simpler and without this climbim.

3.8.Routing quality 
 A lot of words in order to get to the term“stretch”.
Ihave my own suspicion why this term had been invented (and why it has beenadopted). I can imagine that routing quality may also mean different aspects(QoS,…) 
 
3.9.Routing security
Nocomment to this place holder phrase. 
 
3.10. Deployability 
The first sentence can be deleted (blabla only).
Any solution which required a flag day is out from thebeginning.
Yes, incremental deployability is definitely required.
However, I think that ALL solutions can provide this(all the so far displayed as well as all not-yet born solutions:-)

Furthermore I miss 3.11: 
The solution should also enable Moore's Law as addressed in RFC4984

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Tony Li <[email-masked]>
An: [email-masked]
Verschickt: Di., 19. Okt. 2010, 18:24
Thema: [rrg] Last call: Design goals

Hi all,

I'd like to issue a last call for the design goals document: 
http://tools.ietf.org/html/draft-irtf-rrg-design-goals-02

As I'm expecting some discussion, I'd like to make this a bit longer than usual. 
Therefore, the last call will close in two weeks.

Thanks,
Tony

_______________________________________________
rrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: Tony Li <[email-masked]>
Date: Wed, 20 Oct 2010 09:35:00 -0700

Hi Heiner,

Thank you very much for commenting.

> 3.1. Improved routing scalability
> It lacks naming the two aspects in the first place: memory consumption and CPU-performance (update churn). Only thereafter it makes sense to request independency from the internet user population. Why is the control plane mentioned specifically? I don’t understand. It is neither necessary nor correct.

The control plane subsumes the memory, bandwidth and CPU required for routing, both within individual systems and network-wide.  We distinguish from the data plane, which is the transit traffic.  There are similar scalability issues in the data plane, but the argument there is much more challenging to make and is not widely accepted.

>  3.2. Scalable support for traffic engineering
> Bad English: The solutions should also be scalable also wrt detouring routes. ( and not wrt to traffic engineering).

By detour routes, I'm assuming that you're talking about FRR and similar technologies.  This would seem to be an independent issue and I don't think we have any agreement that this is an inter-domain issue.

>  3.3. Scalable support for multi-homing
> It wouldn’t be bad to mention that multi-homing is just a particular aspect of multipath.

Sorry, I'm not seeing your point.  Does multi-path support affect our design goals?  

> 3.4. Scalable support for mobility
> We should also mention support of PRIVACY (where is the roaming user at this moment). Privacy can always be supported (i.e. by any solution) by employing a home agent who will or who will not relay. We may need to deal with both options. The current text fosters the belief that   some solution 
> may provide both concurrently.

Agreed.  Added a comment:  

	"Mechanisms that help to provide more
	  efficient and scalable mobility support are desired, especially
	  when they can be coupled with security, _especially privacy_, and
	  support topological changes at a high-rate."

> 3.5. Simplified renumbering
> The best of all is not mentioned: solutions which do not require any renumbering.

Fair enough.  Added.

> 3.6. Decoupling location and identification
> I have strong doubts that this community has fully understood what loc/id-split may mean.

This doesn't seem like a document where we should be educating them.

> 3.7. First-class elements
> Half of this paragraph is used to explain this weir headline.
> What is really intended here, should be expressed simpler and without this climbim.

Please propose text.  I realize that my background is unique, but I know of no better way to accurately and concisely describe this in polite and professional language.  Saying that "the architecture can't be a kludge" or "no cheesy hacks" doesn't seem to be appropriate.  ;-)

> 3.8. Routing quality
>  A lot of words in order to get to the term “stretch”.
> I have my own suspicion why this term had been invented (and why it has been adopted). I can imagine that routing quality may also mean different aspects (QoS,…)

If you would care to propose text, I would be happy to replace the current definition.  This is taken from the academic literature, where they wanted a metric to evaluate routing quality.  Personally, I don't consider it to be a very practical measure, as it ignores policy and the granularity is poor.  A stretch of 2 is simply disastrous.

>  3.9. Routing security
> No comment to this place holder phrase.

Your sarcasm is not constructive.  If you dislike the content, please propose alternate text.

> Any solution which required a flag day is out from the beginning.
> However, I think that ALL solutions can provide this (all the so far displayed as well as all not-yet born solutions:-)

Clearly, this is not the case.  It is very clear that one can propose a solution that there are non-deployable flag-day solutions.  While they are not going to fall into anyone's definition of common sense, it is incumbent on us to be clear about the requirements anyway.  In fact, in the past, this was a significant point of discussion.

> The solution should also enable Moore's Law as addressed in RFC4984

I'm sorry, I don't understand your point.  As has been argued in 4984, Moore's Law is not the only constraint that we must work with.  DRAM latency, for example, is NOT subject to Moore's Law.  Care to propose text?

Regards,
Tony

---

From: Tony Li <[email-masked]>
Date: Fri, 22 Oct 2010 13:28:04 -0700

Hi folks,

As the number of changes were piling up, I've submitted an -03 working version that can be found here:

http://tools.ietf.org/html/draft-irtf-rrg-design-goals-03

This doesn't change the end of the last call.

Thanks,
Tony

---

From: Sampo Syreeni <[email-masked]>
Date: Sat, 23 Oct 2010 01:02:54 +0300 (EEST)

> This doesn't change the end of the last call.

It don't. But you have to acknowledge that the original was a bit vague, 
plus that the sudden onslaught of opinion probably happened because of 
that.

If I was to be truly evil, I'd ask which precise, verifiable research 
findings does this report embody? ;)
-- 
Sampo Syreeni, aka decoy - [email-masked], http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

---

From: Paul Jakma <[email-masked]>
Date: Mon, 25 Oct 2010 19:31:37 +0100 (BST)

Hi Tony,

Some idle thoughts on the routing quality section..

Is it worth removing the "maximum" from the stretch definition, given 
that stretch can be defined for various cases, such as maximum and 
average? E.g.:

"The stretch of a routing scheme is a proportional measure of the 
increase in path length inherent to that scheme, relative to the 
length of the shortest path, for a pair of nodes in a network. 
Stretch often is expressed as the maximal, worst-case ratio a scheme 
will produce, have over all networks. However other measures of 
stretch may be interesting, such as the average case."

References, as per previous email from Stephen and myself: see 
Kleinrock, Kamoun, "Hierarchical Routing for Large Networks", '77 
(which looks at the average case); and Peleg & Upfal, "A trade-off 
between space and efficiency for routing tables", '89, might be 
weightier.

Also, this goal:

    "A solution is strongly desired to provide routing quality equivalent
     to what is available today or better."

simply may not be achievable if the stretch of BGP on the internet 
today is as close to 1 as can be gotten - which is not an 
unreasonable thing to think (??). In that case, according to the 
results of the Peleg paper, then any new routing scheme that 
decreases the size of the per-node routing table must inevitably also 
increase the stretch factor.

Perhaps therefore it should be slightly weaker, e.g.:

    "A solution is strongly desired to provide routing quality
     equivalent to what is available today, or as close as possible,
     if not better."

?

e.g. to get a 40% to 60% reduction in table sizes would imply a 
stretch in the region of 2 to 3 (for foreseeable sizes of the 
internet).

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
One of the worst of my many faults is that I'm too critical of myself.

---

From: Paul Jakma <[email-masked]>
Date: Tue, 26 Oct 2010 14:58:56 +0100 (BST)

> stretch in the region of 2 to 3 (for foreseeable sizes of the 

Oh, obviously increased stretch implies information hiding, likely 
including various kinds of aggregation. FWIW..

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
A drama critic is a person who surprises a playwright by informing him
what he meant.
 		-- Wilson Mizner

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 28 Oct 2010 19:16:31 +0300

Hello Tony, 

here are my comments to the design goals document:

1. Section 3.1 Improved routing scalability

You talk about "the control plane", but it is unclear what is the
Internets control plane? RFC 1958 that was referred in section 2 doesn't
mention anything about the control plane. Is FIB in your definition on
control plane? So, do you think that the solution should support the
scalability of FIBs? RIB is in my opinion on the routing control plane?
But what about the DNS? Is flow control on the control plane that the
document addresses? 

2. Section 3.4 Scalable support for mobility

Is this document only about the global routing, and not applicable to
intra domain nor MANET type of routing? Maybe the context should be
defined somewhere, preferably in the introduction. 

I do not think that there is a consensus whether mobility is part of the
global routing system. Why should it be?
 
3. Maybe section 3.10 Deployment

I am wondering why the interdomain policy aspects have been left out. In
order to be incrementally deployable the current policy/business
relationships should be supported: customer, peering and transit
relationships. At least on the architecture level. 

Best regards
Hannu

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Tony Li
>Sent: Friday, October 22, 2010 23:28
>To: Tony Li
>Cc: [email-masked]
>Subject: Re: [rrg] Last call: Design goals
>
>
>Hi folks,
>
>> As I'm expecting some discussion, I'd like to make this a 
>bit longer than usual. Therefore, the last call will close in 
>two weeks.
>> 
>> Thanks,
>> Tony
>> 
>> 
>>

---

From: Tony Li <[email-masked]>
Date: Thu, 28 Oct 2010 18:55:06 -0700

Hi Hannu,

Thanks for the comments.

> But what about the DNS? Is flow control on the control plane that the

Ok, thanks.  I'll expand on this a bit.

> defined somewhere, preferably in the introduction. 

Sure, we can expand on that.

> global routing system. Why should it be?

Actually, it should not be.  However, it is a function of the routing and addressing architecture.  This is exactly the bug that we're trying to fix.

> relationships. At least on the architecture level. 

Sure, worth mentioning.

Tony

---

From: Scott Brim <[email-masked]>
Date: Fri, 29 Oct 2010 08:21:34 -0400

> Ok, thanks.  I'll expand on this a bit.

Elsewhere I've used phrases like "control plane transport" for control
plane infrastructure such as data paths to exchange routing information.
 But DNS etc. are different, since both the control and forwarding
planes can function without them.  I like the phrase "infrastructure
services".

>> I do not think that there is a consensus whether mobility is part
>> of the global routing system. Why should it be?
> 
> Actually, it should not be.  However, it is a function of the routing
> and addressing architecture.  This is exactly the bug that we're
> trying to fix.

How mobility is done depends on and is shaped by how routing and
addressing are done.  Some routing and addressing approaches make
mobility simple to solve.  None of them make it truly hard.  (See also
the privacy issues with putting too much support for mobility in routing
and addressing.)

Scott