Subject: [arch-d] It's the routing, people!

From: [email-masked] (Noel Chiappa)
Date: Sat, 11 Nov 2006 11:00:00 -0500 (EST)

Some years ago, in one U.S. campaign there was a slogan "It's the economy,
stupid!". I would like to paraphrase that here, to focus the discussion on
what's important.

We're here primarily because there's a routing problem - i.e. the routing is
going to melt down. That's the problem people are trying to solve. So, "It's
the routing, people!" In other words, the first order of business ought to be
trying to figure out how the routing is going to work.

Designing addresses is kind of fun, but it's also "looking for keys under the
streetlight" (in the words of the old joke). May I remind people that *we are
here now precisely because people designed addresses (IPv6), instead of
figuring out how the routing is going to work*.

I'm somewhat disheartened that the IETF, like the Bourbons (in Talleyrand's
famous phrase), has seemingly learned nothing, and forgotten nothing.
(There's also a military maxim about "amateurs study tactics, professionals
study logistics" - I'll leave it to you all to work out how I'd modify that
for us.)

So, until we have figured out how the routing is going to work, can we please
table *all* discussion of what the addresses are going to look like? Thank
you.

	Noel

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Fred Baker <[email-masked]>
Date: Sat, 11 Nov 2006 08:58:46 -0800

On Nov 11, 2006, at 8:00 AM, Noel Chiappa wrote:
> until we have figured out how the routing is going to work, can we  
> please table *all* discussion of what the addresses are going to  
> look like?

I'll support you in this; you note my comments on routing in response  
to a particular address proposal this morning.

That said, if you want to redefine routing, we need a proposal on the  
table, and we are in fact on a fairly constrained timeline. Are you  
asking us to reset to the rambling discussions of 1992 and presume  
that the current crunch will not actually happen until 20 years hence?

---

From: Geoff Huston <[email-masked]>
Date: Sun, 12 Nov 2006 04:12:50 +1100

Noel,

Each of us has various ways of thinking about a space and various 
ways on conceptualizing the nature of the issues with such a space. 
While its pretty clear what works for you when you turn the 
considerations into symbols and start to move them around, others of 
us have different ways of conceptualizing the space, and indeed have 
different problem priorities.

I don't see routing melting today. Today I see a class of FIB 
implementations coming close to a current design limit. I don't 
necessarily accept that FIB meltdown is only prevented by changing 
the routing paradigm, as I still don't accept that FIB = RIB. I see 
that if per packet performance is critical, and that appears to be 
the case, then the lookup performed per packet should be fast. But I 
don't accept that this necessarily implies that you have to perform 
this lookup over the equivalent of the RIB stuffed into a fast lookup 
data structure to derive an answer that is of the same order as the 
number of physical egress choices on the box.

I suspect that a better understanding of the semantics of addresses, 
and the distinction, even in a constrained routing world about what 
are the characteristics of the packet's source and destination tag, 
and the relationship of these two tags to the forwarding path across 
the network are useful in understanding the relationship to the 
problem being presented here and the degrees of freedom in the symbol 
space that we can manipulate to provide mitigation, both in the short 
and long term. So I interpret your request to table all consideration 
on the semantics of an address at the routing level as being unwise 
and overly tactical (yes, "tactical" as in the full sense of the 
quote you provided below).

regards,

    Geoff

As a postscript to this note, having lived in the IETF  for so long, 
I may be ignorant amateur in full conformance with the comment in 
your note, but frankly, I really didn't need you to point this out 
Noel! Either I knew that already, in which case your repetition of 
the accusation is unhelpful and uninformative, or I didn't, in which 
case the accusation alone is entirely unconvincing to me!

---

From: John Day <[email-masked]>
Date: Sat, 11 Nov 2006 12:21:17 -0500

Then the addresses should simply be labels.  Not true.  If the 
addresses are suppose to be location-dependent, that location 
dependence is relative to the *topology* of the network.  Think in 
terms of how location-dependence should be represented relative to 
the graph of the network.

The nature of the address space is as important as the routes.  They 
actually influence each other to some degree.

You are concentrating on the arithmetic, when you need to be looking 
at the algebra.

I agree with you that v6 did not do this.  But then what did you 
expect. I have yet to see any proposals on this list that do it. But 
they are possible.  If you don't get the two things working together, 
you won't get a solution that scales.  That much I can pretty much 
guarantee.

Take care,
john

---

From: John Leslie <[email-masked]>
Date: Sat, 11 Nov 2006 12:34:31 -0500

Noel Chiappa <[email-masked]> wrote:
> 
> We're here primarily because there's a routing problem - i.e. the
> routing is going to melt down. That's the problem people are trying
> to solve. So, "It's the routing, people!" In other words, the first
> order of business ought to be trying to figure out how the routing
> is going to work.

   I'm not sure "order of business" applies on mailing lists, but I
quite agree we'd be better off with some consensus on what we _want_
the routing to look like.

> Designing addresses is kind of fun, but it's also "looking for keys
> under the streetlight" (in the words of the old joke). May I remind
> people that *we are here now precisely because people designed
> addresses (IPv6), instead of figuring out how the routing is going
> to work*.

   I'd say we're here because the folks designing IPv6 addresses were
chartered to leave "routing" questions to some other group.

> I'm somewhat disheartened that the IETF, like the Bourbons (in
> Talleyrand's famous phrase), has seemingly learned nothing, and
> forgotten nothing...

   :^)

> So, until we have figured out how the routing is going to work, can
> we please table *all* discussion of what the addresses are going to
> look like?

   Personally, I'd be glad to. (I doubt it'll work though...)

   But could you humor me, and try to reach some agreement about what
we mean by

- "address",
- "locator",
- "identifier", and
- "name" ?

--
John Leslie <[email-masked]>

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 12 Nov 2006 04:34:49 -0500

I question this unless the IAB processes wants to agree to this.  It was
stated at the plenary it is an address and routing problem.  Thus it is
on the table as we proceed with the discussion.  The IAB meeting is the
driver for this work and I will assume it will become more formalized
than a random set of opinions on our general architecture list as was
stated Thursday night at the plenary.

Would IAB rep like to comment and clarify?

Best,

/jim 

> -----Original Message-----
> From: Noel Chiappa [mailto:[email-masked]] 
> Sent: Saturday, November 11, 2006 11:00 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [arch-d] It's the routing, people!
> 
> Some years ago, in one U.S. campaign there was a slogan "It's 
> the economy, stupid!". I would like to paraphrase that here, 
> to focus the discussion on what's important.
> 
> We're here primarily because there's a routing problem - i.e. 
> the routing is going to melt down. That's the problem people 
> are trying to solve. So, "It's the routing, people!" In other 
> words, the first order of business ought to be trying to 
> figure out how the routing is going to work.
> 
> Designing addresses is kind of fun, but it's also "looking 
> for keys under the streetlight" (in the words of the old 
> joke). May I remind people that *we are here now precisely 
> because people designed addresses (IPv6), instead of figuring 
> out how the routing is going to work*.
> 
> I'm somewhat disheartened that the IETF, likFrom [email-masked] Sun Nov 12 04:38:46 2006
Content-class: urn:content-classes:message
Subject: RE: [arch-d] It's the routing, people!
Date: Sun, 12 Nov 2006 04:34:49 -0500
From: "Bound, Jim" <[email-masked]>
To: "Noel Chiappa" <[email-masked]>, <[email-masked]>
Cc: 

I question this unless the IAB processes wants to agree to this.  It was
stated at the plenary it is an address and routing problem.  Thus it is
on the table as we proceed with the discussion.  The IAB meeting is the
driver for this work and I will assume it will become more formalized
than a random set of opinions on our general architecture list as was
stated Thursday night at the plenary.

Would IAB rep like to comment and clarify?

Best,

/jim 

> -----Original Message-----
> From: Noel Chiappa [mailto:[email-masked]] 
> Sent: Saturday, November 11, 2006 11:00 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [arch-d] It's the routing, people!
> 
> Some years ago, in one U.S. campaign there was a slogan "It's 
> the economy, stupid!". I would like to paraphrase that here, 
> to focus the discussion on what's important.
> 
> We're here primarily because there's a routing problem - i.e. 
> the routing is going to melt down. That's the problem people 
> are trying to solve. So, "It's the routing, people!" In other 
> words, the first order of business ought to be trying to 
> figure out how the routing is going to work.
> 
> Designing addresses is kind of fun, but it's also "looking 
> for keys under the streetlight" (in the words of the old 
> joke). May I remind people that *we are here now precisely 
> because people designed addresses (IPv6), instead of figuring 
> out how the routing is going to work*.
> 
> I'm somewhat disheartened that the IETF, like the Bourbons 
> (in Talleyrand's famous phrase), has seemingly learned 
> nothing, and forgotten nothing.
> (There's also a military maxim about "amateurs study tactics, 
> professionals study logistics" - I'll leave it to you all to 
> work out how I'd modify that for us.)
> 
> So, until we have figured out how the routing is going to 
> work, can we please table *all* discussion of what the 
> addresses are going to look like? Thank you.
> 
> 	Noel
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 12 Nov 2006 04:37:10 -0500

IPv6 did not do this or not do this it provided an address space.  What
we may or may not do with it moving foward is part of the TBD address
discussion.  

Best,
/jim 

> From: John Day [mailto:[email-masked]] 
> Sent: Saturday, November 11, 2006 12:21 PM
> To: Noel Chiappa; [email-masked]
> Subject: Re: [arch-d] It's the routing, people!
> 
> Then the addresses should simply be labels.  Not true.  If 
> the addresses are suppose to be location-dependent, that 
> location dependence is relative to the *topology* of the 
> network.  Think in terms of how location-dee the Bourbons

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 12 Nov 2006 04:37:10 -0500

Best,
/jim 

> network.  Think in terms of how location-dependence should be 
> represented relative to the graph of the network.
> 
> The nature of the address space is as important as the 
> routes.  They actually influence each other to some degree.
> 
> You are concentrating on the arithmetic, when you need to be 
> looking at the algebra.
> 
> I agree with you that v6 did not do this.  But then what did 
> you expect. I have yet to see any proposals on this list that 
> do it. But they are possible.  If you don't get the two 
> things working together, you won't get a solution that 
> scales.  That much I can pretty much guarantee.
> 
> Take care,
> john
> 
> >Some years ago, in one U.S. campaign there was a slogan "It's the 
> >economy, stupid!". I would like to paraphrase that here, to 
> focus the 
> >discussion on what's important.
> >
> >routing is going to melt down. That's the problem people are 
> trying to 
> >solve. So, "It's the routing, people!" In other words, the 
> first order 
> >of business ought to be trying to figure out how the routing 
> is going to work.
> >
> >addresses (IPv6), instead of figuring out how the routing is 
> going to work*.
> >
> >Talleyrand's famous phrase), has seemingly learned nothing, 
> and forgotten nothing.
> work, can we 
> >please table *all* discussion of what the addresses are 
> going to look 
> >like? Thank you.
> >
> >	Noel
> >

pendence should be 
> represented relative to the graph of the network.
> 
> The nature of the address space is as important as the 
> routes.  They actually influence each other to some degree.
> 
> You are concentrating on the arithmetic, when you need to be 
> looking at the algebra.
> 
> I agree with you that v6 did not do this.  But then what did 
> you expect. I have yet to see any proposals on this list that 
> do it. But they are possible.  If you don't get the two 
> things working together, you won't get a solution that 
> scales.  That much I can pretty much guarantee.
> 
> Take care,
> john
> 
> >Some years ago, in one U.S. campaign there was a slogan "It's the 
> >economy, stupid!". I would like to paraphrase that here, to 
> focus the 
> >discussion on what's important.
> >
> >routing is going to melt down. That's the problem people are 
> trying to 
> >solve. So, "It's the routing, people!" In other words, the 
> first order 
> >of business ought to be trying to figure out how the routing 
> is going to work.
> >
> >addresses (IPv6), instead of figuring out how the routing is 
> going to work*.
> >
> >Talleyrand's famous phrase), has seemingly learned nothing, 
> and forgotten nothing.
> work, can we 
> >please table *all* discussion of what the addresses are 
> going to look 
> >like? Thank you.
> >
> >	Noel
> >

---

From: David Meyer <[email-masked]>
Date: Sun, 12 Nov 2006 12:43:03 -0800

> Would IAB rep like to comment and clarify?

	Speaking as an individual, what I can say is that someone
	got up during Leslie's "what's next" part and said
	addressing should come before routing. I didn't
	necessarily agree, but that's all I heard.

	--dmm

---

From: Peter Sherbin <[email-masked]>
Date: Sun, 12 Nov 2006 15:02:45 -0800 (PST)

> > out how the routing is going to work*.

We can design routing to route anything. The fundamental part is to figure out what
is that thing. No one knows exactly because people are building and learning the
Internet at the same time. We learn by modeling. Any sound model starts with
assumptions. For the Internet assumptions will turn into requirements.

We live in a world where consumers want a choice between competing providers to send
the data. Data belong to a consumer. Communicating via IP requires addresses. Hence
the very basic assumption is how to manage addresses. Unavoidably address management
touches social, economical and political reality of the planet. When address
management is established routing becomes a straightforward engineering exercise.

Thanks,

PS

> > addresses are going to look like? Thank you.

____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

---

From: John Leslie <[email-masked]>
Date: Mon, 13 Nov 2006 12:27:54 -0500

Geoff Huston <[email-masked]> wrote:
> implementations coming close to a current design limit.

   My understanding of the situation is that the expected "meltdown"
is a matter of recalculating "best route" as routes are added and
withdrawn too quickly -- not a matter of having "too many" routes.

   Thus, "FIB implementations" "coming close" etc. confuses me.

   The today-standard _forwarding_ algorhithm of matching closest
enclosing prefix-length, as I understand it, is in no danger of
meltdown. The "meltdown" is in analyzing RIB information to find
a new "best route" (which must be done before any updates can be
propagated).

   (There may be some routers in or near the backbone which can't
forward all their packets at wire speed because the forwarding
table is "too big"; but that is neither a "mestdown" nor what
routing experts would call "routing".)

> I don't necessarily accept that FIB meltdown is only prevented by
> changing the routing paradigm, as I still don't accept that
> FIB = RIB.

   Forwarding Information Base _isn't_ the same as Routing Information
Base. Period.

   Nor is changing the routing paradigm an appropriate "fix" for
routers which can't forward at wire speed. Period.

> I see that if per packet performance is critical, and that appears
> to be the case,

   (which, BTW, is engineering, not architecture...)

> then the lookup performed per packet should be fast.

   Agreed.

> But I don't accept that this necessarily implies that you have to
> perform this lookup over the equivalent of the RIB stuffed into a
> fast lookup data structure to derive an answer that is of the same
> order as the number of physical egress choices on the box.

   Nor should you. Not merely is this engineering, not architecture:
it is _bad_ engineering!

> problem being presented here

   I'm going to take a chance here, and introduce a layering paradigm
which I find helpful in understanding this _architecturally_.

   We all understand, I hope the concept of a layer I'll call
"internetworking" (commonly called OSI "network" layer, but I'll
avoid that because of all the expectations it has accumulated).
This layer allows packets on one network to be forwarded across
other networks to (usually) reach their destinations on a final
network. To accomplish this the destination provides an address
in "internetworking" space which has a consistent meaning as to
what final network a packet addressed to it should reach.

   (It also has information about what host on that network it
should reach, but that should be considered meaningful _only_ to
the destination network.)

   This "internetworking address" does _not_ contain information
on how to get to the destination (except in the trivial case where
you're already on the destination network).

   How to get there is commonly called "routing". It's a matter
of finding a network "closer" to the destination and forwarding
it to that network. What routing gurus call "routing" is somewhat
different: it's any workable scheme to make sure that in the
mythical "steady state" _every_ router will have a consistent view
of what is "closer". Otherwise, packets can get stuck in loops,
never reaching their destinations and clogging the forwarding
paths so that other traffic crawls to a standstill.

   Let's stop there: the "internetworking" layer is designed to
"usually" work "in the steady state".

> and the degrees of freedom in the symbol space that we can manipulate
> to provide mitigation, both in the short and long term.

   I'll get around to that later.

> So I interpret your request to table all consideration on the
> semantics of an address at the routing level as being unwise 

   Note the "at the routing level"...

>> professionals study logistics" - I'll leave it to you all to work
>> out how I'd modify that for us.)

   Those "professionals" know you need the right things in the right
places at the right time before "tactics" can be applied.

>> So, until we have figured out how the routing is going to work,
>> can we please table *all* discussion of what the addresses are
>> going to look like? Thank you.

   Routing-as-we-know-it will (to repeat myself)
"
" "usually" work "in the steady state".

And should consider as an opaque string any part of any address it
ebcounters which it can't use for forwarding from network to network.

   This, IMHO, is good.

   YMMV... Feel free to propose an alternative routing scheme...

   Meanwhile, let me return to architectural layers.

   My next layer I call "transport". I think of this as close enough
to OSI layer 4 that there shouldn't be confusion... YMMV...

   My "transport" layer worries mostly about reliability. Thus, it
should detect the loss of packets and deal with it; and it should
detect corruption of packets and deal with it.

   That bears repeating: my "transport" layer should detect the loss
of packets and deal with it; and it should detect corruption of
packets and deal with it.

   We're not in 1970 anymore. We have better ways of dealing with
loss or corruption than blind retransmission.

   The only other function of my "transport" layer I will cover here
is congestion management. This isn't really even an "other" function,
but it would seem to overlap with a congestion control issue at my
"internetworking" layer.

   At the "transport" layer, you want to maximize utility. Usually
this means maximize reliable throughput. In an ideal internetwork,
there will be multiple paths. My "transport" layer, therefore,
should be able to recognize congestion along one path and shift
some traffic to another path.

   The "internetworking" layer, IMHO, should be able to report that
it is experiencing congestion on a route. This should not change
forwarding unless the congestion is severe enough to disincent the
use of that route. (Conceptually, this is very similar to a short
outage.)

   Enough for one post!

---

From: Jefsey_Morfin <[email-masked]>
Date: Mon, 13 Nov 2006 19:12:59 +0100

>places at the right time before "tactics" can be applied.

I am afraid that knowing is not enough. Making sure is the issue.
The whole issue is not knowing how it could work, but that it works.
There are different ways which could work. Priority is to work out 
the one which will deliver.

When something is to be done, an amateur accepts it is badly done, a 
professional demands it is well done. The first solution will work 
the same but it will not scale.

What you eventually document is the need for dynamic routing. Due to 
the network size this is not possible unless the addressing builds 
the topology. Question is: has the network system gained the 
necessary maturity, or is it still in a deployment phase where 
topology commands addressing?

jfc

---

From: Geoff Huston <[email-masked]>
Date: Tue, 14 Nov 2006 05:58:29 +1100

>withdrawn too quickly -- not a matter of having "too many" routes.

This sounds like a different story to me. The one that I heard Tony 
Li tell the Routing and Addressing the workshop was based 
on  per-packet FIB lookup and the price performance of the chipsets 
that perform such lookups in the face of further scaling of the FIB 
and potential increases in packet rates. I've not heard the issue of 
recalculation of "best routers" as being critical until your note. Do 
you have any references for this that I (and other interested folk on 
this list)  could follow up and read on?

>    Thus, "FIB implementations" "coming close" etc. confuses me.

As I noted above, what you have describe above appears to be a 
different issue.  If that's the case then its little wonder that 
there is some confusion here!

>a new "best route" (which must be done before any updates can be

I'm sorry, but I can't follow this - the RIB passes are by no means 
done in "per packet forwarding time", indeed there is no a priori 
pre-set time in which the RIB pass need be performed in any case. You 
can use "plain" old memory for the RIB and use "plain" old (well not 
too old please!) processors for the RIB pass and nothing breaks as 
far as I am aware. Neither of these are critical in terms of price 
performance and are not, at least as I understand it, critical issues 
in router hardware. (No, I don't build routers, not even at home, so 
I obviously don't have a clue what I'm talking about! :-))

>routing experts would call "routing".)

If the forwarding plane can't scale in performance terms and can't 
continue to deliver per packet unit cost reductions in switching 
then, yes, from my perspective I find myself in agreement with the 
prognosis of Tony Li when he observes that that we appear to have a 
fundamental routing and addressing problem.

>    Forwarding Information Base _isn't_ the same as Routing Information

Well these days in the implementations of router systems I'm aware of 
the FIB appears to be the much the same size as the RIB and share the 
same dynamic properties as the RIB, and contain similar information 
to the RIB. So if it quacks like a duck, walks like a duck and swims 
like a duck then it must be an elephant? right? :-)

>routers which can't forward at wire speed. Period.

Apparently we differ in perspective here. Period.

>    (which, BTW, is engineering, not architecture...)

At this stage we appear to be lost in a forest of semantic 
distinctions, none of them appear to me to be overly useful to assist 
in creating an analytic taxonomy! :-)

cheers,

    Geoff