Subject: Re: (IPng 4984) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard

From: Scott Bradner <[email-masked]>
Date: Mon, 1 Dec 1997 14:58:03 -0500 (EST)

Daniel said:
I have seen some of this discussion.  I am afraid I have seen no
documented discussion revealing the reasoning behind fixing the TLA
length and fixing it at 13 bits.  Frankly I have been surprised by the
sudden speed of the provider based addressing standardisation.  

last year in regards to what is now RFC 2050 I asked the lawyers that
do work for the IESG what restrictions in flexibility we (the IETF) have
in the area of defining rules and technology that restricts ISP practices.
I was told that the only time we can be restrictive is when there is 
no other technically reasonable option - I support Daniel here, if this
field is to be restricted to a specific length then we must have 
very good technical reasons for doing so.

Scott

---

From: [email-masked] (Christian Huitema)
Date: Mon, 1 Dec 1997 15:47:42 -0500 (EST)

Daniel, 

There were two basic arguments for limiting the length of the TLA
prefix:

1) Routing table size.  All TLA have to be in all tables in all 
   defaultless routers.  Thus, the number of TLAs becomes a minorant
   of the size of the tables.

2) Address space size.  The current document only specifies 1/8th
   of the address space.  If it turns out that there is a need for
   many more TLA's in three years, it will actually be possible
   to make some.

The particular value chosen, 13 bits, as only one advantage.  The
combination of format and TLA fits in 16 bits, which provides for easy
writing of routing prefixes.

The point that you note re: allocation practices is, however, perfectly
true.  ISPs should not receive a TLA 'a priori", they should graduate
to it.  If I remeber correctly, an ISP that starts operating in Europe
today receives a /19, and will gradually receive more space as it
connects more customers.  An ISP that starts operating with IPv6 should
receive one or several NLAs from established transit providers; it should
only receive a global entry in the routing tables once it has passed
some "graduation" criteria.

-- 
Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 02 Dec 1997 02:39:00 +0000

Try "The length of the TLA field is fixed at a relatively small size
so as to guarantee that the default-free routing table is
certain not to exceed a size known to be technically feasible."

If that is untrue, then we can't justify the fixed size.

  Brian Carpenter

>-- Scott Bradner wrote:
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------

---

From: "Mike O'Dell" <[email-masked]>
Date: Tue, 02 Dec 1997 07:11:00 -0500

brian's reason is exactly the goal which was in mind:

to bound the maximum complexity of the default-free region
at values believed to be viable with some margin.

the margin is important because even routers normally
though to be "default-free" will probably carry a significant
number of more-specific prefixes for optimizing paths,
both internal to a TLA and between TLAs.

and note, once again, the issue is not the size of the default-free
region, but the complexity of the topology, which determines how
many copies of the full default-free region one must examine before
arriving at the forwarding table with one entry per TLA.

it is now routine to see an announced prefix 15 times via
different paths, only one of which must be selected for use.
the complexity of the topology is only expected to increase,
both internally and externally, so it is not unreasonable to
attempt to bound the size of the set as that is the only 
parameter which is in any sense "tunable".

as for 13 - anything smaller was felt to be clearly too small,
and it becomes harder and harder to argue for bigger numbers
in light of the complexity management which is mandatory.

if anyone expects a magic formula which says "13" and not something
else, you won't get it.  what is very clear is that it is pretty
easy for it to to "too big", and then it eats into the other
topology bits which have their own set of long arguments.
would 14 work - certainly.  

Like everything else, 13 is an engineering compromise - chosen
to balance one set of considerations against a bunch of others,
and after ruminating over it a long time, the consensus was
13 was the best choice.

and as someone else pointed out, the TLA space can be expanded
laterally into other reserved areas, so there are more available.

now, to look at things from a different vantage point....

I think one deep issue here is that the IPv6 address design, in
some sense, appears to threaten the existing registries.  the design
assumes that each TLA act as a registry for its region of the address
space, leaving the registries to only allocate TLAs, which will be
infrequent.

