Re: RINA - scott whaps at the nanog hornets nest :-)
--- dot@dotat.at wrote: From: Tony Finch <dot@dotat.at> : I note that he doesn't actually describe how to implement : a large-scale addressing and routing architecture. It's all : handwaving. There is more discussed in the book. The paper was written by another person and had to only hit the highlights, or it'd be too long for folks to want to read. I'd imagine you can get a copy of the book in a university library. :And he seems to think that core routers can cope with per-flow state. Can you elaborate for me? : The only bits he's at all concrete about are the transport : protocol, which isn't really where the unsolved problems are. It wasn't about just solving problems. It seems to me to be about if you could clean-slate design, what would you do? AFAICT the RRG folks are specifically focused on fixing problems: map-n-encap and tunneling being the most liked solutions. One similar thing to other proposals on that list, though, that has me wondering is the use of a 'server' in the middle to keep track of everything. scott
On Mon, 8 Nov 2010, Scott Weeks wrote:
From: Tony Finch <dot@dotat.at>
: I note that he doesn't actually describe how to implement : a large-scale addressing and routing architecture. It's all : handwaving.
There is more discussed in the book.
I have bought and read the book. It's an interesting and entertaining rant about the protocol wars, but still far too vague about proposing solutions for our current pain points. Argiung about TCP vs. Delta-T is a very long way from the problems that need solving. My comment stands.
:And he seems to think that core routers can cope with per-flow state.
Can you elaborate for me?
Perhaps I don't understand how connection-oriented networks work. How do you reserve bandwidth for a connection with guaranteed quality of service without establishing state on every router in the path? How do you do it in a network that spans multiple organizations? What connection-oriented inter-domain protocols have had widespread deployment?
It wasn't about just solving problems. It seems to me to be about if you could clean-slate design, what would you do?
If your lovely clean architecture can't solve problems why should anyone pay attention to it? A clean slate architecture needs to synthesize what we have learned from practical experience and add a dose of cleverness so that problems can be solved much more easily. A simple mostly-unrelated example: in the 1980s hypertext systems had links that were bidirectional and they made an effort to keep them consistently maintained. This made it impossible to have an inter-domain hypertext system. The WWW discarded the requirement for consistent bidirectional links, so it was not "proper hypertext". Even so, because it does not require co-operation between the ends of the link, it rapidly outgrew any previous hypertext system. The point of a clean slate design is to rethink the foundations of your architecture, and get rid of constraints that set you up to fail. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD.
participants (2)
-
Scott Weeks -
Tony Finch