Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering

From: [email-masked] (Noel Chiappa)
Date: Mon, 1 Jan 2007 16:50:19 -0500 (EST)

> From: Tony Li <[email-masked]>

    > Architecturally, sites that simply differ in traffic volume or internal
    > complexity shouldn't be dealt with separately. Thus, a 'clean' solution
    > should not require entirely different solutions for different market
    > sub-segments.

Tony, a nice goal, but I wonder... I think there's something to the line of
reasoning (well put by Marcelo) that says that big sites probably have
important differences which may have to be reflected in the mechanisms. (Size
does matter in computer science! :-)

I wonder if perhaps there's some way to have our cake and eat it too; have
the same basic architecture (and therefore support substrate, like
identity/location separation), but make the engineering mechanisms different
in the two cases, to take into account scale differences?

	Noel

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

---

From: Roland Dobbins <[email-masked]>
Date: Mon, 1 Jan 2007 14:11:01 -0800

> does matter in computer science! :-)

While Marcelo's assumptions in that regard are perfectly reasonable  
and understandable, the differences aren't as large as one would  
think; and enterprises actively wish to minimize those differences  
further, if they can (in the direction of lesser complexity, obviously).

Other than size/volume and internal complexity, I can't really think  
of any qualitative differences of a significant and consistent enough  
nature to be used as any sort of objective criteria on which to  
predicate a split.  Perhaps others may have thoughts they can  
contribute?

> in the two cases, to take into account scale differences?

This isn't desirable, but it may be less undesirable than other  
alternatives which have been put forth to date.  However, I strongly  
agree with tli that identifying a scalable solution which doesn't  
operate differently based upon volume or internal complexity is an  
important principle to maintain, if at all possible.  Somewhat  
significant differences between singlehomed and multihomed sites is  
acceptable; we've that today with the requirement for BGP.  But  
significant differences between dual-homed sites and a quad-homed  
sites, for example, is highly undesirable, and should be avoided if  
it's possible to do so.

[ I write this understanding that in the final analysis, it may be  
impossible to maintain this principle, but I think it's really,  
really important that we try to do so.  It would be one of the last  
principles I'd discard, given any choice at all. ]

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // 408.527.6376 voice

		All battles are perpetual.

     		   -- Milton Friedman

---

From: Tony Li <[email-masked]>
Date: Mon, 1 Jan 2007 15:11:38 -0800

> the same basic architecture (and theFrom [email-masked] Mon Jan 01 18:12:14 2007
From: Tony Li <[email-masked]>
Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re:
	[RAM] Traffic Engineering
Date: Mon, 1 Jan 2007 15:11:38 -0800
To: Noel Chiappa <[email-masked]>
Cc: [email-masked]

> in the two cases, to take into account scale differences?

I could be convinced by concrete counter examples, but the only  
distinctions that I can see are:

a) sites that have exactly one ASBR
b) sites that have more than one ASBR

Tony

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 2 Jan 2007 17:42:25 +0100

> in the two cases, to take into account scale differences?

yes, maybe this is a nice way of seeing it...

maybe there are some optional features that could be left out for very 
simple sites, or we could have default configurations that are defined 
for the simple sites and thay would require additional tunning for more 
complex sites...

Again, for me one of the biggest differences is that in small sites we 
cannot assume that there we qualified people to configure the solution.

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 2 Jan 2007 17:50:55 +0100

> b) sites that have more than one ASBR

that certainly makes things easier, i guess that the sites with more 
than one exit router may need additional protocol/mechanisms (it is 
certainly the case for shim6)

So, i think this could be one case of having optional mechanisms for 
more complex setups.

Regards, marcelo