Subject: Re: other requirement? (was Re: [RAM] Traffic Engineering

From: [email-masked] (Noel Chiappa)
Date: Wed, 3 Jan 2007 12:12:06 -0500 (EST)

> From: David Meyer <[email-masked]>

    > Its not clear to me (yet) what the architectural design constraints
    > we're working with here are.

Sadly, I suspect the engineering constaints (from legacy/interoperability/etc)
are likely to be far more significant than architectural ones... :-(

	Noel

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

---

From: [email-masked]
Date: Wed, 3 Jan 2007 18:31:17 +0000

> are likely to be far more significant than architectural ones... :-(

	lessons from NIMROD aside, what would you do TODAY, knowing what we know 
	about the existing systems, the scalability properties and projected
	growth/traffic patterns?

	Radia and others have recently been dabbling w/ the ideas of grafting
	some of the old bridging/arp techniques into the routing system.  Such
	a thing might be very useful, esp if one wants to do things like make
	multicast a first-class player - presuming flooding techniques.
	And _IF_ those kinds of assumptions hold, then existing/legacy/interop
	considerations maybe less important.

	YMMV of course.  Strawpoll... What percentage of IP process stacks will be 
	"untethered", mobile, and only "on" for a percentage of their lifespan
	in 10, 15, 20 years?  What percentage will be fixed, tethered, and 
	always on for a percentage of their lifetime in the next 10, 15, 20 years?

--bill

---

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

On Wed, Jan 03, 2007 at 12:12:06PM -0500, Noel Chiappa wrote:
> Sadly, I suspect the engineering constaints (from
> legacy/interoperability/etc) are likely to be far more
> significant than architectural ones... :-( 

	Well, yeah, and I guess this was the point of Mark
	Handley's "Why the Internet only just works" [0] (i.e.,
	that the incremental deployablity is the primary
	requirement for internet technologies today). 

	OTOH, maybe this is the opportunity to actually do
	something progressive/innovative in this space. And hey,
	why not? 

	So, to that end, what constraints do folks feel we are
	working with?

	--dmm

[0] http://www.cs.ucl.ac.uk/staff/M.Handley/papers/only-just-works.pdf
_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram