Subject: RE: Some IPv6LL operational experience

From: "Bound, Jim" <[email-masked]>
Date: Sat, 23 Aug 2003 00:13:42 -0400

> you know, I'm really fed up with your misrepresenting my positions.

I not speaking to Mr. Hain for awhile but I feel the same.

The fact is that the WG believes this is important discussion.  Whether
Mr. Hain likes it or not.

/jim

--------------------------------------------------------------------
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: "Tony Hain" <[email-masked]>
Date: Sat, 23 Aug 2003 13:10:56 -0700

Bound, Jim wrote:
> The fact is that the WG believes this is important 
> discussion.  

It is an important discussion. There is a very critical architectural point
here, and it is being glossed over by 'the sky is falling' claims that apps
might fail, or have to do some work.

The architectural point is that IPv6 nodes support simultaneous use of
multiple dynamically acquired addresses per interface. This is a distinct
value over the capabilities of IPv4, as many failure modes arise from the
inflexibility of a single address at a time. 

The reality of the network is that different nodes will have different
perspectives of reachability for any given address. Some consider this
dysfunctional, others consider it a feature. In any case, as long as we
provide  a flag to indicate when there is a reachability discrepancy
(intentional or an artifact of network dynamics), there is an opportunity to
prioritize the list to achieve the app goals. 

> Whether Mr. Hain likes it or not.

There are arguments that apps should not ever be aware of topology. I
completely agree. Whether you like it or not, the current attachment point
of the end systems is topology information. If the apps require input of, or
choose to reach down and grab the attachment topology information to pass to
a peer, they have violated the premise that they don't know anything about
topology. This is not a function of my likes or dislikes, it is a simple
matter of technical fact. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Sat, 23 Aug 2003 16:47:48 -0400

On Sat, 23 Aug 2003 13:10:56 -0700

> might fail, or have to do some work.

Tony,

It's become clear that you don't know what you're talking about.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Sat, 23 Aug 2003 14:32:13 -0700

Keith Moore wrote:
> > It is an important discussion. There is a very critical 
> architectural 
> > point here, and it is being glossed over by 'the sky is falling' 
> > claims that apps might fail, or have to do some work.
> 
> Tony,
> 

On the contrary, I know exactly what I am talking about. The point of
attachment to the topology is topology information. Sounding alarms when
apps fail due to being passed incomplete topology information is nothing
more than claiming the sky is falling. 

Jim's example scenario was about passing LL's as literals to an app. LL's
are topology information about the current point of attachment. The
complaint was that the app would fail if it was not passed complete topology
information, by specifing which link the target was connected to. 

Your favorite examples are about multi-party referrals of topology
attachment points. Since we agree that the apps don't and shouldn't have
complete topology information, we also agree apps will fail when there is an
inconsistency in reachability for any topology attachment points passed as
literal values. 

Yet you continue to insist that passing around incomplete topology
information is not only valid, it is an inherent right of all application
programmers for all time. It is fine for you to have that view. It is not
fine when you use that view to prevent someone else from having a different
view about how apps should deal with the topological reality of
inconsistency. The network is not a flat, ubiquitous, consistent
environment, so passing around points of attachment to the topology is a
failing mode of operation. Insisting that we optimize for the fantasy
scenario of flat and consistent ubiquity, is not helping us deliver useful
technologies.

Tony

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Sun, 24 Aug 2003 06:56:45 +0200

> scenario of flat and consistent ubiquity, is not helping us deliver useful

Its something I can't put my finger on, but the though keep reapparing in
my mind.

You seem to say you use address and scope to talk to other nodes.

What is scope ? An integer ? An bit string ? A lamdba that evaluated
somewhere ? How is scoped compared ? How is scoped stored on network ? What
is the lifetime of a scope ? How is a scope a and a adress passed to a
nohter node ? How is scope and addresses handled in your name to address
system ?

Love

---

From: Keith Moore <[email-masked]>
Date: Sat, 23 Aug 2003 17:47:08 -0400

> > > It is an important discussion. There is a very critical architectural
> > > point here, and it is being glossed over by 'the sky is falling'  claims
> > > that apps might fail, or have to do some work.
> > 
> On the contrary, I know exactly what I am talking about. 

No you don't.  You've never written a multiparty app that has to cope with the
conditions you are trying to impose on apps.  If you had, you wouldn't be
dismissing the extra complexity required to do this as "some work" and you
wouldn't be dismissing the problems as Chicken Little claims.

For better or worse, the current TCP/IP architecture uses IP addresses as 
both attachment names and endpoint names.  That might be unfortunate, but
you can't fix this by dismissing the use of IP addresses as endpoint names as
inappropriate, declaring that the network no longer has to provide a coherent,
uniform view of addressing, and pretending that any lack of coherency in the
network is now the apps' problem to solve.   Moving the problem from layer 3 
to layer 7 doesn't solve it; it makes it more difficult to solve.

If you want to really fix this you need to create real endpoint
names, provide a fast and reliable layer of indirection between these names
and addresses, and change the transport protocols to allow them to use those
endpoint names instead of addresses.

Until those changes are made and deployed, it will continue to be perfectly
reasonable for apps to pass IP addresses around, and it's the network's job to
maintain a coherent view of addressing for hosts to use.  Even when those
changes are made, much of the responsibility for maintaining that mapping
layer must still lie with the network.