Subject: [RRG] Precision of the goals?

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Apr 2007 10:05:32 +0200

I'm wondering how much precision there should be in the goals.
Just to take the first one as an example:

>    Thus, the first required goal is to provide significant improvement
>    to the scalability of the routing plane.

Should we be looking for a way to measure that goal? For example,
by having a goal that the RIB size goes like log(N) for some measure N?
Obviously that is simplistic - my point is to ask whether we
want to define metrics.

If the goals are only qualitative, it will be hard to judge
proposals.

BTW another point occurred to me when reading the Asbtract

>     ...The RRG is designing
>    an alternate architecture to meet these challenges.  This document
>    consists of a prioritized list of design goals for the architecture.

If we want the broader community to take any notice of the promised design,
it seems necessary to get some measure of buy-in from the broader community
for the goals, once they have taken shape.

     Brian

--
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: Fri, 27 Apr 2007 07:48:04 -0700

Hi Brian,

> If the goals are only qualitative, it will be hard to judge

Well, my take on it is that we will have a hard time being  
quantitative about all of the goals.  How do we quantify  
'deployability', for example?   And if we can't quantify all of the  
goals, is there really a benefit in quantifying some of them?

This is exactly why the second paragraph of the introduction is a  
request to use 'good judgement'.

There are also other considerations, such as folks "designing to the  
test" and gaming the system by rigging the goals that we should  
avoid, IMHO.

> for the goals, once they have taken shape.

Yes, that certainly makes sense.  Any specific requests there?  Does  
presenting it to INT area seems sufficient?

Tony

---

From: Mark Townsley <[email-masked]>
Date: Fri, 27 Apr 2007 17:50:36 +0200

Tony Li wrote:
> test" and gaming the system by rigging the goals that we should avoid, 
> IMHO.
>
>
That's one avenue. You could send email to [email-masked], and if 
you'd like a slot in Chicago we could probably work that out. Also, the 
roap directorate has a charter which includes reporting on what is 
happening to the broader community, so perhaps consult with it as well.

- Mark

---

From: [email-masked]
Date: Fri, 27 Apr 2007 17:07:26 EDT

IMO the biggest hurdle for the most that take part in this discussion is  
their expertise on traditional IETF (BGP) routing. My recommendation: Lean back,  
forget about all the details, ignore what is a RIB or FIB, or stretch or 
other  measurements,but trust yourself. Let loose. Don't be afraid of any 
revolutionary  solution. Because at the end, there will be enough time and opportunity 
to think  about how the existing machinery (OSPF,BGP) can be utilized for any 
solution  that will replace exactly these routing protocols.
 
Heiner
 
In einer eMail vom 27.04.2007 10:06:45 Westeuropäische Normalzeit schreibt  
[email-masked]:

Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Apr 2007 10:52:59 +0200

Tony,

>> goals, is there really a benefit in quantifying some of them?

I think so, where it's possible. And I'm really not looking for
firm numbers necessarily - just something that allows us to review
a proposed solution other than by gut feeling.

>> request to use 'good judgement'.

Yes

>> test" and gaming the system by rigging the goals that we should avoid, 

Yes. But things like "log N rather than N^2" probably can't be gamed.

> happening to the broader community, so perhaps consult with it as well.

I'd assume that the INT and routing areas are mainly concerned, but
personally I hope all the IETF areas will have a look - either this
is useless work, or it's truly fundamental.

     Brian

---

From: Tony Li <[email-masked]>
Date: Mon, 30 Apr 2007 12:54:52 -0700

>>> 'deployability', for example?   And if we can't quantify all of  
>>> the goals, is there really a benefit in quantifying some of them?
>
>>> There are also other considerations, such as folks "designing to  
>>> the test" and gaming the system by rigging the goals that we  
>>> should avoid, IMHO.
>

Brian,

I'm not opposed to the suggestion, but I'm not sure how to specify  
metrics that will capture proper space/time complexity measures  
without inviting folks to drown us in detail or enable gaming.   
Specific contributions are most welcome.

My best take for routing growth would be something like:

	The proposed solution must limit growth in the size of the table to  
not exceed 1.2X/2 years.

Regards,
Tony

---

From: Lixia Zhang <[email-masked]>
Date: Thu, 10 May 2007 14:46:56 -0700

