Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches

From: Jari Arkko <[email-masked]>
Date: Wed, 15 Feb 2006 18:19:25 +0200

Trying to summarize this old thread... I think we concluded
the following:

o Good architecture does not necessarily imply that we have
exactly one solution for each individual component problem.

However, for some parts of the stack having multiple solutions
is easier than for others. For instance, there are many wireless
link layers, and this diversity has generally been a good thing.
For IP, this is more problematic, because it should be the layer
that allows interneworking. Similar problems apply to any
end-to-end protocol, though there might be a smaller population
of users.

Question: are there differences in the different parts of the
IP layer, or do we expect it to provide the same universal
service? For instance, today we can (most of the time)
rely on getting the basic communication service, but finding
a peer that supports a multihoming IP extension is very
unlikely. Note that this isn't just a question of what new
functions we should require IP to have. Its also about whether
the old functions should continue to exist. In Eric's example
there was a specific case where an existing function, multicast,
no longer worked. Similarly, NATs have limited our ability to
act both as servers as clients.

o Minimization, and the waist of the IP hourglass. We seem to agree
on that the core functionality needs to be small in order to maxime
the ability to support the architecture in different systems and
over time; minimality provides flexibility.

Many people feel that we have lost the focus on the narrow waist.
(Or are, say, IP layer extensions mostly additional functionality
on top, and not a true part of the waist? See also above about
the universal service.)

o Striking the right balance between market driven development
and architectural oversight is needed. But it is hard.

o Architectural redesign is painful, and expensive in the short run.
Local-tweaks look less expensive, because they are cheap in the
short run.

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 15 Feb 2006 10:49:32 -0600

Hi, Jari,

> Similarly, NATs have limited our ability to

If I'm reading 
http://www1.ietf.org/mail-archive/web/sip/current/msg12820.html and the 
related thread correctly, it's also worth mentioning that NAT keepalives for 
VoIP look like a huge amount of overhead and are creating ugliness (well, of 
course you have to modify all of the implementations of any protocol that 
wants to keep its NAT bindings active, to switch on the keepalive packets 
correctly).

This was pretty easy to ignore in a seriously client-server world 
(especially one where interesting servers were not behind NATs), but is now 
a lot harder to ignore in a peer-to-peer world (oh, you wanted to receive 
phone calls, too?)...

Thanks,

Spencer

---

From: Jari Arkko <[email-masked]>
Date: Wed, 15 Feb 2006 19:08:17 +0200

Spencer Dawkins wrote:

>  it's also worth mentioning that NAT keepalives for VoIP look like a 
> huge amount of overhead and are creating ugliness (well, of course you 
> have to modify all of the implementations of any protocol that wants 
> to keep its NAT bindings active, to switch on the keepalive packets 
> correctly).

Indeed. And if you count what percentage of capacity this can
take in a wireless network, you'll be surprised.

Of course, this can probably be optimized somehow, the
complexity can be hidden in a common protocol component,
but still, it is one of the ugliest and most troublesome parts
of the current network, IMHO.

Its worth noting that there's no fundamental reason why this is
so broken. Even if you were to accept the concept of a NAT (or
a stateful firewall, for that matter; the problems are similar), an
architectected design could have avoided keepalives in various
ways.

--Jari

---

From: Melinda Shore <[email-masked]>
Date: Wed, 15 Feb 2006 12:28:07 -0500

> architectected design could have avoided keepalives in various

We do have a handful of ways to communicate what we want directly
to the NAT (RSIP, midcom, NSIS).  It's hard to deploy, however,
since they all assume that you've got capable NATs and, in the
case of midcom and rsip, that you know where they are.  They do
not, however, require the use of keepalives or other behavior
that's intended to influence the NAT by side-effect.

What's happening instead is that applications people dealing with
NAT traversal problems are putting together a set of procedures
for inferring things about the behavior of NATs in your networks
and where the application endpoints are in relation to the NATs.
It's an unfortunate development in light of its nasty architecture,
nasty messaging, and nasty security properties, but I suspect
it was inevitable given deployment difficulties and various
political problems.

The firewall traversal problem is actually substantially different,
and there's good reason to be concerned that some of the NAT
traversal mechanisms under discussion are being adapted to solve
firewall traversal.  Because they work by side-effect rather than
explicit request, they're effectively outsourcing border security
policy enforcement to the application.