just so.

but given the work required to run a registry, existing registries with
good track records would be in an excellent position to compete for the
right to provide registration services for *any* TLA or delegation within
a TLA, not just ones they assigned.  

this is a natural fall-out of attempting to provide an addressing structure
which can pave the way for making the network self-organizing.  if that
were really the case, unlike today, there would be little need for
registry organizations (little - not "no", but little) which use humans
clerical workers to execute a simple resource allocation algorithm for the
world's largest distributed computer.

	-mo

---

From: [email-masked]
Date: Tue, 2 Dec 1997 04:48:36 -0800 (PST)

Before we wander too far down this path, there was a very interesting
paper at the last sigcom in which the authors managed to shrink the
size of the then current routing table (~40k routes) into less than 
200K of memory.

In short, I differ from Mike in that my values for "believed to be viable"
differ, apparently wildly, from his and brians.  I'm unconvinced that
this will remain a true, long term technological argument. I'd like to
see something besides, "too hard with 1990's technologies".  "Long time"
ought to have a better spec than say, Internet Dog Years?

-- 
--bill

---

From: "Mike O'Dell" <[email-masked]>
Date: Tue, 02 Dec 1997 09:12:49 -0500

bill,  

i'm surprised by your remark.
i thought you have been around long enough to understand this.
we've been over all this before.

	the problem is not now, nor has it ever been,
	the size of the forwarding table  measured in any unit -
	routes, bytes, feet, or kilograms.

(yes, there have been a few episodes where gross inadequacies of popular
hardware created *serious* tactical headaches, but don't confuse that
with the underlying problem.)

the fundamental problem is the complexity of the computation which produces
the forwarding table from many, many of copies various subsets of the
global routing information.

the complexity of that computation is driven by two things - 
the cardinality of the set of visible nodes in the global topology graph,
and the complexity of the topology connecting those nodes.  
(note that "node" here does not imply a router but whole networks).

of these two things, we cannot readily control the edge topology of the
graph, so we are only left with controlling the cardinality of the node set of
the graph if we wish to influence that complexity.

of course, you can argue that we don't need to care about the problem - 
that somehow processors will keep getting fast enough fast enough to
retain reasonable convergence times.

but then you are betting on a race between two exponentials -
and are making the bet that the smaller exponent will win.    

i know *i* don't want to wager the future on that bet.

	-mo

---

From: [email-masked]
Date: Tue, 2 Dec 1997 07:08:28 -0800 (PST)

> i know *i* don't want to wager the future on that bet.

My argument is that the basic premise that the assumptions wrt the
cardinality of the set of visable nodes in the topology graph
-may- be wrong.  Other than that, I agree with you.  Chalk it up
to a fit of Noel-Stev syndrome. With a bit of rest, I'm sure
it will pass.  (and I do recommend "Small Forwarding Tables for
Fast Routing Lookup" from SigCom'97, which is one more reason why
I think these arguments just might be off)

-- 
--bill

---

From: [email-masked] (Christian Huitema)
Date: Tue, 2 Dec 1997 10:28:16 -0500 (EST)

> ought to have a better spec than say, Internet Dog Years?

Bill,

What you say is true.  Technology is going to progress, and at some point
in the future we may convince ourselves that we can safely handle
1,000,000 TLAs instead of 10,000.  However:

1) We are not there yet.  Andrew Brodnik et al demonstrated that one can
   efficiently compress today's routing tables in the cache of a Pentium
   chip.  But their algorithm has yet to be implemented in commercial
   routers.

2) There is more to scaling than routers' caches.  Compressing the tables
   in cache memory mainly allows you to switch packets faster than if your
   tables were kept in a slow RAM.  It does not reduce route flaps, or
   the complexity of the topology.

3) In any case, we are taking decision today based on today's technology.
   As I pointed out, there is plenty of address space reserved for further
   use.  If the technology does evolve, then it will be time to open
   more space.

