Subject: Re: [RAM] Goal: Minimising Routing Entropy

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Jan 2007 16:25:08 +0100

On 2006-12-29 15:42, RJ Atkinson wrote:
> 
>     I'd like to suggest that an architectural goal
> for any new effort should be to reduce/minimise Routing
> Entropy.  

My instinct is that this is a Good Thing, but my other concern
is churn rates (which are obviously related to entropy
among other things). I'd rather get a handle on the dynamics
before being sure whether the target should be entropy
itself or some aspect of the churn.

     Brian

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: David Meyer <[email-masked]>
Date: Thu, 4 Jan 2007 09:53:55 -0800

> itself or some aspect of the churn.

	Brian,

	As you might imagine, I agree with this statement.

	--dmm

---

From: Tony Li <[email-masked]>
Date: Thu, 4 Jan 2007 10:20:11 -0800

> 	As you might imagine, I agree with this statement.

I'm intrigued by this.  To my way of thinking, the churn rate is an  
artifact of BGP's design, the actual physical changes in the  
topology, and operational input.  It doesn't really seem to be  
architectural, it's just a side-effect of the control plane  
mechanisms that we've chosen.

That's not to say it's not an important issue...

Tony

---

From: David Meyer <[email-masked]>
Date: Thu, 4 Jan 2007 10:36:53 -0800

> mechanisms that we've chosen.

	I think I can agree with that. My goal in studying
	network dynamics are two-fold: First, I'd like to build
	an unbiased (in the statistical sense) model (or just 
	find one) that will help us understand the dynamic nature
	of the BGP UPDATE stream. This may not be architectural,
	but these studies do help us to better understand the
	properties of BGP. Second, such studies would, I imagine,
	inform future architecture and design. As a side effect,
	it would be nice to have the (mathematical) machinery
	available to do this kind of work on whatever protocols
	we deploy (to the extent such machinery could be made
	general purpose). 

	And anyway, all of this convolves my interests in
	complexity, paleontology (who doesn't like dinosaurs?),
	and networking, and fun is allowed, right :-)  

	--dmm

---

From: Russ White <[email-masked]>
Date: Fri, 05 Jan 2007 08:59:17 -0500

> artifact of BGP's design, the actual physical changes in the topology,
> and operational input.  It doesn't really seem to be architectural, it's
> just a side-effect of the control plane mechanisms that we've chosen.

I would tend to say it's more of an artifact of the way BGP has been
deployed, due to operational and financial pressures combined with the
AS Path hunting effect you get when removing a destination or short path
from the system.

I think (?) that no matter if we got rid of BGP's hunting effect (which
is possible without totally replacing BGP, I think), we would still have
some measurable churn because of simple deployment issues.

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Jan 2007 16:02:34 +0100

>> mechanisms that we've chosen.

If that turns out to be true, it's excellent news - we don't
need to change the architecture, we just need to fix the
control plane. Seriously.

> 	we deploy (to the extent such machinery could be made

Yes - which argues for a powerful modelling tool for a large-scale
simulated BGP4ish world.

     Brian

---

From: Tony Li <[email-masked]>
Date: Fri, 5 Jan 2007 13:10:32 -0800

On Jan 5, 2007, at 7:02 AM, Brian E Carpenter wrote:

>>> I'm intrigued by this.  To my way of thinking, the churn rate is  
>>> an  artifact of BGP's design, the actual physical changes in the   

Brian,

Is there some theory, argument or position that suggests that it's  
architectural?  If so, pointers please....

That said, I think that "just fixing the control plane" is not nearly  
as trivial as you make it sound.  I will point out that additional  
hierarchy (i.e., abstraction) of routing information would certainly  
help the problem, but that capability is already there today (e.g.,  
proxy aggregation) if folks could only bring themselves to use it...

Regards,
Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 08 Jan 2007 17:03:04 +0100

> architectural?  If so, pointers please....

Frankly I think there's a lack of analysis, but certainly
I have no such pointers.

> 
> That said, I think that "just fixing the control plane" is not nearly as 
> trivial as you make it sound.  I will point out that additional 

Correct, it isn't trivial, but control plane fixes should at least be
possible on a stepwise basis, which strikes me as doable.

     Brian