Subject: RE: [arch-d] Re: Notes From Monday Nights Meeting

From: [email-masked] (Noel Chiappa)
Date: Wed, 8 Nov 2006 21:24:18 -0500 (EST)

> From: "Schliesser, Benson" <[email-masked]>

    > do we think it's possible, even with the weight of these concerns, to
    > change the course of IPv6 at this point and still alleviate address
    > exhaustion in time? 

Look, the IPv4 ran out of addresses a decade ago (or more, I can't be bothered
to work it out). NAT boxes exist in large part because of the unavailability
of IPv4 address space (and in part to insulate sites from addressing changes,
but I'll get to that in a second). A different kind of "running out of IPv4
addresses" is approaching, but the market will find a way to muddle through
that one too (probably a market in IPv4 address space, as well as more NAT
boxes), just as they decided that IPv4+NAT, ugly and imperfect as it was, was
more cost-effective than an IPv6 transition.

    > I'd rather have an imperfect routing system than face disruption from
    > critical resource exhaustion.

If the routing tables blow up, it won't matter how big the addresses in the
packets are.

    > we should continue to encourage IPv6 deployment and plan to use it as a
    > locator when we settle on the ID protocol some day. After all, it does
    > solve some large and relatively short-term problems.

It's precisely because IPv6 does not, in fact, solve any decent number of real
problems (see comment about about insulating sites from address changes when
e.g. changing ISP's, and the current discussion about multihoming, etc, etc,
etc, etc) that it has spent over a decade hanging around without any real
progress in terms of actual deployment. Until the IETF faces the reality,
which is that customers aren't buying the IPv6 KoolAid, and makes radical
changes to it to actually make it worthwhile, that state of affairs will
continue.

It's deeply ironic that the ID/location split, which the original IPv6
architect(s) fought bitterly against, could have been a major selling point
for IPv6. A more advanced routing architecture (hell, any different routing
architecture) would have helped too. Oh well, water under the bridge.

	Noel

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

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 9 Nov 2006 08:54:31 +0200

On Nov 9, 2006, at 4:24, Noel Chiappa wrote:
> Until the IETF faces the reality,

This brought to my mind something that I read recently.

In the systems theory or systems dynamics, there is a behavioural  
pattern called "Shifting the Burden".  That pattern has been known  
for at least a decade, probably much longer; I'm sure some of you  
must be familiar with it.  I just haven't happened to be aware of the  
results the systems theory people have.  Anyway, here are a couple of  
articles that explain the pattern:

http://www.systems-thinking.org/theWay/ssb/sb.htm
http://www.worldtrans.org/essay/shiftingburden.html

Looking at the pattern, to me it looks pretty clear that the IETF has  
been stuck to the "symptomatic solution", failing to address the more  
fundamental problems, thereby allowing the side effects to  
accumulate.  Yes, that in itself is nothing new; it has been argued  
several times with different terms.  What was new to me is that the  
behaviour that we are seeing is common to human beings and human  
organisations, and well known in the systems theory.

What is perhaps more worrisome, at least to me, is that the "shifting  
of burden" pattern easily leads to an "addiction" pattern, where  
there becomes a dependency to the symptomatic behaviour pattern that  
further inhibits the fundamental solution; see:

http://www.systems-thinking.org/theWay/sad/ad.htm

According to systems theory, such an addiction "make the real source  
of the problem, in time, even more difficult to resolve."

Sad.

--Pekka Nikander

---

From: John Day <[email-masked]>
Date: Thu, 9 Nov 2006 08:18:06 -0500

Thank you.  I was tied up yesterday and was going to respond to the 
discussion going to say:

Stop!  Please stop this right now.  We don't need yet another patch. 
We have been avoiding fundamentally resolving anything for the past 
30 years.  We are long past needing solutions.  The constant patching 
is doing far more harm than good.

People try to rationalize it as "small incremental change."  Small 
incremental change can work, IF there is a goal.  If each change is 
progress toward that goal.  There is none here.  The only goal is 
make the pain go away for now.  Incremental change here bears more 
resemblance to evolution than to science and engineering.  Before 
many of you say yes, we want things to evolve, this is good, Remember 
in evolution 95% of all species go extinct because their sequence of 
changes leads to a dead end.  For evolution, this doesn't matter 
there are millions of species all trying different paths.  Life goes 
on.  We only have one.  Which means there is a high probability we 
are already fairly far down a dead end path.  The IETF is doing an 
imitation of the Faber Marching Band.

But we have to quit entertaining patches.  Yes, we can come up with 
ways to "make it work."  Actually that is fairly easy.  But they 
don't contribute to reaching a desired end state.  In fact, we don't 
really know where each of them takes us and it is probably deeper 
into the woods. Remember the advice if you are lost in the woods. 
Stay put and let people find you!  Don't wander off aimlessly.  We 
need to establish what the solutions are and the steps we take to get 
there.

There is more bad news.  It is virtually impossible for organizations 
to change culture.  This is well known for corporate organizations. 
It is even harder in committees where power is bottom up not top 
down.  Not only is it hard to change the mind set, but there is too 
much vested interest in the status quo to allow a successful change. 
I am afraid the IETF may have become the new bell heads.

Sorry to be on such a downer this morning.

Take care,
John

At 8:54 +0200 2006/11/09, Pekka Nikander wrote:
>must be familiar with it.  I just haven't happened to be aware of 
>the results the systems theory people have.  Anyway, here are a 
>couple of articles that explain the pattern:
>
>Looking at the pattern, to me it looks pretty clear that the IETF 
>has been stuck to the "symptomatic solution", failing to address the 
>more fundamental problems, thereby allowing the side effects to 
>What is perhaps more worrisome, at least to me, is that the 
>"shifting of burden" pattern easily leads to an "addiction" pattern, 
>where there becomes a dependency to the symptomatic behaviour 
>pattern that further inhibits the fundamental solution; see:
>

---

From: Fred Baker <[email-masked]>
Date: Thu, 9 Nov 2006 08:07:39 -0800

Guys, maybe we should set up a different list for this discussion.  
I'm sure it's a very interesting and important discussion for the  
IETF to have about itself.

That said, we have cycles for one thing. We can navel-gaze and wonder  
whether we need a counsellor, or we can go solve the IPv6 addressing  
problem. This list is for technical discussions, and right now we  
really need to be thinking about the technical topic.

Please?

On Nov 8, 2006, at 10:54 PM, Pekka Nikander wrote:

> has been stuck to the "symptomatic solution", failing to address  
> the more fundamental problems, thereby allowing the side effects to  
> "shifting of burden" pattern easily leads to an "addiction"  
> pattern, where there becomes a dependency to the symptomatic  
> behaviour pattern that further inhibits the fundamental solution; see:
>
> According to systems theory, such an addiction "make the real  
> source of the problem, in time, even more difficult to resolve."
>
> Sad.
>
> --Pekka Nikander
>
>

---

From: "Schliesser, Benson" <[email-masked]>
Date: Thu, 9 Nov 2006 10:20:06 -0600

Noel Chiappa [mailto:[email-masked]] wrote:
> A different kind of "running out of IPv4
> addresses" is approaching, but the market will find a way to muddle
> through that one too (probably a market in IPv4 address space,
> as well as more NAT boxes)

Or perhaps the market will muddle through by using IPv6, imperfect as it
may be.

> changes to it to actually make it worthwhile, that state of affairs
will

I don't want to give the impression that radical changes are
undesirable. Quite the opposite, I fully endorse ongoing work towards a
complete architecture. (this seems almost silly to say, it's so
obviously needed)
My contention is that in a sense we've missed an opportunity, and
delaying a solution to our impending crisis so that we can use the
crisis to motivate further change is risky.

This feels like feature-creep to me, when the business really needs us
to just ship a product. That is, unless shipping the product would lead
to massive recalls etc, but I haven't heard any real argument to that
end yet.

Cheers,
-Benson

---

From: "Schliesser, Benson" <[email-masked]>
Date: Thu, 9 Nov 2006 10:27:40 -0600

John Day [mailto:[email-masked]] wrote:
> there is a high probability we are already fairly far down a dead
> end path.
> [...]
> Remember the advice if you are lost in the woods.
> Stay put and let people find you!  Don't wander off aimlessly.

Except there is a bear marching toward us, and while getting out of the
woods is the goal getting away from the bear is the imperative.

Of course as you point out, if we run away down a dead-end path (into
the bear's cave?), then we are in an even worse condition. Is IPv6 this
dead-end path, or just an imperfect solution?

David Meyer [mailto:[email-masked]] wrote:
> 	In any event, as I said in AMS, lets "give peace a
> 	chance" and see if we can't make some progress. Yeah,
> 	things were/are broken. But that's the past. Let's look
> 	forward where we can. And lets also note well that the
> 	"proof" will be in what we produce (and more importantly,
> 	what we deploy).

That is well said--thank you, David.

Cheers,
-Benson

---

From: John Day <[email-masked]>
Date: Thu, 9 Nov 2006 11:26:47 -0500

I couldn't disagree more.  This is an architecture-discuss list, 
which I take to mean that how to do architecture is part and parcel 
of that effort.  This is precisely what this list should be 
discussing.

Your plea is that we return to precisely the behavior pattern that 
has gotten us in this mess.   I would even suggest that your 
suggestion merely serves to illustrate the point I just made in my 
reply to Noel.

if we are going to finally start solving problems.  It can't be 
business as usual.

Perhaps the discussion of this technical point should be another 
list.  On this list, this technical problem should be viewed from the 
point of view of what does this tell us about what the architecture 
should look like.

Take care,
John

At 8:07 -0800 2006/11/09, Fred Baker wrote:
>That said, we have cycles for one thing. We can navel-gaze and 
>wonder whether we need a counsellor, or we can go solve the IPv6 
>addressing problem. This list is for technical discussions, and 
>right now we really need to be thinking about the technical topic.
>
>Please?
>

---

From: Dorian Kim <[email-masked]>
Date: Thu, 9 Nov 2006 11:28:26 -0500

> crisis to motivate further change is risky.

Counter contention could be that we've been hearing this for the last
10+ years and how do we know it's too late until we try and see if we 
can make changes fly?

-dorian

---

From: John Day <[email-masked]>
Date: Thu, 9 Nov 2006 11:40:21 -0500

>10+ years and how do we know it's too late until we try and see if we

Please remember that the "it is too late to change" or the "Internet 
is too large to change" are standard ploys of those trying to protect 
the status quo.  As Noel indicated they have been used for a long 
time. 25 years in the Internet, that I know of!

My response is the only reason not to change is if you believe that 
the Internet is near the end of its growth.  I don't believe that.  I 
don't believe that we are even close.  I don't even think we are as 
close to it now than 1980 (roughly when I heard it first) was to 
where we are now.

But then I always have been an optimist.  ;-)

(And as far as giving peace a chance.  How long do they want?  They 
have had 14 years!)

Take care,
John

---

From: Fred Baker <[email-masked]>
Date: Thu, 9 Nov 2006 08:52:43 -0800

On Nov 9, 2006, at 8:20 AM, Schliesser, Benson wrote:
> This feels like feature-creep to me, when the business really needs  
> us to just ship a product. That is, unless shipping the product  
> would lead to massive recalls etc, but I haven't heard any real  
> argument to that end yet.

I'll suggest that you look through
	http://tools.ietf.org/html/draft-baker-v6ops-l3-multihoming-analysis
	http://tools.ietf.org/html/draft-ietf-ipngwg-esd-analysis
	http://tools.ietf.org/html/draft-ietf-ipngwg-gseaddr
	http://www.vaf.net/~vaf/v6ops.pdf or (longer) http://www.vaf.net/ 
~vaf/iepg.pdf

Bottom line, I didn't look at GSE in the draft above, but I looked at  
what we're doing now, and I looked at two other things that the IETF  
has looked at, and compared them to the stated requirements for the  
problem in RFC 3582. What I came up with is that PI addressing as  
practiced today is very likely to put O(10^7) routes into the  
backbone by 2050, and by a different analysis Vince Fuller reports a  
similar number within 15 years. Compared to our present O(10^5)  
routes, that's a lot, and it drives

  - equipment cost: recalling that the route table is replicated in  
many memory systems on each high end router, how much did you want to  
pay for the equipment?
  - service delivery cost: power, cooling, ...    Recall that Google  
is siting plants by rivers to address power and cooling now...
  - route scalability: BCP 38, as I discussed a few days ago, imposes  
some interesting issues in IPv6 routing

I'm told that traffic engineering is a big deal as well, which leads  
me to believe that we don't have all the requirements on the table,  
and to be frank I'm a little peeved that after ten years of bickering  
and dismissive slamming of each other both IETF->ISPs and ISPs->IETF  
we haven't managed to get that basic step done.

It's not feature-creep. There is a very expert set of people who  
stated up front that this problem needed to be addressed (among  
others), and it hasn't gotten addressed. This is kind of their last  
chance to get it addressed, and they really want to do so. I think it  
is better for us that we take the step and have an honest and non- 
combative discussion on the topic.

The biggest problem, frankly, is that we have conflicting  
requirements and two communities that are willing to hurl insults  
rather than listen and help. An example of the conflicting  
requirements is that Vince and others, and many in the enterprise  
community, want IP addressing without the requirement to renumber  
when you leave a service provider, and consider that a fundamental  
need, while many in the ISP community see IPv6 PA addressing as a  
market lock and therefore something advantageous to them. Yes, I have  
heard those words from ISP mouths. We can't both create and not  
create a market lock, and whichever group we fail to please is  
guaranteed to be wandering around making pretty strong statements  
about the unresponsiveness and stupidity of the IETF community. shim6  
right now creates a market lock for any customer that abhors  
renumbering.

---

From: John Leslie <[email-masked]>
Date: Thu, 9 Nov 2006 13:22:27 -0500

> 	http://tools.ietf.org/html/draft-baker-v6ops-l3-multihoming-analysis

   (33 pages)... written as advice to IP address registries: it is
unlikely that registries can do much about the problem. :^(

> 	http://tools.ietf.org/html/draft-ietf-ipngwg-esd-analysis

   (52 pages)... analysis of GSE proposal; I haven't read it either.

> 	http://tools.ietf.org/html/draft-ietf-ipngwg-gseaddr

   (20 pages)... the GSE proposal: calls for rewriting addresses at
site boundaries. At first blush, it looks like automated renumbering
for re-homing to a different upstream...

> 	http://www.vaf.net/~vaf/v6ops.pdf or (longer) http://www.vaf.net/ 

   (19 slides)... explains why provider-independent routing-as-we-
know-it can't work.

> backbone by 2050...

   Clearly unworkable!

   (I'll let others discuss the perpetual-motion-machines they envision
to get around this routing problem...)

> we haven't managed to get that basic step done.

   Our problem is architectural: asking the routing infrastructure to
solve the reliability problem which multi-homing intends to address
can only decrease the reliability of the routing infrastructure.

   (I shall briefly resist the temptation to give an "obvioous" answer.)

> combative discussion on the topic.

   By all means. But let's separate it from what particular protocol
we use for inter-netting.

> need,

   Examine that statement carefully: it's not quite correct. They
want end-user source- and destination-addressing that need not change
when a particular upstream ceases to provide what they need for
reasonable prices and conditions. We'd be _very_ poorly advised to
(try to) deny them this.

> while many in the ISP community see IPv6 PA addressing as a  
> market lock and therefore something advantageous to them.

   The upstream providers want sufficient lock-in that they can
pass through any cost increases without worrying about losing their
customers. Without this, their businesses are more likely to fail.

> We can't both create and not create a market lock, and whichever
> group we fail to please is  guaranteed to be wandering around
> making pretty strong statements  about the unresponsiveness and
> stupidity of the IETF community.

   IMHO, we can't create this market lock, period. The ISPs must
create it themselves (and I don't believe they'll succeed). We
should, however, beware "reasonable-sounding" calls to "protect
the infrastructure" by helping them create such locks.

--
John Leslie <[email-masked]>

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 9 Nov 2006 22:34:02 +0200

While I appreciate Fred's plea not to continue with non-technical  
discussion here, I don't think the general discussion list nor the  
e2e-interest lists are would be the right places either.  We do have  
an architectural problem, that far I think we almost all agree.   
While we could argue about the detail problems ad infinum, it is  
pretty clear the Internet architecture as it was 20 years ago, and  
very much is considered to still be, doesn't work _that_well_ any  
more.  That it, it still "works", for some definition of "works", but  
it could work much better.

To me, the systems theory pattern was enlightening.  It gave a  
behavioural, sociological explanation why we, i.e. the IETF, IAB, and  
IRTF, fail to discuss the architecture in the fundamental sense.  We  
simply seem to be, as organisations, addicted to the current way of  
working.

More important, however, might be the suggested aids.  To copy from  
the web page I referred to:

> 1. When dealing with a problem ask yourself if you are treating the  
> symptoms or addressing the real cause of the problem. Often, out of  
> expediency, the symptomatic solution is essential. The most  
> effective strategy for dealing with a Shifting the Burden structure  
> is an employment of the symptomatic solution AND development of the  
> fundamental solution. Thus one resolves the immediate problem and  
> works to ensure that it doesn't return.
>
> 2. If the structure promotes the development of an addiction then  
> you have another problem so solve.

So, we seem to have three different problems to solve:

1. Creating new symptomatic solutions to address the short term needs.
2. Creating new fundamental solutions to address the fundamental  
problems.
3. Working out a structure that does not promote this addiction any  
more.

IMHO, on this list we should focus on the middle one, to the extend  
we can.  So, my apologies for this side track, but I think this side  
track is needed.

The IETF in general takes pretty well care of the first one.

I have no idea if there is any part of the current I* organisation  
that could really ponder about the last one, but maybe there is.  At  
least there are brave people out there; perhaps this ongoing  
discussion could give some common direction to them.

As a community, we have tried, in different ways over the years,  
discuss the fundamental architectural issues.  We have had good  
ideas, many of which have been published.  Almost all have died, and  
those that are still alive are not doing too well.  Hence, some very  
fundamental changes seem to be needed.  We, as an organisation, need  
to learn and change, I'm afraid.

I cannot claim to be any expert of organisational learning.  However,  
one particular organisational learning theory has recently gained my  
attention, and seems to have its roots deep: The Theory U, by  
Scharmer et al from MIT Sloan School of Management.  For a good  
presentation of the central ideas, see http://www.learninggroup.org/ 
dec05presentation.pdf

 From the I* point of view, trying the U would mean really deep  
diving.  I guess some old timers would recognise such deep diving,  
but I haven't seen it in any larger nor smaller scale, though.  The  
current structure of our discussions just doesn't create the  
necessary space for such state of mind.  However, only something like  
that would provide any real change to the architecture, I'm afraid.   
Very difficult, but perhaps not impossible.

The next question for this forum, then, would be how to apply the U  
theory to the fundamental architectural problem, i.e., problem #2 above.

I have no answer to that.  But perhaps someone has.  Or perhaps  
someone can point to a knowledgeable argument showing that this train  
of thought is completely pointless.

--Pekka Nikander

---

From: David Meyer <[email-masked]>
Date: Thu, 9 Nov 2006 14:00:10 -0800

Pekka,

> While I appreciate Fred's plea not to continue with non-technical  

	We plan to use this list for discussion of the outcomes
	of the routing and addressing workshop, and about the
	(technical) ways forward. If you desire a mailing list
	for non-technical issues (such as organizational theory),
	please set one up. We do, however, need to focus on the
	our task, and this is the list that we're going to use
	for that. Please respect this request.

	Thnx,

	--dmm

---

From: John Day <[email-masked]>
Date: Thu, 9 Nov 2006 17:08:32 -0500

I guess the question is more, where should the architecture 
discussions go if this is going to be dedicated to routing and 
addressing?

Just curious,
John

At 14:00 -0800 2006/11/09, David Meyer wrote:
>Content-Type: multipart/signed; micalg=pgp-sha1;
>	protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ"
>Content-Disposition: inline
>
>	Pekka,
>
>Attachment converted: Macintosh HD:Untitled 1 (    /    ) (0047BDDF)

---

From: Lixia Zhang <[email-masked]>
Date: Thu, 9 Nov 2006 14:18:19 -0800

> discussions go if this is going to be dedicated to routing and  

routing and addressing discussion is architecture discussion.

> John

e2e-interest list has been used for many other architectural  
discussions.

---

From: Alexis Turner <[email-masked]>
Date: Thu, 9 Nov 2006 23:37:17 +0000 (UTC)

Well, that succinctly summed up why the net is broken - because no one wants to 
actually think about it.
-A.

	Pekka,

	Thnx,

	--dmm

---

From: David Meyer <[email-masked]>
Date: Thu, 9 Nov 2006 16:44:06 -0800

On Thu, Nov 09, 2006 at 11:37:17PM +0000, Alexis Turner wrote:
> Well, that succinctly summed up why the net is broken - because
> no one wants to  actually think about it.

	Well, that's really not a fair statement. A lot of folks
	care deeply and spend a lot of time thinking about what
	the problems are (both technical, organizational, and
	admistrative), and how they might be addressed.  

	What I do think we need, however, is a place to
	have a focused discussion about the problem space and
	potential solutions, and if this doesn't turn out to be
	the right place to do it, that's ok. 

	So let's stop trashing one another and get on to the work
	at hand.  

	--dmm

---

From: Scott W Brim <[email-masked]>
Date: Thu, 9 Nov 2006 18:34:14 -0800

> 	for that. Please respect this request.

Dave, are you saying you want this list *only* for routing &
addressing issues?  If so ... Routing & addressing interact with other
architectural issues, and so far this list is lightly used.  Let's
wait until there's a demonstrated problem, and then weigh costs &
benefits?

Scott

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 10 Nov 2006 10:40:29 +0200

Fred,

You wrote earlier:
> market lock and therefore something advantageous to them. Yes, I  
> have heard those words from ISP mouths. We can't both create and  
> not create a market lock, and whichever group we fail to please is  
> about the unresponsiveness and stupidity of the IETF community.  
> shim6 right now creates a market lock for any customer that abhors  
> renumbering.

I think this is a nice example where asking the right questions, or  
going deeper, may help.

In this particular case, I'd like to ask why the enterprise community  
abhors renumbering?

And I think we know the rough answer chain:

   1) it costs too much, because

   2a) addresses have high-level, application specific semantics,  
thereby making changing them costly, and

   2b) there are no good mechanisms for addressing these costs in the  
current architecture

So, jumping a little ahead in the name of brevity, IMHO, this goes  
directly to my previous question:

   What are the things that we want to name and address?

According to yesterday's plenary slides, id/loc split was felt  
popular in the workshop.  My interpretation would be that it was felt  
so because it shifts the cost structures, making your above described  
incentive tussle to disappear.

In other terms, we want to name/address applications/services/ 
whatever differently from the network locations, creating a different  
cost structure than the current one.

Basically, we seem to have three different asset structures here:

  1) Applications, which are bound to the (socket) API.  Changing  
these is very slow, as our experience with IPv6 amply shows.   (> 10  
years from spec to most apps having been changed)

  2) Host operating systems.  Here the turn around is fairly fast,  
only 3-5 years and the majority of hosts have a newer operating  
system.  Again, think about prevalence of IPv6 implementation at  
today's hosts.

  3) Routers.  This is the area where I have least experience, but I  
would imagine that the routers get replaced at roughly the same rate  
as hosts.  The purchasing and feature economics differ, though.

The focus seems to be only on the routing system.  I think that is a  
wrong approach.  By changing the hosts appropriately, we could lift  
quite a lot of pressure from the routing system.  There are even  
several ways for doing it!  The trick is to simultaneously preserve  
the (socket) APIs and other needed backwards compatibility, as their  
changing takes much longer.

In fact, both the GSE and SHIM6 approaches are going there already:  
changing both the hosts and routers, roughly but not quite at the  
same time.  What I just consider sad is that people dare not be  
radical enough, given that we will, ANYWAY, need to change both the  
hosts and routers, and wait for the 3-5 years to get that deployed.

So, based on the above, I still think the right question is to ask  
what we want to name and address, through the socket APIs.  Only then  
plan how to change the hosts, routers, and infrastructure  
appropriately, preferably in a step-wise manner, each step making  
sense in itself.  (A few IETFs ago I described how that could happen  
with HIP, if anyone remembers any more.  Today I think that HIP is  
not radical enough; we need even bigger changes.  HIP is just like  
SHIM6 + some elements of GSE + some more infra for referrals, but  
still focusing on hosts.)

--Pekka Nikander

---

From: Fred Baker <[email-masked]>
Date: Fri, 10 Nov 2006 04:41:56 -0800

On Nov 10, 2006, at 12:40 AM, Pekka Nikander wrote:
> In this particular case, I'd like to ask why the enterprise  
> community abhors renumbering?
>
>   2b) there are no good mechanisms for addressing these costs in  
> the current architecture

Those are certainly important parts of the question. I learned a lot  
while researching for

http://www.ietf.org/rfc/rfc4192.txt
4192 Procedures for Renumbering an IPv6 Network without a Flag Day. F.
      Baker, E. Lear, R. Droms. September 2005. (Format: TXT=52110  
bytes)
      (Updates RFC2072) (Status: INFORMATIONAL)