In short, limiting the size of TLA to 13 bits looks like a reasonable cut,
today.

-- 
Christian Huitema

---

From: "Mike O'Dell" <[email-masked]>
Date: Tue, 02 Dec 1997 10:31:43 -0500

i've read Pink, et al.

it has to do with quick forwarding, not the computation which
decides what goes in the forwarding table given all the possibilities
to chose from. (longest match covering, AS path selection, etc, etc, etc)

and i would love to be wrong - but even being wrong by a lot doesn't change
the number of bits by a large amount given the way the size participates
in the compuations.

	-mo

---

From: [email-masked]
Date: Tue, 2 Dec 1997 07:46:51 -0800 (PST)

>    chip.  But their algorithm has yet to be implemented in commercial

	True.  But how far off can that be? :)

>    the complexity of the topology.

	One of the interesting side effects from the paper is the construct
	that appears to allow the creation of a true default free router
	i.e. one that has the ability to carry the total IPv4 space as
	host routes.  

	a 13bit TLA does not reduce route flap nor moderate the complexity
	of the topology, which appear to have moved into the critical path.

	a 13bit TLA does give some breathing room by sanctioning a level
	of proxy aggregation. This method allows ISPs to lie to each
	other about the stability of their internal infrastructure, which
	is the current model for reducing the dynamics of the routing system.
	(Is it just me or is there really a joke being perpetrated by
	the attempts to present a stable routing infrastructure with dynamic
	routing protocols? :)

>    use.  If the technology does evolve, then it will be time to open

	Fine.  Then this might be best served as a BCP and not standards
	track?  Or are the concerns rasied by everyone but me strong
	enough to push this into the standards track?  What I find interesting
	is that this particular addressing scheme has had less field time
	than the previous addressing scheme.  Will there be yet another
	scheme fall out of the woodwork?  Is there a reason why these 
	schemes can't co-exist?  
	
	And I'm not sure that the extra space will be available. Are you?

> In short, limiting the size of TLA to 13 bits looks like a reasonable cut,

	Ok.  I just thought I'd say my piece.  

-- 
--bill

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 02 Dec 1997 13:03:19 -0600

Remember the mantra we've all been chanting ever since Palo Alto:
"It's not the size of the forwarding table; it's the amount of
computation it takes to produce it."

---

From: [email-masked]
Date: Thu, 04 Dec 1997 11:40:09 -0500

>In short, limiting the size of TLA to 13 bits looks like a reasonable cut,

I want to add that for the TLA and AAAA record discussion I see nothing
wrong with having a stage 1 solution and then stage 2 and we create the
backwards compatibility as implementors.  

I realize we need to provide the best solution for dynamic addressing
and for ISPs.  But right now real customers want IPv6 on "Intranets", or
private enterprises.  We will see several products this year and
customers will be able to start deploying IPv6 from vendors.  Many
customers do not want to move to private addresses and a total v4 NAT
solution who need addresses today.  They want to move to IPv6 and have a
plan to participate on the Internet even before the ISPs start supporting 
their needs for IPv6.  I will also say that Europe and Asia appear to be
moving much faster than the U.S. ISPs to be IPv6 ready.

The point of this mail is that we implementors of IPv6 can absorb
updates to the Address Architecture and AAAA records and we have changed
the addr arch twice and once enough where we updated our code on the
6bone, and are using the new specs.  The implementors will do the
changes we develop and that should not be a fear of anyone IMO.

The essential architecture of IPv6 is done and most of us have our code
base prep'd to support the evolutionary IPv6 fine tuning by this working
group.  It is not difficult to move forward here with changes.  

One of the things that has always driven the IETF processes is the
"market".  There is now a market for IPv6 and they want it right now.
We need to give it to them as vendors, and I hope we view that need in
our deliberations.

Also we have some new players at the UNH bake-off this week and one of
them is Microsoft.  This is really good.

/jim