Re: Weekly Routing Table Report
--- mohta@necom830.hpcl.titech.ac.jp wrote: From: Masataka Ohta <mohta@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
Scott Weeks wrote:
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
as I can't find open access papers or something like that there, let me stick to wikipedia.
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.
Another major misunderstanding of him is that he is not aware that domain name with MX is application name and there are proposals (though unnecessarily complicated) such as SRV to cover other applications beyond SMTP. With SRV, non-default port numbers do not have to be specified in URLs. So, we already have application names of domain names and mapping mechanism between names and addresses/port_numers of DNS.
E2E (end-to-end principle) is not relevant
That someone can not recognize relevance between something and the E2E principle does not mean much.
IPv6 is/was a waste of time
True, but, the reason is because IPv4 Internet with DNS, TCP and NAT is good enough. That TCP identifies connections only by single source and destination addresses is certainly a problem. But, the least painful solution is to extend TCP to be able to identify connections by multiple addresses. Properly designed NAT can save IP addresses a lot still keeping the E2E transparency.
The RINA's fundamental principles are that computer networking is just Inter-Process Communication or IPC,
That is a too much computer centric view not very applicable to communications involving human beings, where the E2E argument must often be applied to human beings (true end) behind applications (tentative end in a computer). Masataka Ohta
It is a 3-day weekend in the US. A good time to pause for a few minutes and consider what all of us accomplished together. Pat yourselves on the back, raise a glass or whatever your personal
Did we all forget the size of the IPv6 table is nearing a milestone number in the DFZ? ;) traditions are, and bask in the glory of a job well done. Patrick W. Gilmore (Okay pat the back of your local network engineer if you forgot.) Aclamaciones, Cheers, À votre santé!
Nowadays boxes can easily take 5x the current 768 in tcam and in control-plane -only sky is the limit, so for example there's no need for any clever RR infrastructure designs anymore to hold all the routes in your AS control-plane.
adamv0025 If you have an older router that can only handle x number of routes in TCAM less than the current number of routes; what software are you using to keep it default free? Or if the sky is really the limit, sell me your most or least expensive Tbps capable TCAM that will hold a routing table of 3M+ routes IPv4 and another 3M+ IPv6 without gimmicks or stipulations. (Low or high number of interfaces, small or god-sized box.) Let me know why you like what you have, or what you want to have. Be thankful for your network. What's in your rack? Good Luck On Sun, Sep 1, 2019 at 11:46 PM Masataka Ohta < mohta@necom830.hpcl.titech.ac.jp> wrote:
Scott Weeks wrote:
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
as I can't find open access papers or something like that there, let me stick to wikipedia.
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.
Another major misunderstanding of him is that he is not aware that domain name with MX is application name and there are proposals (though unnecessarily complicated) such as SRV to cover other applications beyond SMTP. With SRV, non-default port numbers do not have to be specified in URLs.
So, we already have application names of domain names and mapping mechanism between names and addresses/port_numers of DNS.
E2E (end-to-end principle) is not relevant
That someone can not recognize relevance between something and the E2E principle does not mean much.
IPv6 is/was a waste of time
True, but, the reason is because IPv4 Internet with DNS, TCP and NAT is good enough.
That TCP identifies connections only by single source and destination addresses is certainly a problem. But, the least painful solution is to extend TCP to be able to identify connections by multiple addresses.
Properly designed NAT can save IP addresses a lot still keeping the E2E transparency.
The RINA's fundamental principles are that computer networking is just Inter-Process Communication or IPC,
That is a too much computer centric view not very applicable to communications involving human beings, where the E2E argument must often be applied to human beings (true end) behind applications (tentative end in a computer).
Masataka Ohta
participants (3)
-
howard stearn -
Masataka Ohta -
Scott Weeks