Melinda

---

From: [email-masked]
Date: Wed, 15 Feb 2006 20:01:09 +0200

Spencer, Jari,

NAT signaling isn't just about signaling overhead, it's also about
battery
capacity. Depending upon how frequently you send keep-alives, you can
really
eat into battery capacity.  Wireless is great, as long as you don't need
to be plugged into a power outlet!

Also, usage patterns are different.  As an informal test for some other
stuff
I'm doing, I'm keeping track of my family's phone usage.  My wife has
the record,
so far she has not turned off her phone for 179 days and counting (she
has
had to charge it a few times, though).  If you imagine needing to run
keep-alives 
in order to be able to receive calls or message, that would be a lot of 
keep-alives.

John

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>ext Spencer Dawkins
>Sent: 15 February, 2006 18:50
>To: [email-masked]
>Subject: Re: [arch-d] Valid and Invalid Internet architectures 
>and approaches
>
>Hi, Jari,
>
>> Similarly, NATs have limited our ability to act both as servers as 
>> clients.
>
>If I'm reading
>http://www1.ietf.org/mail-archive/web/sip/current/msg12820.html
> and the related thread correctly, it's also worth mentioning 
>that NAT keepalives for VoIP look like a huge amount of 
>overhead and are creating ugliness (well, of course you have 
>to modify all of the implementations of any protocol that 
>wants to keep its NAT bindings active, to switch on the 
>keepalive packets correctly).
>
>This was pretty easy to ignore in a seriously client-server 
>world (especially one where interesting servers were not 
>behind NATs), but is now a lot harder to ignore in a 
>peer-to-peer world (oh, you wanted to receive phone calls, too?)...
>
>Thanks,
>
>Spencer 
>
>
>

---

From: Tony Li <[email-masked]>
Date: Wed, 15 Feb 2006 11:22:38 -0800

Jari,

Thanks for summarizing.

> act both as servers as clients.

As with any good architecture, we need to have a very clear definition
of what we expect a minimal implementation to provide.  That minimum
level of functionality defines the baseline of the architecture and so
is key to defining the basic capabilities throughout the network.  Any
function that we feel should be pervasive (e.g., multihoming) should be
intrinsic, not an optional extension.  This is a bug in our current
approach in that we have not only left out multihoming (and renumbering,
etc.) but we have also failed to state what a minimal implementation
truly is today.

> on top, and not a true part of the waist? See also above about

This is just another way of complaining about the existence of MPLS.  In
truth, what we should be focusing on at the architectural level is to
how IP should support connection-oriented services, complete with
explicit path establishment.  The fact that IPv4 cannot support this led
to the creation of an alternative in the waist of the hourglass.  Now,
purists may claim that you don't ever want to support those services,
but this does nothing for those folks who feel that they need/want them.

Regards,
Tony

---

From: [email-masked]
Date: Thu, 16 Feb 2006 06:25:43 +0200

Hi Melinda & Jari,

Things are also complicated by the fact that different protocols
have different NAT traversal techniques, leading to the potential
layering of different keep-alive solutions when running SIP over
IPsec over MIP, for example (that is somewhat overkill, but I've
been in some meetings where use cases that would require this
functionality has been bandied about).  Since NATs are non-
transparent, it's impossible to really know how to traverse
them before you try.

I also agree with Melinda's comment on firewalls.

John

>ext Melinda Shore
>Sent: 15 February, 2006 19:28
>To: Jari Arkko; Spencer Dawkins
>Cc: [email-masked]
>> Its worth noting that there's no fundamental reason why this is so 
>> broken. Even if you were to accept the concept of a NAT (or 
>a stateful 
>> firewall, for that matter; the problems are similar), an 
>> architectected design could have avoided keepalives in various ways.
>
>We do have a handful of ways to communicate what we want 
>directly to the NAT (RSIP, midcom, NSIS).  It's hard to 
>deploy, however, since they all assume that you've got capable 
>NATs and, in the case of midcom and rsip, that you know where 
>they are.  They do not, however, require the use of keepalives 
>or other behavior that's intended to influence the NAT by side-effect.
>
>What's happening instead is that applications people dealing 
>with NAT traversal problems are putting together a set of 
>procedures for inferring things about the behavior of NATs in 
>your networks and where the application endpoints are in 
>relation to the NATs.
>It's an unfortunate development in light of its nasty 
>architecture, nasty messaging, and nasty security properties, 
>but I suspect it was inevitable given deployment difficulties 
>and various political problems.
>
>The firewall traversal problem is actually substantially 
>different, and there's good reason to be concerned that some 
>of the NAT traversal mechanisms under discussion are being 
>adapted to solve firewall traversal.  Because they work by 
>side-effect rather than explicit request, they're effectively 
>outsourcing border security policy enforcement to the application.
>
>Melinda
>

