Subject: Re: [arch-d] Do we have "partial consensus"?

From: [email-masked] (Noel Chiappa)
Date: Wed, 13 Dec 2006 12:23:48 -0500 (EST)

> From: Pekka Nikander <[email-masked]>

Most of this I agree with; a few comments:

    >> We want to work towards an architecture with separate "layers" for
    >> "routing" and "transport", where "routing" is responsible for

    > I'm afraid we need to be more specific about terminology here,
    > unfortunately. Apparently we need to make a distinction between the
    > routing and forwarding functions

I agree, and this terminology distinction (routing/forwarding) is one most
people working on routers use. I like to use the term "path selection" for
"routing", though, because the latter term may not be clearly defined to many
people (just like "address") - some people see it as meaning "forwarding".
However, "path selection" can have only one meaning. "Forwarding" seems safe
to use as-is, though.

    > Conversely, it may be a good idea to call the forwarding/routing layer
    > as "internetworking" or the "network" layer, as it often has
    > traditionally been.

I would strongly resist calling it the "network" layer. I know this
terminology is a result of the ISO-7 model, but when one gets to things like
ATM and other networks, which have real and non-trivial protocols of their
own, not having a separate name for that network-specific stuff can be very
confusing.

So I have, for many years now (see, for instance, Section 7.1, "A New Layer
Model", in 'Endpoints and Endpoint Names') added an "internetwork" layer as a
new, *additional*, fully-fledged layer, in between the existing "network" and
"transport" layer in the ISO stack.

To do anything else, is, IMO, really badly misguided.

    > I'm still trying to figure out the transport functions and transport
    > names. From a larger point of view, I'm not convinced that we need a
    > "transport" layer with separate names.

I agree - but at the same time, we have the constraint that we don't have a
blank sheet of paper, and have to devise an evolutionary, interoperable,
path. Given that constraint, adding transport names (whether something like
HIP, or a recasting of existing IPvN "addresses") may be the best way forward
from here.

Even if we do name endpoints, we still need even more names at higher layers
(e.g. to name various aspects of communication with a server farm, where one
can continue an existing interaction even if the particular server one is
talking to drops dead - HTTP cookies do this now, really). So, yes, a
blank-sheet design would probably dispense with them - but we don't have a
blank sheet...

    > The "identifier" name space will be mainly used by applications and the
    > "locator" name space by routing and forwarding.

It remains to be seen how much use people would make of the routing-name
names, i) if they existed, and ii) if the path-selection system was less of a
"black box" over which the users have almost no control.

E.g. I personally like being able to select my path when I'm in my car, and 
I might do the same for some of my network traffic, too, *if I could*, which
I currently can not.

    >> is there a better name than "layers" for these problem spaces?

    > I'm afraid we first need to sort out the main namespaces and the main
    > functionality they are needed support. 

I agree, but it's worth pointing out that typically there is an association
between a namespace and a layer, so in thinking about these things, one is
almost necessarily thinking about both of them.

    > when thinking in terms of a "new" or clean slate architecture, I'm
    > afraid that so much of our current wisdom must be reconsidered that it
    > is probably a little bit too early to think in terms of layered
    > responsibilities.

Hunh! If we're really clean-slating, the first thing to do is ditch the whole
simplistic "layers" model, and go with the more general "modularization
dependency graph" (probably a tree, actually - see the references from
Section 7.2, "Layering and General System Modularization Principles").

    > I think it would be a big step forward if we could agree that we need
    > to separate the current IPvN namespaces into two "layered" name spaces,
    > the "lower layer" names being used primarily by the routing and
    > forwarding system and the "upper layer" names being geared primarily
    > towards the needs of applications and the legacy socket APIs.

My sense is there is now rough consensus on this point. Just to check this,
does anyone out there disagree with that principle?

(Actually, people might miss this, buried in the body of a long message. I'll
ask it separately, too.)

    > [Apparently, the NSRG couldn't agree on that, and I don't remember
    > having seen any announcement that any I* body would have agreed on
    > that.]

Please, I'd rather not delve back into history (much as some of it may still
rankle for me, privately :-). It's all water under the bridge. Let's focus on
what people think now.

    > Note that when asking for consensus on this, I am not *not* asking for
    > consensus on .. what would be the details of the "layered" namespaces,
    > etc. That is, I am not asking for consensus on *any* of the details.

Alas, I fear that the devil in this case is going to be precisely in the
details...

I remain dubious that any one approach will gain rough consensus, for a
number of reasons. (Although nobody will be happier than me if my gloom on
this point proves wrong, and we can agree.) For one, different solutions will
have different costs and benefits for different groups, and so each will
prefer the one that works best for them. For another, engineers (like most
people :-) always seem to have a stubborn attachment to their own ideas. Etc,
etc, etc...

Even if the I* comes in and knocks heads and choses Door A, that doesn't
necessarily mean that the vendors, customers, etc will all agree to go with
Door A.

So perhaps we can do nothing more than lay out a couple of options, and see
which one the market picks.

    > instead of trying to agree on a problem definition (since I think
    > producing it would be very hard), I propose that perhaps we could agree
    > on a general solution approach.

I agree. The process seems to favour creation of "requirements" documents,
but in practise they don't really seem to have been that helpful - and, as
you point out, in this case even production of that would be tricky. I think
it will be much easier to get people to sign up to the general approach.

Then we get to "how to actually do it", and that's where it's going to be
difficult. I suspect that a coalition of ISP's may have to come together and
pick a solution that works for them - since the driver for this, at base, is
going to be routing problems in the backbone.

      Noel

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

---

From: "tom.petch" <[email-masked]>
Date: Thu, 14 Dec 2006 10:49:48 +0100

----- Original Message -----
From: "Noel Chiappa" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, December 13, 2006 6:23 PM
Subject: Re: [arch-d] Do we have "partial consensus"?

> Most of this I agree with; a few comments:
<snip>
> (Actually, people might miss this, buried in the body of a long message. I'll
I agree with it and see it successfully done in legacy, proprietary networks.
The corollary is that you need a directory service to at least do the forward if
not the reverse mapping.  What I have never understood is why, in IP, it is the
lower layer address (IP) that is used by the upper layers (see for example the
analyses performed by v6ops in support of a change of format of the lower layer
address) when, in theory, a distinct upper layer address (DNS) is available.

Tom Petch

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 17 Dec 2006 09:53:28 -0500

> The corollary is that you need a directory service to at 
> least do the forward if not the reverse mapping.  What I have 
> never understood is why, in IP, it is the lower layer address 
> (IP) that is used by the upper layers (see for example the 

I brought this up early on this list.  This is one of my concerns this
will not scale for forwarding to look up in some name space directory
there is a required caching mechanism similar to DNS zone transfer or
X.500 transfers for the name space. Assuming a look up at each
forwarding point in a stack is not wise.  DNS to me I will say now is
not an option in my view.

/jim