Subject: Re: [arch-d] Defining terms

From: [email-masked] (Noel Chiappa)
Date: Mon, 20 Mar 2006 08:53:13 -0500 (EST)

> From: Fred Baker <[email-masked]>

    > Everything *can't* be done at the edge; for example, where do we do
    > routing? Not at the edge, and we in fact have a knee-jerk response
    > *against* having the edge involved in routing. 

I'm not sure exactly what you meant here, but please note that although we
do routing (path selection) in the network today, it doesn't *have* to be
done there; you *can* do routing (path selection) at the edge.

(I produced such a design, and I feel that for architectural reasons it
would be superior to do it at the edge, but I don't expect to see it in my
lifetime - and that's not a rhetorical device, I'm already almost 50.)

    > if multiple upper layer protocols require the same service and the
    > network layer is capable of delivering it, doing it once instead of
    > many times makes sense to me. 

Right - but that doesn't mean the network layer should do it. The added
functionality will make the network layer more complex, and applications
which don't need that capability will have to pay the price even if they
don't need it.

As others here have pointed out, the whole "layer" concept is the wrong way
to look at it. It's a modularized system, just like any other large system,
and we need to look at it as a module dependency graph, hopefully one
without any dependency loops (operating systems were the earliest to develop
this whole model, but it's common now).

So, yes, only implement that service once - but as a subsystem that other
subsystems can call on when they need it.

The only reason I can think off off the top of my head to make something
mandatory, and part of some low-level abstraction, is when you want clients
not to be aware that they are using it - e.g. paging (operating systems), or
mobility (networks) - so that clients don't have to do anything "unusual" to
get it, and so that users always have the capability, and the client
designer/implementor can't screw up and take that capability away from the
user.

	Noel

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

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 20 Mar 2006 15:42:37 +0100

>lifetime - and that's not a rhetorical device, I'm already almost 50.)

I do not know why. I am older and I saw it negotiated at the edge, 
and I do not see why I would not see it again on a large scale. 
Please let stop to consider the digital ecosystem as a unique space, 
with unique layers, and a unique technology. There can be multiple 
layer piles aside or on-top of each others. You just need a complete 
enough general model as I described to understand that.

Is your design documented on line?
jfc

---

From: John Day <[email-masked]>
Date: Mon, 20 Mar 2006 09:48:58 -0500

>designer/implementor can't screw up and take that capability away from the

So one creates a module to hide complexity of what is going on under 
the covers.  A black box. Granted.

For communications, this means that for the communicating black boxes 
in different systems there has to be some shared state for 
communications to take place.  Maybe not much, but some.  At the very 
least the communicating parties have to have share the ability to 
understand the communications.  Modules that do not have any shared 
state are not involved in communications by definition.

So we have a collection of things in different systems all 
cooperating with some amount of shared state and doing it in some 
black box to hide the complexity from the user of the black box.

Now of course, this collection of users can also cooperate to do 
something and provide a black box to their users.

So now, if these are not layers what are they?  pancakes?  waffles?

I would contend that layers are a means of organizing functionality, 
but have little to do with implementation.  But that is nothing new, 
we have known that for 25 years.  Although, if you *need* a boundary 
for some reason, some place a layer boundary is a good place to do 
it, if you have chosen your layers wisely.  Perhaps we have not 
chosen wisely.

Take care,
john

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/arcFrom [email-masked] Tue Mar 21 09:55:06 2006
Date: Mon, 20 Mar 2006 09:48:58 -0500
To: [email-masked] (Noel Chiappa), [email-masked]
From: John Day <[email-masked]>
Subject: Re: [arch-d] Defining terms
Cc: [email-masked]

>designer/implementor can't screw up and take that capability away from the

So one creates a module to hide complexity of what is going on under 
the covers.  A black box. Granted.

For communications, this means that for the communicating black boxes 
in different systems there has to be some shared state for 
communications to take place.  Maybe not much, but some.  At the very 
least the communicating parties have to have share the ability to 
understand the communications.  Modules that do not have any shared 
state are not involved in communications by definition.

So we have a collection of things in different systems all 
cooperating with some amount of shared state and doing it in some 
black box to hide the complexity from the user of the black box.

Now of course, this collection of users can also cooperate to do 
something and provide a black box to their users.

So now, if these are not layers what are they?  pancakes?  waffles?

I would contend that layers are a means of organizing functionality, 
but have little to do with implementation.  But that is nothing new, 
we have known that for 25 years.  Although, if you *need* a boundary 
for some reason, some place a layer boundary is a good place to do 
it, if you have chosen your layers wisely.  Perhaps we have not 
chosen wisely.

Take care,
john