Bottom line, the primary reason that I came up with for people not  
wanting to renumber has to do with poor application design and  
network management practices.

Unicast network layer addresses do not actually have "high-level,  
application specific semantics". There are some multicast addresses  
that have specific meanings, such as AllOspfDesignatedRouters; I'll  
argue that those are a very special case. If unicast applications had  
application-specific semantics, one would need different addresses  
for different applications. They don't; addresses are assigned per  
interface, not per application.

One can argue that there is no need for a generic application to have  
any knowledge of either the address(es) of its own system or a peer  
it wants to communicate with. The reason that it does know is what I  
would consider to be poorly designed socket APIs. The way many OS's  
work today is something like:

	address := gethostbyname(DNS name);
	socket := opensocket(address);

One could imagine a different API:

	socket := openSocketByName(DNS name)

to accomplish the same thing, and hide the distinction between  
different kinds of IP addresses and the multiplicity of them entirely  
from the application. Alas, it is not so.

Now, the folks in the opsec working group will tell you that they  
really don't want to have access by name, they really want the  
address, and will give you reasons why. No problem, we provide a  
separate API for folks who have a real requirement of this type.  
Let's just say that they are a special case, not the general one.

Regarding mechanisms in the present architecture for managing address  
complexities, well, we have mechanisms (see, for example, RFC 2894,  
and more generally consider how a large network uses scripts and  
databases to manage configurations), but I'm not sure the mechanisms  
are all that relevant. The big issue is that there are a variety of  
configuration elements in routers (yes, my company is part of the  
problem here) and in some cases in applications where it is just a  
whole lot simpler to configure the address, and as a result the  
address is what is configured. Fixing this is a non-trivial problem,  
not something that one waves a hand at. Route maps, access lists,  
security associations, static routes, and a long list of other things  
are implicated here. I was told of a company whose shipping would  
stop cold if a certain computer was renumbered, because the hand-held  
UPC readers used in the process use a hard-coded IP address rather  
than a DNS name configured in a NVRAM or such - someone took an ill- 
advised short-cut, and it makes that particular change difficult.  
This class of issue is mostly what makes renumbering hard. And saying  
"well, if we just had <pick your protocol> defined and implemented  
that would be solved" is naive - the big problem there is that never  
mind what might or might not exist, the engineer designing <whatever>  
chose to not use it. If the tool isn't used, it really doesn't matter  
how wonderful it is.

You might find

http://tools.ietf.org/html/draft-chown-v6ops-renumber-thinkabout
   "Things to think about when Renumbering an IPv6 network", Tim Chown,
   20-Sep-06

interesting in this context.

The problem is closest to your "it costs too much", although in this  
case it isn't a monetary cost. It is the fact that one has to somehow  
touch every computer in an organization including its network  
infrastructure and management and mission-critical servers, and in  
touching them do exactly the right thing. That is something that is  
doable (my company does it regularly) on a piecemeal basis, but  
pretty difficult for a company of any non-trivial size to do globally  
in one swell foop.

So I mostly disagree with your 2(a) and 2(b), but I will agree with  
some variation on your first point.

> what we want to name and address, through the socket APIs.

OK, so what would they be?

I tend to think of applications in the manner that the term "host"  
resulted from. An Application Host Processor, for those of us  
familiar with Big Blue, is a computer on which applications run. If  
two applications cannot coexist easily one one host, one either  
upgrades the host in some way or separates them, making them run on  
separate systems. If two systems are underutilized, one might  
similarly move an application from one to the other for economic  
reasons. The computer is a computational environment that some number  
of applications use, and the applications are in a very real sense  
the important part. So I will generally argue that one wants to name  
applications, not the computers they run on, and lo and behold we do  
that (sort of). We have names like ftp.example.com, smtp.example.com,  
and so on. The translations of these names into addresses may result  
in single or multiple addresses, and in the latter case they may be  
multiple interfaces on the same machine or they may be different  
machines. In general, I think that is a very sensible model.

As to addresses, one needs a way to find the endpoint that a targeted  
application runs on in the topology of the network. That is a many- 
layered thing; when the message arrives at the host, how does the  
host determine that the message is intended for itself? How does the  
router in front of it determine which host to deliver the message to?  
On some different LAN, how does one find an acceptable path to the  
target LAN? In view of RFC 2008, in a remote administration, how does  
routing find the targeted administration that operates the intended  
LAN? This is the stuff (using GSE's terms) of the endpoint  
identifier, the LAN ID, and the "routing glop". There are many ways  
to cut this cookie: the addresses a system uses can, when treated as  
an equivalence class, be called a locator or endpoint identifier, or  
the DNS name could be called that. So the EID doesn't have to be  
implemented as a certain set of bits within a network address; there  
are other ways to do it. But functionally, we have to have some  
solution to the problem that the EID, however we understand it,  
solves. Ditto more and less specific components of the routing locator.

I tend to think, and this isn't a very original thought, that the big  
problem that we have tripped over in this area is that we have not  
kept names at the application layer and network layer addresses at  
the network layer. They are in fact in the right places, but we  
manage to distribute addressing information to a part of the system  
it is irrelevant to, and in so doing shoot ourselves in the foot.

If you want a detailed discussion of this, you might be interested to  
review the development and specification of the ISO CLNS NSAP :-)

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 10 Nov 2006 17:16:01 +0200

Fred,

You managed to neatly summarise what I tried to say but failed:

> I tend to think, and this isn't a very original thought, that the  
> big problem that we have tripped over in this area is that we have  
> not kept names at the application layer and network layer addresses  
> at the network layer. They are in fact in the right places, but we  

What I meant with "application specific semantics" is what you said:  
addressing information getting installed in various places in the  
application world (e.g. in configuration files), mostly due to bad  
design.  Nothing new, already discussed in RFC 1958.  But reality.

What I meant with "having no good mechanisms for changing [the  
addresses]" is exactly what you said: "one has to somehow touch every  
computer in an organization".

And when I say "cost", I my no means mean monetary costs; even  
needing to pay attention is a cost.

I guess another communication problem is that I tend to consider the  
"Internet architecture" to be what is out there in reality, not the  
way we would like it to be.  Another problem is apparently language.   
I'm not a native English speaker, and I seem to use some words  
differently than a native speaker would use; sorry about that.  And  
thanks for your clear explanations.

> OK, so what would they be?

I tend to think that the "host" concept is not really something that  
applications are interested in.  They are interested in getting  
certain information (content) or services (dynamic content or  
transactions, if you will).  The lower layer implementation still  
probably benefits from the host concept, but I am not quite sure.   
Perhaps naming hosts by enumerating the dynamic set of locators  
currently associated with their interfaces might suffice.  (Remember  
the late "Homeless MIP" draft?)  However, due to the difficulty of  
keeping such dynamic information reliably up-to-date, I still lean  
towards having a layer able to name "hosts".  That shouldn't be  
visible to the applications, though.

Hence, since the socket API is what the applications see today and  
will see at least for the next 10 years and probably much longer, I  
think we should do quite a lot of changes underneath, just to get the  
architecture to match with the contemporary needs.  Right now the  
applications see the locators.  With MIP, HIP, or SHIM6 they see some  
kind of "host" identifiers, let they be called "home addresses",  
"host identity tags", or "upper layer identifiers".  I think we  
should take one step further, and make the socket API "things" to  
refer to content and/or service names.  Something that is completely  
independent from the physical location of the services.  At the same  
time, we need to let the socket API "things" still look like IP  
addresses for the legacy apps.

New steps of indirection to the legacy socket API: <API "address",  
port> -> "internal service name" -> "host name" -> "locator".

The important point is that if we manage to get to a level where the  
"things" applications "address" through to socket API are no longer  
bound to the network topology, we will get _much_ more freedom in  
reconsidering the addressing and routing structures.  Renumbering  
will no longer be such an issue that it is today.  In other words, it  
would become much easier to keep the addresses roughly in par with  
the topology, relieving most of the identified future burden from the  
routing tables.

The second, perhaps less obvious point is that new layers of  
identifiers would allow routing over multiple IP domains.  Hence, in  
addition to relieving burden from the routing tables by allowing more  
dynamic address assignment, we could also create a new routing layer  
on the the top of the existing ones.  Something that could be called  
"architected overlay routing" across multiple domains, if you will.

--Pekka Nikander

---

From: David Meyer <[email-masked]>
Date: Fri, 10 Nov 2006 07:24:03 -0800

> wait until there's a demonstrated problem, and then weigh costs &

	Come on folks. This has kinda gotten out of hand. We need
	a list for some technial discussions and this one had
	been very quiet, so we thought maybe we'd use it. Its not
	that big of a problem. We'll make another list.

	--dmm

---

From: Jefsey_Morfin <[email-masked]>
Date: Fri, 10 Nov 2006 16:51:41 +0100

Dear Fred,
I read what you say. And this very interesting. Thank you.

But I do not understand why you want to change what exists? Not only 
to improve what is coming and give all the time to what exists to 
become obsolete or to find new solutions for new needs. There are six 
IPv6 /3 blocks. People needing hard coded IP addresses are eiher 
using the current IPv6 block or IPv4. What is the problem of keeping 
supporting them? And to pcik another block for another numbering plan 
reducing the load on tables? This is why I lobby for RIRs and ITU 
addressing blocks to coexist and cooperate. Multihoming and mobility 
are an issue for people not bound to their IP addresses?

IMHO routing is not to be addressed in tables but in the addressing 
plan (coordinates) plus a distributed needle mechanism (probably a 
ONES, i.e. networked OPES which could probably also address the 
problem at the net/host edge). For a few years birds, fishes, ants, 
etc. succeed to go where they want rather efficiently without any 
table on the top of the moutains or the bottom of the sea?
jfc

---

From: David Meyer <[email-masked]>
Date: Thu, 9 Nov 2006 14:15:13 -0800

> discussions go if this is going to be dedicated to routing and 

	I don't have an answer, and since I posted this message
	some of my collegues have suggested we use a different
	list for routing & addressing. We'll get together and get
	a dinfinitive answer to you as soon as possible.

	--dmm

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 10 Nov 2006 11:47:30 -0500

Dave,

That would be good I think.  Probably should announce the list to this
list too and whereever else it is announced.  I would suggest we need to
identify the technical topics well and if you can do that it would be
helpful.  Also might be good to work on addressing first then routing as
Peter Sherbin from Rogers suggested last night at the Plenary.

Thanks
/jim 

> -----Original Message-----
> From: David Meyer [mailto:[email-masked]] 
> Sent: Thursday, November 09, 2006 5:15 PM
> To: John Day
> Cc: Pekka Nikander; [email-masked]
> Subject: Re: [arch-d] [Off-topic ] Furthe r thoughts: about 
> systems theory andthe theory U
>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 10 Nov 2006 10:45:54 -0800

+1

Actually, I don't mind discussing this topic. But
what I am missing is a discussion of

(1) Do we have an architectural problem with
     regards to routing scalability, and what
     are the supporting facts?

(2) Possible ways to address the problem and the
     relevant trade-offs.

--Jari

Fred Baker kirjoitti:
> Guys, maybe we should set up a different list for this discussion. I'm
> sure it's a very interesting and important discussion for the IETF to
> have about itself.
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 10 Nov 2006 13:54:48 -0500

I would like to see these questions discussed.  Also under trade-offs
the market and business ramifications are part of that discussion when
it happens.

/jim 

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Friday, November 10, 2006 1:46 PM
> To: Fred Baker
> Cc: [email-masked]
> Subject: Re: [arch-d] Systems theory: The IETF "addicted" to 
> "symptomaticsolutions" aka "point solutions"?
> 
> +1
> 
> Actually, I don't mind discussing this topic. But what I am 
> missing is a discussion of
>