Subject: Re: [RAM] Re: [Int-area] Please be more specific about the problem

From: [email-masked] (Noel Chiappa)
Date: Thu, 22 Mar 2007 09:07:35 -0400 (EDT)

> From: Russ White <[email-masked]>

    > I'm not certain how a loc/id split would "solve" this issue, if this is
    > the issue.... One of the reasons I'd like to see a better problem
    > statement is to better understand the actual problem.

This triggered another design-philosophy thought, if you all will bear with
another one of these....

Asking "how will architectural feature X solve problem Y" is not a useful
question to ask - iff your goal is to ascertain whether X is a good idea. (If
all you're trying to do is solve Y, of course, it is a reasonable question.)

Remember my maxim about great architecture: The test of great architecture is
not how well it does things it was designed to do, but how well it does
things it was never expected to handle. So you can never really evaluate
architecture by asking "does it do the things listed in this requirements
document", or anything like that.

The way to evaluate architectural structures, qua architecture, is to say
"does this somehow encapsulate some essential vision of how things really
are, or ought to be, organized" - think things like stacks and processes,
concepts which now seem not just "obvious and intuitive", but "necessary" -
but weren't when they were first invented. (For a good time, read early
computer designs and see how they did procedure calls - once they understood
what a procedure is, of course - the earlist ones didn't even do that.)

And along that axis, the location/identity split is clearly a good thing,
because at a fundamental level, location and identity are two very different
concepts, and it's clear that having one name for both is just going to be
fundamentally limiting.

And to answer your actual question, IMO the real way to do TE is to support
both traffic aggregates (i.e. collections of packets) and paths as
first-class objects at the internetworking layer. That way, you can say "this
traffic aggregate should take that path" directly, instead of trying to do it
indirectly by fiddling with routing tables (the latter technique being
something I liken to driving a screw by gripping a flat piece of metal with a
pair of vice-grips, because that's the only tool you've got; buy a
screwdriver, dude :-).

The location/identity split is not really germane to handling TE, any more
than, say, queing priorities (another architectural change, albeit a smaller
one). It's just a part of the fundamental 'atmosphere' of networking
concepts, one which is just not on point when doing TE.

What the problems in doing TE *really* are, are a symptom of the
over-simplicity of the architecture of the internetworking layer, and the
routing (path-finding). That simplicity was a Good Thing in trying to do an
initial "test of concept" deployment back in the late 70's, but it's biting
us now. Fixing just one of those shortcomings (conflating identity and
location) is simply not fixing all of them. No single patch to an existing
architecture can do that.

	Noel

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Mar 2007 17:23:19 +0100

> document", or anything like that.

If the answer to the question is:  It does the things listed in this 
requirements document *badly*, then you know that you should not consider the 
architecture further.

If the answer to the question is:  I do not know, then you know the 
architecture will not have near-term utility.

This sounds like a useful, first-stage filter.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Eliot Lear <[email-masked]>
Date: Thu, 22 Mar 2007 18:51:13 +0100

Noel,

An engineering problem has been raised, and while a new architecture can 
be a solution to an engineering problem, I want to understand just how 
far we have to go to fix the engineering problem.  In order to do that I 
have to understand the engineering problem better.  And so I wonder if 
someone can point me to the presentations that were given at the routing 
area so I can see what we're talking about.  Amazingly, in the seven or 
so presentations I've taken on this topic, only one of them had any data 
at all (thank you Tony & Vince) about routing growth, but even it did 
not answer this question:  is our primary concern control plane churn in 
the form of memory bandwidth or memory size?  I've gotten an oral answer 
of "both", but at least some data is needed in order to answer the 
question of what sort of characteristics any mapping from id to loc must 
have.  That was the point that I amongst others tried to make at the 
mike, today.

Which brings me to Bernard's point:

> a. Performance data is often highly dependent on the implementations being 
> studied, and therefore it is often unclear whether the conclusions hold 
> universally. 
>
> b. There are often multiple solutions available to the problem, some of 
> which will perform better than others in given use cases.  Without 
> agreement on the use cases, it can therefore be difficult to agree which 
> solutions are superior, even if the performance data itself is 
> unassailable (which is itself rare). 
Understood, and so if you can tell me what "the problem" is with some 
reason to believe so, I believe we will have gotten over this hurdle.  I 
believe therefore the questions I asked are not beyond the bounds of reason.

Eliot

---

From: Tony Li <[email-masked]>
Date: Thu, 22 Mar 2007 19:15:24 +0100

Eliot,

> is our primary concern control plane churn in the form of memory  
> bandwidth or memory size?

My primary concern at this point is memory latency in the RIB.  You  
should be careful to note the difference between bandwidth and  
latency and it's impact on performance.

Tony

---

From: David Conrad <[email-masked]>
Date: Thu, 22 Mar 2007 11:49:14 -0700

Eliot,

On Mar 22, 2007, at 10:51 AM, Eliot Lear wrote:
> An engineering problem has been raised, and while a new  
> architecture can be a solution to an engineering problem, I want to  
> understand just how far we have to go to fix the engineering problem.

Actually, I think a better description of the situation is that we're  
seeing yet another symptom (or symptoms) of an underlying  
architecture problem and we're looking for yet another engineering  
solution(s) to hack around that architecture problem.

> bandwidth or memory size?  I've gotten an oral answer of "both",

Of course it is both, since the underlying problem is evidenced by  
simple growth.  You get churn because of growth in routing  
announcements (since there are more prefixes to announce) and in  
memory bandwidth because you've got to drag more prefixes out of the  
RIB and memory size because there are more prefixes to store.

The engineering hack (as argued by some) is to throw more/faster/ 
better hardware at the problem and hope we don't run into the laws of  
physics.  I personally think physics is going to win in the end.

Rgds,
-drc

---

From: Peter Sherbin <[email-masked]>
Date: Thu, 22 Mar 2007 14:04:54 -0700 (PDT)

>From ietf-68/ram discussions loc/id split looks like the way people would want to
pursue. Assuming id = name, we have an opportunity to set a naming structure for
everything. Literally give a unique name to each and every thing we know. E.g. use
ASCII for a "bee" = "62:65:65" or "01100010 01100101 01100101".

Catalogs of name hierarchies exist for ages. Why do not formalize it once and for
all via a standard numbering convention.

Thus we will have ions of unique names. And than a few millions or billions of
locators/addresses. Combination Name + Locator = IPv6 source/destination descriptor.

IPv6 has enough room for names. If you think about it IPv6 designers were solving
naming problem rather than the locators' one.

Routing will not change other than a smaller table and removal of NAT. TE and
Multihoming suddenly become non-issues. 

Thanks,

Peter

____________________________________________________________________________________
Food fight? Enjoy some healthy debate 
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367

---

From: Eliot Lear <[email-masked]>
Date: Fri, 23 Mar 2007 11:20:13 +0100

> RIB and memory size because there are more prefixes to store.
Yes, but what are the scaling properties of memory size in terms of 
COGS?  If we don't care we have more options.

Eliot