---

From: "Tian Chen" <[email-masked]>
Date: Fri, 17 Feb 2006 16:18:03 +0800

----- Original Message ----- 
From: "Tony Li" <[email-masked]>
To: "Jari Arkko" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 16, 2006 3:22 AM
Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches

> etc.) but we have also failed to state what a minimal implementation

IMHO, minimal implementation of our current approach is just and should be a
"basic communication service".  I don't think this is a bug. If some nodes need new functions 
(e.g., multihoming,mobility, identification),   they could fat their own waists of the IP hourglass with 
special bags(e.g.SHIM,MIP,HIP e.t.c),   and these are the cost *must* be paided for their
new functions. While other static nodes could still maintain their thin-simple IP waist 
without being bothered. (Those  nodes could communicate with each other in some 
MIP similar mechannism in the cost of bandwidth/efficiency). So if there is "feature cancer",
only who carried bags die.

By keeping backward compitiblity, SHIM6+CGA(or other similar approaches) would be at least 
a middle-term solution to architecutre issues and emergent industial needs. As Pekka Nikkander said, 
could we design a way towards converging solutions?  Instead of let many distinct approaches grow 
up for each fucntion, thus may prevent  those bags from being "feature cancer",or at least make nodes 
live longer :)

I agree with you that in the long-run the community may need a new architecture, and "any function 
that we feel should be pervasive should be intrinsic, not an optional extension".  I suggest we do middle-term 
solution and long-run  architecture in parallel. But both should be backward compitible at least with 
common static IPV6 nodes.
_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 17 Feb 2006 19:06:55 +0100

At 09:18 17/02/2006, Tian Chen wrote:
>I agree with you that in the long-run the community may need a new 
>architecture, and "any function that we feel should be pervasive 
>should be intrinsic, not an optional extension".  I suggest we do 
>middle-term solution and long-run  architecture in parallel. But 
>both should be backward compitible at least with common static IPV6 nodes.

%100 agree. But this calls for an architectural model of the ways 
(plural) to use that KISS basic solutions to build as many externets 
(independent external netwok look-alike within the same digital 
ecosystem) as people need. Parallel, converging or transitionning.

IMHO this calls for a user-centric (minimum granularity) 
multi-technology architecture based upon a structured stable address 
geography, independent from technologies. This is what I said I 
expected from this mailing list.

However the simplification makes many things currently embedded into 
the protocol stack to be supported at an 8th level interoperation 
layer. This means that eventually the applications may stay 
compatible (and new ones to be more powerful) transparently to the 
lower layers reshuffling. So transition is OK and hybrid network 
level solutions are able to be easily welcome. I expect service 
continuity, multilingualisation, spaces of exchanges, trust and 
services, mobility, security, etc. to be supported that way.

I think we should therefore not discuss (existing) protocols but 
functions. Like talking of word processing on a PC rather than Word, 
Open Office, etc. There may be different releases, solutions, etc. 
The network should be independent to its inteoperation system. 
Question is (previous mail) to indentify the features that 
interoperation system needs and see how IP support them (and how 
other protocols we may have to use in parallel use them - in 
particular in Space [which is a way to say sure sending, FEC etc. 
included] with applications everywhere).

jfc

---

From: Tony Li <[email-masked]>
Date: Fri, 17 Feb 2006 10:16:18 -0800

Tian,

> only who carried bags die.

Well, that's certainly a self-consistent point of view, but it begs the
question as to whether we can ever make any architectural changes.  In
fact, if the only possible additions are by bags on the side, then I'd
argue that the only functions being added are features and not intrinsic
to the architecture.

