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

From: "Fergie" <[email-masked]>
Date: Thu, 22 Mar 2007 11:02:59 GMT

-- Eliot Lear <[email-masked]> wrote:

>With the routing and internet areas working on ID/Locator split and the 
security and application areas taking notice, can we please be more 
specific about what problem we think we're solving?
>
>Specifically:
>
>    * Are we concerned about routing table size?  Is there a cache
      limitation? or
    * are we concerned about routing entropy on the wire?  and/or
    * are we concerned about other control plane entropy internal to the
      router associated with routing? or
    * are we concerned about something else?
>
>Please provide data and analysis to support your statement.  A URL is 
sufficient.  If we do not agree that we have enough data and analysis, 
perhaps our next step should be to get the data and do the analysis.  
The lack of data and analysis in this week's presentations was extremely 
disturbing.

Eliot,

So, I didn't attend the RRG meeting on Saturday, but I've seen
Vince's presentation on a couple of occasions:

 http://www1.ietf.org/mail-archive/web/ram/current/msg00747.html

Having said that, and while I cannot personally respond to most of
the issues you mention [above], I do think that _at_least_ this [the
issues outlined by Vince] weighs heavy on many, if not most, Tier-1
ISP's minds.

Not sure if this qualifies as sufficient data & analysis, but...

I'd like to hear more from the ISPs, myself.

$.02,

- ferg

--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/

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

---

From: "Fergie" <[email-masked]>
Date: Thu, 22 Mar 2007 11:02:59 GMT

limitation? or

Eliot,

$.02,

- ferg

---

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