Subject: Re: [lisp] My comment at the mic during the WG meeting about evaluating/measuring complexity

From: David Meyer <[email-masked]>
Date: Wed, 25 Mar 2009 10:37:49 -0700

On Wed, Mar 25, 2009 at 10:25:55AM -0700, David Meyer wrote:
> On Wed, Mar 25, 2009 at 10:21:44AM -0700, David R Oran wrote:
> Christian Vogt raised a point at the mic during the WG meeting that  
> the LISP as a whole system appeared to be getting very complex and  
> cautioned that complex systems are hard to deploy and manage. Dave  
> Meyer commented that trying to evaluate complexity was hard/subjective  
> and we should not rat-hole on discussing LISP's complexity.
> 
> I don't have an opinion on whether LISP (as a system) is complex or  
> not, whether the complexity justified or gratuitous, or whether the  
> complexity represents a serious barrier to deployment and operation. I  
> do, however, disagree with Dave Meyer that we don't have pretty good  
> objective criteria for evaluating complexity, and that it would be  
> good to apply these to assessing LISP's complexity.
 
 	Well, what I intended was that it is not all that useful
 	to make statements like "addition of components makes
 	things more complicated".
 
> WG co-chair Sam Hartman asked me to document what I thought these  
> objective criteria were. This is by no means a complete list, but  
> includes:
> 
> - How big is the total state space of the system, and how does it  
> scale with the number of elements participating.
> 
> - How many elements of the system need to change state when a single  
> event occurs (events include boxes going up/down, routes changing, EID  
> prefixes being added/removed, RLOCs being added removed, etc.)
> 
> - How many individual logical elements are involved in each primitive  
> operation of the system (e.g. resolving a MAP request) such that  
> either the operation fails (in the absence of redundancy) or requires  
> high-reliability machinery to provide acceptable availability.
> 
> - How many individual elements need hand configuration to provision  
> and manage the system. How does this scale with the number of sites,  
> service providers, and registries.
> 
> - How many administrative domains are involved in the consistent  
> operation of the system, and how many configuration and policy  
> elements need to be coordinated across those boundaries.
> 
> I would assert that at best these are actually measurable, and at  
> worst can be loosely assessed.
 
 	No disagreement with what you've said here. But taking
 	data points (measurement) or even systematic "loose
 	assessment" is a qualitatively different statement than
 	what I was responding to.
 
 	Dave

---

From: Scott Brim <[email-masked]>
Date: Wed, 25 Mar 2009 10:44:32 -0700

This is all excellent, but there's a criterion missing that I don't
know how to name ... something about the organization of the elements
involved in a change.  If a change propagates hierarchically that's
less complexity than if a change propagates, is reflected back toward
the origin, and elements which have already changed have to change
again until balance is achieved.  In particular I don't think lisp-ms
adds particularly to the _overall_ system complexity because it is
peripheral and a particular change only flows in one direction.

swb

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: David R Oran <[email-masked]>
Date: Wed, 25 Mar 2009 10:21:44 -0700

DaveO.

"Make everything as simple as possible, but not simpler." - Albert  
Einstein.

---

From: David Meyer <[email-masked]>
Date: Wed, 25 Mar 2009 10:25:55 -0700

Dave

---

From: David R Oran <[email-masked]>
Date: Wed, 25 Mar 2009 10:50:23 -0700

> peripheral and a particular change only flows in one direction.
True (of course) but it's a second order effect - trees trade off  
protocol/topology simplicity for single points of failure (each down  
branch) that in turn my require other complexity to ensure robustness  
(e.g. high-reliability or redundant components).

Basically, you can push the complexity around, but at first order if  
the element count is large the complexity increases.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 Mar 2009 19:28:42 -0400

Thanks for your criteria.  I think it will be valuable to include
these in our analysis of LISP.