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

At 14:25 03/08/2007, Brian E Carpenter wrote:
>Content-Transfer-Encoding: 7bit
>
>>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.

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.

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

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

>>  - 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.

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.

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

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).

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram