[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 at iab.org
https://www1.ietf.org/mailman/listinfo/ram