Subject: Re: Why?

From: [email-masked] (Noel Chiappa)
Date: Tue, 15 Mar 2005 13:19:17 -0500 (EST)

> From: Keith Moore <[email-masked]>

    > when that functionality requires having knowledge that is only
    > possessed by the network (which is what hosts need to do address
    > selection)

Rome wasn't built in a day. If you have a solution that requires pieces
A, B and C, saying you can't deploy one unless the others are already
deployed is a recipe for statis. Yes, "the network" does need to make
more info available to the edges, but that's another issue.

    > (you might make an argument for moving the functionality to the
    > edge of the network, but not all the way to hosts, and that
    > argument might be convincing)

In general, in these discussion I am not differentiating between "edge of
the network" and "hosts", because the important thing is that it's not
*in* "the network" - i.e. completely unavoidable by all users. Congestion
control was in "the network" in the ARPANet, and routing is still in "the
network" today.

Once you have moved things "out of the network", it's a second order
decision whether you do it in the hosts, or whether you have some
intermediate set of substrate (e.g. DNS) at the "edges" (from the point
of view of "the network") that does it.

(Note that the substrate is something which you may well also wind up
depending on for the proper functioning of the network - e.g. because,
let's be serious, if DNS dies, for most users, the network is dead.) 

	Noel

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

---

From: Keith Moore <[email-masked]>
Date: Tue, 15 Mar 2005 13:36:25 -0500

> If you have a solution that requires pieces A, B and C, saying you 
> can't deploy one unless the others are already deployed is a recipe 
> for statis.

it's not a matter of what is being said, it's a matter of what is 
required for things to work well.  or to put it another way, if your 
proposed solution requires pieces A, B, and C, but you don't even know 
how to build pieces B and C, there's a good chance you are on entirely 
the wrong track.

> In general, in these discussion I am not differentiating between "edge 
> of the network" and "hosts", because the important thing is that it's 
> not *in* "the network" - i.e. completely unavoidable by all users.

if you think in terms of the network, what you care about is whether 
this functionality is in the network.  if  you think in terms of hosts 
and apps, what you care about is whether this functionality is in the 
hosts.  to me, the important thing is that the routing functionality is 
NOT in the hosts.  whether it's "in" the network or at the edge of the 
network matters less to me, because no matter what it will have to be 
provided outside of the host.  or maybe there's room for an 
implementation at the border of the host and the network, especially to 
accommodate hosts with interfaces on multiple networks, but it needs to 
be feasible for single-interface hosts to work reliably without this 
functionality.

> intermediate set of substrate (e.g. DNS) at the "edges" (from the 
> point of view of "the network") that does it.

no, not "e.g. DNS".  there is essentially nothing about either the DNS 
protocol or the delegation tree or the infrastructure that lends itself 
to this task.

Keith