Subject: Re: [RAM] First cut at routing & addressing problem statement

From: Thomas Narten <[email-masked]>
Date: Wed, 01 Aug 2007 09:14:39 -0400

JFC Morfin <[email-masked]> writes:

> At 22:24 31/07/2007, Thomas Narten wrote:
> >We intended the term "site" to be a fairly general term, one that
> >includes pretty much any topologically distinct thing that connects to
> >the internet. This includes home users. It is also NOT restricted to
> >just larger enterprises or ASes. We'll add a clarifying definition to
> >the document.

> Dear Thomas,
> I am sorry but "5. Provides meaningful benefits to the parties who 
> bear the costs of deploying and maintaining the technology." is an 
> error. What we want is to provide meaningful benefits to the users.

Sure. But if you provide benefits to users, but the cost of providing
those benefits is carried by others (who do not themselves see the
benefits), by what means does one actually force the cost on those
others? There is no free lunch. We can't make parties do things they
don't want to. One thing we should have learned by now is that forcing
others to bear unfunded mandates (to benefit another party) all to
often results in technology that simply never gets deployed.

So, if we actually want something to be deployed, it would be
advisable to have the technology be of a type that those who have to
pay the costs also see the benefit, so that they have incentive to pay
the cost.

Thomas

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Aug 2007 14:25:43 +0200

> We would welcome comments on the document. In particular:
> 
>  - Do folk agree with the problem statement as written, or are we
>    missing something fairly fundamental?

Yes. I think it's correct to keep it down to the bare bones.

>  - Are there other pressures on the routing system that we have not
>    listed or described completely?

Not that I noticed.

>  - We intentionally did not include improving mobility as a core
>    "problem", as explained in the document. (That doesn't mean we
>    don't recognize that some of the solutions under discussion may
>    also be applicable to mobility scenarios. Rather, we tend to see
>    improved mobility as a possible benefit of certain classes of
>    solutions.)

I think this is correct. In many ways mobility is an overlay
on a routing system assumed to be stable and scaleable.

>  - Are there other views of what folk perceive the core routing and
>    addressing problem to be?

Not here.

     Brian

---

From: JFC Morfin <[email-masked]>
Date: Sat, 04 Aug 2007 12:41:23 +0200

At 14:25 03/08/2007, Brian E Carpenter wrote:
>Content-Transfer-Encoding: 7bit
>

Fairly fundamental: yes.

- What an address is?
- UP as the User Protected address area. Any ROAP network centric 
solution will only meet the same problem which is user centric reality.
- all the discussed figures are based upon the source of the problem: 
number limited by constraints.

The solution must support billions of AS (real and virtual), routing 
planes. Every host must be PI-able.

>>    listed or described completely?

Just introduced a big one. TE must be possible by individual users.

>on a routing system assumed to be stable and scaleable.

I am afraid this is incorrect. Addresses must be defined first: as 
possibly made of a stable, mobile, and virtual part (parts in case of 
multilevel). If every host is considered for what it is: a virtual 
system hosted by a mobile machine plugged into a stable plug, the 
solution should be unique.

You can also phrase: address = PA + PI + UP. The problem is much 
clearer if these three spaces are made orthogonal.

>>    addressing problem to be?

Addressing and routing are not ex-nihilo. They happen in a real 
network context. The other missing point in the statement is the Plan 
(as in NIMROD but probably with an adjancy focus).

To understand this, let assume that a complete multi-level solution 
has been found, and there is no more problem. I will therefore have 
access to a certain level of TE, as a user, an ISP, a Government, of 
the IGF. I will then be able build the plan of my own virtual network 
infrastructure, and develop an higher level ROAP (routing addressing 
planning system) atop of it. This solution may in turn scale into 
higher virtuality levels. In doing this I would create a fractality 
break in traffic support: at some point [entering your solution from 
mine] the architectural vision changes.

I accept to bet it can work and that the whole thing can support the 
semantic networking layers I am interested in. But I doubt it will be 
optimal. So, it means that under the upper layers needs, the Internet 
layers solution will have to be adapted, leading to three 
simultaneous approaches (the current one, the solution to the current 
problem statement, the new approach needed by semantic network development).

This is why I suggested that one first considers the problems 
resulting from the current IETF paradigm, as summarized by the 
community two years ago in RFC 3935. Then consider which paradigm 
improvements (like for example switching from decentralization to 
distribution) could simplify or generalize the problem at hand.

jfc

PS. Some will probably disregard this post in claiming that it is a 
troll. Others will try to understand where I come from.

I consider four general communication layers: telecoms between 
devices, datacoms between agents, metacoms between brains, syllocoms 
within comprehension systems. I currently focus on metacoms as a 
support to syllocoms exploration. Network System theories seem to 
apply to them all as in any four successive network layers (along 
fractality and subsidiarity rules). Semantic networking is currently 
supported at the Internet layer (data) and at the metacoms layer 
(metadata) but in most of the cases as a layer violation (ex. RFC 
4646) because metacoms have not been identified as such by the IAB.

Inconsistency between these layers seems to translate, as for every 
other layers, by layer violations and rigidities. At its datacoms 
engineering level IETF should benefit from the IAB guidance to 
correctly position its work in such a generalized communication 
model. The problem ROAP translates is that the IAB does not build 
requirements from reality, but from consistency with the initial 
prototype. IAB/IETF tunes the network (RFC 3935: "make it work 
better") rather than build it.

I fully understand the need to keep the existing past solutions in 
tune with present needs. But not to the point to conflict with our 
future. I only make the capacity of the investigated solution to 
_also_ support the past as a validation criteria.

In the Multilingual Internet case, the problem was the confusion 
introduced by the RFC 4646 initial proposition (because it would go 
through due to its sponsors). It was therefore vital that its text 
and context be clarified and constrained. This was done (but 
unfortunately not respected).

So far, in this case I see no other bigger danger than delays for 
all. Two years ago I considered that IPv6 "UP" (see above) could be 
directly related to semantic addresses, giving them a universal 
common reference and an IPv6 killing application. ISO 3166-1:2006 
shown the simplicity and power of polynymy (concept name/address 
invariance across languages). This uncouples digital and semantic 
addressing (including its DNS part: I gave an example with cctags).

---

From: Eliot Lear <[email-masked]>
Date: Mon, 06 Aug 2007 11:57:04 +0200

Hi,

I have not had time to review the full document yet, but I do have some 
immediate comments.

In Section 3, 4th para, we *do* build routers to meet today's 
requirements and so it is unnecessary to ask a question that has already 
been clearly answered in the affirmative.

In Section 3.1, first para, the wording here leaves out the most 
important "must", which is that routers must process changes to the 
network topology.  Moreover, it leaves as quite murky as to whether the 
problem is in the forwarding path, the update path, or both, or whether 
this is dependent on design architecture.  I would personally like to 
see some performance numbers here.

In Section 4.3 first para, last sentence, given current discussions on 
RAM, I would make the following change for clarity:

OLD:
> However, each individual PI
>    prefix must be propagated throughout the DFZ and adds to the DFZ
>    routing load.

NEW:
> However, with the current BGP-based routing system, each individual PI
>    prefix must be propagated throughout the DFZ and adds to the DFZ
>    routing load.

Section 4.4 should reference (informationally) RFC 1627, where we first 
raised this concern 13 years ago.

Finally, in Section 6, I think we should add that it is desirable that 
those who multihome or make use of traffic engineering incur whatever 
associated costs.  This follows in part from your earlier business 
alignment discussion.

Eliot