Weekly Routing Table Report

Mon Sep 2 00:05:09 UTC 2019

--- mohta at necom830.hpcl.titech.ac.jp wrote:
From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Scott Weeks wrote:

> I have been reading your posts on IETF and here regarding the
> above and I'm curious as to your thoughts on John Day's RINA.

As you give no reference, let's rely on wikipedia

https://en.wikipedia.org/wiki/Recursive_Internetwork_Architecture
--------------------------------------------------------

Yes, my apologies for no reference.  Further, I have no URL to
point to as I read the book. (actual book; no e-something)

Here's something:  http://pouzinsociety.org

Like the book, in the Wikipedia article you have to get through 
or skip the first part.  In the book, that's the first 5 or so 
chapters.  He just describes why, in his opinion, previous things 
have failed and the way he does it turns a lot of folks off.  
Likewise, I skipped the last 1-2 chapters.  So in the Wikipedia 
article skip to the Introduction" section.

A couple more things:

---------------
E2E (end-to-end principle) is not relevant

IPv6 is/was a waste of time

The RINA's fundamental principles are that computer 
networking is just Inter-Process Communication or IPC,
and that layering should be done based on scope/scale, 
with a single recurring set of protocols, rather than 
function, with specialized protocols.
---------------

------------ more from Wikipedia ----------------

The IPC model of RINA concretizes distributed applications in 
Distributed Application Facilities or DAFs, as illustrated in 
Figure 2. A DAF is composed of two or more Distributed Application 
or DAPs, which collaborate to perform a task. These DAPs 
communicate using a single application protocol called Common 
Distributed Application Protocol or CDAP, which enables two DAPs 
to exchange structured data in the form of objects. All of the 
DAP's externally visible information is represented by objects and 
structured in a Resource Information Base or RIB, which provides a 
naming schema and a logical organization to the objects known by 
the DAP (for example a naming tree). CDAP allows the DAPs to 
perform six remote operations on the peer's objects: create, delete, 
read, write, start and stop.

In order to exchange information, DAPs need an underlying facility 
that provides communication services to them. This facility is 
another DAF whose task is to provide and manage Inter Process 
Communication services over a certain scope, and is called a 
Distributed IPC Facility or DIF. A DIF can be thought of as a layer, 
and enables a DAP to allocate flows to one or more DAPs, by just 
providing the names of the targeted DAPs and the characteristics 
required for the flow such as bounds on data loss and delay, 
in-order delivery of data, reliability, etc. 

DIFs, being DAFs, can in turn use other underlying DIFs themselves. 
This is the recursion of the RINA.

scott

and restrict scope only for multihoming.

Then, it is true that:

 > 1972. Multi-homing not supported by the ARPANET.

which means current specifications do not support multihoming very well.

but, the statement

 > The solution was obvious: as in operating systems, a logical address
 > space naming the nodes (hosts and routers) was required on top of the
 > physical interface address space.

is wrong, because it is enough to let transport layer identify
connections based on a set of physical interface addresses of
all the interfaces, which is what draft-ohta-e2e-multihoming-*
proposes.

That is, he misunderstand restrictions by the current specification
something inevitably required by layering.

 > It tosses all this on its head.

If you have some text of RINA denying the E2E argument, quote it
with URLs please.

						Masataka Ohta