> Specific contributions are most welcome.

Let me try a strawman here: as far as we can see from the BGP data,  
the number of ISPs has been grown very slowly over the years; today's  
routing scalability problem is largely due to the growth of Internet  
user sites which are also multihomed. And because the ISPs are the  
ones who feel the pain when the routing system size grows beyond  
"comfortable" range, there seems a feedback loop for ISP-induced  
routing growth.
So What about adding the following quantifier to the existing  
scalability goal:

    the first required goal is to provide significant improvement
    to the scalability of the routing plane; it is highly desirable
    to make the routing plane scale independently from the Internet
    user population growth.

Lixia

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 May 2007 16:29:39 +0200

Sorry, I've been off-line... below...

On 2007-05-10 23:46, Lixia Zhang wrote:
>>>>> the test" and gaming the system by rigging the goals that we should 
>>>>> avoid, IMHO.
>>>
> Let me try a strawman here: as far as we can see from the BGP data, the 
> number of ISPs has been grown very slowly over the years; today's 
> user sites which are also multihomed. And because the ISPs are the ones 
> who feel the pain when the routing system size grows beyond 
> "comfortable" range, there seems a feedback loop for ISP-induced routing 
> growth.

Yes, I think that is a good compromise between completely qualitative
goals and over-specification; it offers some sort of measuring
stick.

     Brian

---

From: Tony Li <[email-masked]>
Date: Fri, 18 May 2007 15:21:33 -0700

> goals and over-specification; it offers some sort of measuring

Thanks Brian.

I've received a comment suggesting that "routing plane" is somewhat  
informal and less precise than the commonly accepted "control plane",  
so I've shifted to that terminology.  Also, we've defined the term  
"strongly desired" for expressing our priorities, so I've used that  
instead.  After some minor wordsmithing, the resulting text then reads:

	  ... Carrying this large amount of state in the
	  control plane is expensive and places undue cost burdens on network
	  participants that do not necessarily get value from the increases in
	  the routing table size.  Thus, the first required goal is to provide
	  significant improvement to the scalability of the control plane.
	  It is strongly desired to make the control plane scale
	  independently from the growth of the Internet user population.

Is everyone ok with that?

Tony

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 21 May 2007 12:43:03 +0200

I actually rather liked the use of routing plane.  The trouble with control
plane is that in work such as ccamp (close to the hearts of many operators), it
is mostly about signalling, not routing, and may be taken to include such
protocols as icmp, and is used in contrast to against management and user/data
planes..  I see no such baggage with routing plane.  My own approach is to
explain what I mean by control plane when I first use it because I do not see it
as well-defined.

Tom Petch

---

From: [email-masked]
Date: Wed, 23 May 2007 02:50:05 EDT

Suggestions:
Let's use the terms "forwarding plane" (instead of control plane) and  
"routing plane".
 
Both planes as well as their close relationship have to be  considered.
 
Heiner
 
In einer eMail vom 22.05.2007 23:49:19 Westeuropäische Normalzeit schreibt  
[email-masked]:

actually  rather liked the use of routing plane.  The trouble with control
plane  is that in work such as ccamp (close to the hearts of many operators), 
 it
is mostly about signalling, not routing, and may be taken to include  such
protocols as icmp, and is used in contrast to against management and  
user/data
planes..  I see no such baggage with routing plane.  My  own approach is to
explain what I mean by control plane when I first use it  because I do not 
see it
as well-defined.

Tom Petch

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 May 2007 23:54:15 -0700

> Let's use the terms "forwarding plane" (instead of control plane)  
> and "routing plane".

Data-plane and control-plane are more accepted terms. Plus they are  
obvious terms, which is goodness for clarity.

Dino

---

From: [email-masked]
Date: Wed, 23 May 2007 03:46:33 EDT

In connection-oriented ITU-T-homed layer-3 technology there is the
separation of (1) data-plane and (2) signalling Plane (=control plane),  e.g. 
in ISDN-technology there is the 
(1) b-channel and the (2) d-channel.
 
I think this is pretty orthogonal with the differentiation between routing  
plane and forwarding plane as known from the connection-less IP-technology. It  
could be so easy to call things such that there is no mix up.
 
Heiner

Dino