Thus, the question really comes down to whether or not we feel we need
architectural changes.

> common static IPV6 nodes.

It's an interesting thought, but so far we seem to have a strongly
allergic reaction to the thought of architectural changes in mid-flight
in the name of preserving the 'installed base' [sic] of v6
implementations.  IMHO, this is a fatal limitation that hobbles the
evolution of the network.  Consider the number of in-flight changes made
to v4 that quickly were adopted as intrinsic portions of the
architecture (e.g., subnetting, CIDR, DiffServ).

This seems to leave us in a position where we have passed the point of
accepting any substantive architectural changes.  This makes the
discussion (and indeed, the entire mailing list) rather moot.

Tony

---

From: Thomas Narten <[email-masked]>
Date: Fri, 17 Feb 2006 16:58:24 -0500

> implementations.

This is simply being pragmatic. One simply can't do fork-lift upgrades
that have significant cost and flag days. No one is willing to do
this. (This is a general statement and has nothing to do with IPv6 per
se. And while one can argue there is little "installed base" of IPv6
at one level, at another level there is --- in the sense of products
in the pipeline, etc. That is "installed base" because you can't turn
it off or pull it out of the pipeline, etc.)

The fact is we have a system today that people use/depend on. Talking
about "architectural change" in the abstract isn't useful. You need to
talk about a specific point you want to get to (i.e., a new protocol),
that has compelling value once there, and a credible transition plan
on how to get from here to there. That is the simple reality of trying
to make changes to infrastructure.

> IMHO, this is a fatal limitation that hobbles the evolution of the
> network.  Consider the number of in-flight changes made to v4 that
> quickly were adopted as intrinsic portions of the architecture
> (e.g., subnetting, CIDR, DiffServ).

But they were possible because there was a credible transition
strategy for how to deploy, that did not require unworkable flag days
and fork lift upgrades. It has nothing to do with being an
architectural change (or not). (And Diffserv is an architectural
change?)

> accepting any substantive architectural changes.

I don't agre with this conclusion. But IMO, it's not terribly useful
to talk about architecture in an abstract sense. Architecture is a bit
like art -- you know good architecture when you see it, but it's
really hard to define. It has to do with how a big complex system
(protocol suite) is componentized into separate, managable pieces,
where the parts fit together cleanly and with good abstract
interfaces, there is an overall simplicity and coherency, and so
forth.

> This makes the discussion (and indeed, the entire mailing list)
> rather moot.

Perhaps. I too get frustrated with abstract discussions about
architecture, as I don't see what it will lead to.

Thomas

---

From: John Kristoff <[email-masked]>
Date: Fri, 17 Feb 2006 16:24:20 -0600

> architectural change (or not). (And Diffserv is an architectural

Or quickly adopted for that matter?  :-)

John

---

From: Tony Li <[email-masked]>
Date: Fri, 17 Feb 2006 20:08:33 -0800

Thomas,

Architectural proposals have been lofted.  They were specific, had clear
migration plans, and the discussion was shut down with the usual "v6 has
already shipped" dogma.  Specific topics were:

	- GSE (more generally locator/identifier splits)
	- locator agile transport protocols

Without these types of capabilities, the architecture is stuck
supporting multihoming and mobility with kludges such as NAT, SHIM6 (NAT
in the host), and various forms of tunneling.

To truly move forward, we first need to have consensus on the following:

	- We have a problem.
	- The current crop of solutions are unsatisfactory.
	- We are willing to make changes.

Until then, we have the status quo.

Tony

---

From: Paul Vixie <[email-masked]>
Date: Sat, 18 Feb 2006 04:22:58 +0000

# To truly move forward, we first need to have consensus on the following:
# 
# 	- We have a problem.
# 	- The current crop of solutions are unsatisfactory.
# 	- We are willing to make changes.
# 
# Until then, we have the status quo.

since a reality tv show just occurred in my office about this, i'll share it.

the sysadmins here (isc) just came into my office and said "so what do you
want to do about ipv6 address space in amsterdam?"  we're going to open a
"mirror site" there this year, with the usual diverse transit and peering
and so on.

i was asked "can we carve a /48 out of our ipv6 /32?"  and i said "only if
you're going to cut it in half and only advertise the bottom /33 from
california".  i don't, you see, want to advertise both a cutout AND a covering
route unless i have a backbone, and i don't have a backbone to amsterdam, and
i don't wish to pretend i do (using tunnels).  they said "no, we can't do
that" (for various reasons).

i was asked "should we just get address space from each of our transits there,
and multihome all of our hosts?"  i said "if you're willing to have five or
ten addresses per interface, and deal with the fact that the little itty bitty
SYN and ACK packets will come to you via diverse transit, but all of your big
gigantic FTP and WWW packets will go out via a single default route, sure."
they said "no, we can't do that" (for various reasons).

so, for now, isc-amsterdam will not speak ipv6.  which is a pity, since we've
got compelling content that the R&E community _loves_.  i'm waiting to see
how the current ARIN PPML discussion around "IPv6 PI space for multihomers"
comes out.  perhaps we'll get a /32 or /48 or /64 or whatever, and burn a
slot in every routing table on the internet just to make ourselves reachable.
(for isc, it's not about provider lock-in, it's about making it work at all.)

in other words, i'm in favour of tony's first two assertions:

# 	- We have a problem.
# 	- The current crop of solutions are unsatisfactory.
# 	- We are willing to make changes.

i cannot, alas, speak for the third one.  (the rest of you could, though.)

note that some time after we solve this for amsterdam, we'll have to deal
with chicago by the same means (whatever those are).  an architecture that
leads even technically advanced early adopters toward nondeployment seems
"somewhat flawed" or at least "wanting more".

<insert obligatory DNS A6 RR rant here>

---

From: Fred Baker <[email-masked]>
Date: Fri, 17 Feb 2006 20:25:08 -0800

very much agree.

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 17 Feb 2006 16:56:09 -0800

Hi -

> From: "Thomas Narten" <[email-masked]>
> To: "Tony Li" <[email-masked]>
> Sent: Friday, February 17, 2006 1:58 PM
...
> architecture, as I don't see what it will lead to.
...

Getting even more abstact...

Architectural change could also be a change to our understanding of,
and how we talk about, what we already have.  It may even be useful
to have multiple architectural perspectives, just as classical physics
continues to be useful for describing some things, even though when we
also employ quantum physics every day.

Which perspectives are used can impact whether a particular problem's
solution seems simple or complicated, central or peripheral.

Randy

---

From: "Tian Chen" <[email-masked]>
Date: Sat, 18 Feb 2006 17:34:04 +0800

"Tony Li" wrote
> - We are willing to make changes.

I'm also in favour of tony's first two assertions, and not speak for the third one.
Yes, current IPv6  architecture is "somewhat flawed". Let me make a comparision.
He(IPv6 ) is  already an infant now, not an embryo; we just can't return him back to the
uterus and re-pregnant anothor better one, because he is already be recognized by the public.
And, IPv4 is running out, time is up, the torch have to be passed to this new generation of IP 
(even he is somewhat flawed) . What we could do now is make some remedies(or kludge,bag, 
cancer, what ever you want to call ) to help this baby facing new challenges, and start produce 
a successor. That's why I suggest "we do middle-term solution and long-run  architecture in parallel".
Maybe we could bring the GSE back as a candidate in long-run  architecture discussion. and also I 
could have a chance to boost (SHIM+CGA+MIP similar rendezvous mechanism) in a middle-term 
solution discussion.

IMHO, the most probelm of current architecture is not "supporting multihoming and mobility 
with kludges" or lack of identity. If we really abandon the current  one (Arch 1) and adopt a 
totally new architectural proposal (Arch 2) which could perfectly cater to all of those needs, 
what *should* we do if  another critical new requirement suddenly came out?  Yet another whole and
quick move to Arch 3...until Arch N? or, add kludge and bags to Arch 2?  So I think the next new 
architecture *must* be "Forward compatible" (or modularity?).  If a architecture is born to 
cope with changes, then a Architectural  Change won't be so painful and unacceptable anymore.

In my perfect world, architecture X is there. Layer's horizonal interfaces are organized in a 
COM/COM+  similiar style. When 2 people want to connect, their correspond layers do *capability
set exchange*  first (sounds like QueryInterface): who could mobile, who have identity,e.t.c. As soon
as a basic common agreement achieved, plane take off. What's more, Layer's vertical  interfaces are 
organized in  a WINDOWS OS network-driver-stack similar style, which already foresee many new 
addional IP waists and willing to manage them. Thus in 2036 when I am lurking in IETF's
 newer-architecture-discuss maillist, I  for sure won't see this:

A: Hey, you can't do that architectural change. This would not be backward compatible with  our exsiting 
     IPv8  systems.
B: The only reason that why we won't change the architecture is because it change the architecture

---

From: "Tian Chen" <[email-masked]>
Date: Sat, 18 Feb 2006 17:45:41 +0800

"Thomas Narten"  wrote
> interfaces, there is an overall simplicity and coherency, and so

I disagree with you in this point. you can't "know good architecture when
 you see it ", remeber OSI 7-layer model? It lost to IP architecture, where
we are speaking now. If a architecture is finally accepted by the majority
of the data-communication community, then it is a good architecture :)
 
> architecture, as I don't see what it will lead to.

Someone should put this mail list forward. If things still goes like "You MUST!"
"No, you can't" over and over, there would be no output.
_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Scott W Brim <[email-masked]>
Date: Sat, 18 Feb 2006 06:53:14 -0500

> architectural change (or not). (And Diffserv is an architectural

Architectural changes can be made by deploying first in islands, with
interworking and tunneling, and then letting the islands grow.  The
problem here is Tony's third point ...

> 	- We are willing to make changes.

... and that the Internet now runs on money.  Why would someone want to
deploy a small island with interworking (and loss of capability,
increased complexity and operational costs) when the issues are
competition and the bottom line for the next quarter?  You need either
higher motivation or lower cost.  The only thing that seems like it's
going to increase motivation is more pain for all of us -- carrots
aren't working.  How can we lower overall cost of deploying something risky?

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 18 Feb 2006 11:58:16 -0600

From: "Scott W Brim" <[email-masked]>

> aren't working.  How can we lower overall cost of deploying something 

I've been following the discussion in SIP on the overhead to keep NAT 
bindings alive (thread starts at 
http://www1.ietf.org/mail-archive/web/sip/current/msg12806.html).

The highlight is whether we need/don't need to have two protocols (in this 
case, one text-based and one binary) running over the same transport mapping 
to (1) keep NAT bindings alive and (2) actually do anything useful (in this 
case, SIP). The best guess (since NAT functionality isn't standardized) is 
that SIP endpoints behind a NAT would work best if they sent keepalives 
every 15 seconds, in order to make sure that they can make/receive something 
like one call per hour).

There is also some commentary on what the effect of actual productive work 
being a small minority of total work is on proxy costs, etc.

Of course, we note that multiplexing keepalive signalling for one 
application with that application doesn't actually keep any NAT bindings 
refreshed for anything else, so anything else that needs SIPpish NAT 
traversal characteristics either duplicates the NAT binding refresh 
signaling or becomes part of SIP...

So I'm worried that neither carrots or sticks are providing sufficient 
motivation for change... how much more pain is needed? Apparently, more than 
we might have guessed intuitively!

Thanks,

Spencer

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 18 Feb 2006 23:40:59 +0100

At 10:45 18/02/2006, Tian Chen wrote:
>of the data-communication community, then it is a good architecture

I saw three of them and I hope to see one or two more.  Each brought 
some feed-back teaching about reality.

Being an architect without understanding where you build for is 
useless. There is no "good" architecture. There are ways of 
addressing needs in a context. For that one must to understand the 
context and the needs. The big lack of the Internet culture is to 
lack a model. ENS (from Tymnet experience), OSI (from ITU analysis), 
were models. IETF has the RFC 1958: a set of recipes also based on 
experience. It is great because it tells how to build in the IP 
vision. But it does not say much about the framework where we build.

It is typical that this prospective debate is based on existing 
protocols and solution. This is not innovative, but progressive. This 
may share in the response, even to support it in adding smart patches 
over smart patches. But it cannot scale. IPv6, NATs, etc. are 
discussed, not routing, adressing, naming, signaling, transport, 
interoperability, interintelligiblity, infrastructure, 
structure/metastructure/multilingualisation, universalisation vs 
internationalisation, brainware, interoperating system, mobility, 
identity, authentication, store and forward/retrieve, layers, OPES 
and ONES, end to end, brain to brain, inculturation, basic/value 
added/extended services, innovation support, test beds, transitions, 
hybridism and convergence, authority, polylogue, architexts, 
networked languages, interlinks, access engines, network value, 
globality, operation management, economical model, etc. etc.

If the debate is not at that level it is an Internet maintenance and 
tuning IETF debate, not an IAB debate.
jfc

---

From: David Barak <[email-masked]>
Date: Sun, 19 Feb 2006 04:54:29 -0800 (PST)

> deploying something risky?

The motivation for deploying something new could also
be enhanced value-add services - you don't have to
lower costs if you can raise prices.  But I agree with
your salient point, which is that there does have to
be a motivating factor to entice people to deploy the
islands of new-style architecture.  

David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Jari Arkko <[email-masked]>
Date: Mon, 20 Feb 2006 13:34:56 +0200

Tony,

>	- We are willing to make changes.
I agree that we have real-world problems and problems
(or at least limitations and unnecessary weight) in current
solutions. I think there is willingness in the IETF community
to make changes.

But as Thomas noted, it would be useful to get to the
specifics:

o  I cannot speak about the events around GSE adoption
    in the IPv6 work, because I was not involved. But I
    would not assume that GSE or other proposals like that
    are today dismissed merely because the IETF has
    already shipped something. For instance, there was
    a discussion of a significant GSE security issue on
    this list some months ago. I do not know if such issues
    are fatal or if they can be fixed. My quick assessment
    is that its not trivial.

    The larger point is that while people believe in (I think)
    the locator-identifier split, the details do matter. And
    it would be easier to be in favor of proposals if they
    were complete. Not to pick just on GSE, there are
    issues in other approaches, too. HIP has issues with
    referrals, Shim6 is hard to deploy because you probably
    want something on the v4 side too, etc. And when
    you add everything that you wanted, what started
    out as a simple and clean proposal may look very
    different at the end.

o  I said that I believe the IETF has willingness for chance.
    But it is not enough for the IETF to do something, we
    also have to get the real world motivated enough to
    follow.

    (For instance, we already have a locator agile transport
    protocol.  It is being used, but only in specific applications,
    not in general Internet use by millions of end-users. And
    we  have technology to provide enough addresses to everyone,
    but while it is widely implemented, it isn't as widely turned
    on as we'd like.)

    The problem with motivation is that the rewards and
    costs associated with technology choices do not always
    map onto a single entity. The SIP application programmer
    feels pain, but the guy who decided to employ a NAT may
    be happy because it was easy for him. Or maybe both of
    them are happy, because they got their things up and
    running, and the end-user is paying for the bandwidth
    usage. Or we have tragedy of the commons.

--Jari

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Feb 2006 06:54:20 -0800

> 	- locator agile transport protocols

I agree that these are the most important infrastructure problems that 
needs more work.

> in the host), and various forms of tunneling.

I'm far from sure that tunnel and "architected NAT" are kludges; what 
matters the most is that the applications get sane behavior from the 
layers below, and that routing can scale.

> Until then, we have the status quo.

I suspect that many people are in the state of "it would be nice if we 
(or somebody else) could solve the identifier/locator split", but once 
we move into more details than that, it's harder to get any form of 
consensus.

For instance, so folks might view it as a requirement that the 
applications (and the APIs they use to access the network) can't change. 
Others might view that we can't require changes to routers. A third 
group of people might not want to see any mandatory changes to host IP 
stacks, because that's too hard to deploy.
If we take the union of those "requirements", then clearly nothing can 
change.

One way to untangle that is encourage parallel efforts that can make 
their own choices of what the wish to pick as their constraints.

Even if we can get past that part, and have one or more proposals for a 
better architecture, it is far from clear to me that anybody wants to 
"pay" the cost of the changes; I don't expect that will find some free 
lunch here, because if there was one we'd most like would have already 
found it.

Thus spending cycles on this set of problems is high risk.
Getting the IAB to somehow endorse that folks explore solutions to this 
set of problems can't hurt, but I'm not sure it will help very much either.

    Erik