Subject: RE: [RAM] moving a discussion from various I* lists to [email-masked]

From: "Schliesser, Benson" <[email-masked]>
Date: Wed, 20 Dec 2006 21:00:38 -0600

> From: Fergie [mailto:[email-masked]] 
> [...]
> In other words, it would be nice to hear from the router what they
> are doing to meet the obvious future needs here.

I'll posit that the router vendors see competitive advantage in
capitalizing a solution to this problem and aren't inclined to share
openly.
(Though perhaps I am too cynical?)
Generally speaking, this is the sort of problem that's already been
solved in other domains. So, I'd expect to see some reasonable
innovation in the router space. That doesn't make me any less nervous,
though, especially nervous about the deployability/economics...

Cheers,
-Benson

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

---

From: "Chris L. Morrow" <[email-masked]>
Date: Thu, 21 Dec 2006 03:36:31 +0000 (GMT)

> capitalizing a solution to this problem and aren't inclined to share

that could be, which would be unfortunate I think. I don't see how many of
the currently proposed directions will work in a single vendor world.

> though, especially nervous about the deployability/economics...

Agreed, I think it's important to not discard any thing out of hand at
this point in the game though. Given a solid-ish problem statement some
requirements could arise and better selection of direction may be simple,
right?

-Chris

---

From: David Meyer <[email-masked]>
Date: Thu, 21 Dec 2006 07:22:42 -0800

On Wed, Dec 20, 2006 at 09:00:38PM -0600, Schliesser, Benson wrote:
> solved in other domains. 

	Can you provide an example from another domain? That
	might be informative.

> So, I'd expect to see some reasonable innovation in the router
> space. That doesn't make me any less nervous, though,
> especially nervous about the deployability/economics... 

	Sure, and to be direct: The size of the RIB/FIB also
	reflects the granularity of the information that the
	routing system is carrying. The finer-grained that
	information is, the more the core of the network will
	"see" the dynamics of the edges, which converts, more or
	less, to BGP UPDATE rates. So the size of the RIB (or
	FIB) is not independent of the dynamics of the network.

	That being said, my concern about the UPDATE dynamics
	stuff is that we don't know if there are non-linear
	effects in the system that have the potential to
	overwhelm *any* hardware solution. I don't know the
	answer to that, but I'll just note that if the 2.8 x 10^6
	daily UPDATEs (that Geoff predicts by the end of 2010)
	arrive in a small number of bursts, well, that would be
	challenging. That is, how many UPDATEs/sec can we handle,
	with what kind of burstiness, and with what kind of
	prefix packing? Then trigger all of the other components
	of BGP convergence (i.e., FIB download, as Chris was
	mentioning). There's quite a bit that we don't understand
	in that equation.  
	
	And BTW, if the UPDATE stream exhibits some kind of LRD
	(Long Range Dependence), and has a Hurst parameter (H)
	[0] that is something > 0.5 (0.0 <= H <= 1.0), then the
	burstiness of the UPDATE stream is "chaotic" (and in
	addition, there can be unattractive feedback effects),
	so we need to think carefully about that. But as I said
	above, our understanding of all of this is weak.

	I knew I'd figure out a way to work my favorite topic
	(complexity) into this discussion :-)

	--dmm

[0]	FWIW (and very briefly), the Hurst parameter (H) is a
	measure of the level self-similarity of a time series
	that exhibits some kind of LRD.
_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram