On Jan 18, 2014, at 9:39 AM, heinerhum...@aol.com wrote: > Certainly, Lixia :-) > > And there are many more severe points to make for sure. Against LISP, against > IPv6, against many holy paradigms, and also against the general way to > proceed. > "Rough consensus and running code" has also its disadvantages, especially if > each taken step to improve creates a higher hurdle for the over next step of > improvement. > > > Heiner
Heiner, if your goal is to start a RRG discussion, here is my personal suggestion: moving from abstract statements to structured specifics would help get you moving, for example, listing your "more severe points", or describe through a concrete example what is the problem as you see with "rough consensus and running code". Lixia > -----Ursprüngliche Mitteilung----- > Von: Lixia Zhang <li...@cs.ucla.edu> > An: HeinerHummel <heinerhum...@aol.com> > Cc: tony.li <tony...@tony.li>; rrg <rrg@irtf.org> > Verschickt: Sa, 18 Jan 2014 7:04 am > Betreff: Re: [rrg] London > > On Jan 17, 2014, at 12:05 AM, heinerhum...@aol.com wrote: > >> Lixia, >> >> It was at the London 2002 IETF meeting when the request was raised to >> develop a new routing architecture. Concurrently it was added " there is no >> reason to rush, we will have a 10 years time frame for doing it". Well, >> meanwhile 12 years have passed and all we 've got is LISP which boasts to >> enable 52x10^27 EIDs per person but doesn't enhance the IPv4 address space >> not by one single address. Also, it is a concept which employs (bottle neck) >> servers which are vulnerable wrt. DoSA and perhaps even due to normal >> overload of queries and which creates a dependency of their clients which >> might cause a latent political threat by the owners of these servers for >> their (helpless) clients. >> >> IPv6 was certainly not meant by that request in London because it existed >> already at that time. And RFC 4984 §3 even warns that it would multifold the >> number of prefixes. And integrating AS-numbers seems not good wrt prefix >> building either. Also: 16 octets are provided and yet a E164 mobile user >> phone number is still needed outside of these 16 octets:-(. >> >> In the past I have asked many times to discuss the existing paradigms, and >> to question them ! Research is questioning the obvious! The too obvious! >> Like: Why are there two different routing concepts wrt intra versus >> inter-domain routing? I really would like to know why is Dijkstra bad for >> inter-domain ? Why isn't Distance Vector used in intra-domain routing? >> Why is there no Multicast-FIB ? Is it because it can't hardly be like the >> existing Unicast-FIB on the one hand side while on the other side a FIB must >> not be any different than the existing one? >> Lixia, why would you not necessarily agree with my technical specific of >> having a Multicast-FIB ? >> And also: What is the value of depending on prefix building in unicast >> forwarding? After all, it doesn't work wrt Multicast nor to Anycast (nor see >> above with AS#s) >> >> Another very fundamental point is what we expect a network layer to be/to >> look like/to handle/ to solve: >> >> It is not only me, it is the entire ITU-T which thinks that the network >> layer deals with the WHERE. With E164 routing and addressing are or at least >> have been identical: the next-hop trunk was selected electro-mechanically >> due to the next dialed digit. A routing protocol wasn't even needed. >> >> It is worth to have a look to the past. I am convinced, If there were not >> MPOA (but Cisco's Peer model instead) MPLS wouldn't have been developed. >> Without MPLS, being a strong push of IntServ, there wouldn't have been the >> counter movement DiffServ whose mantra is "do what Traffic Engineering >> wanted to contribute to SVCs/LSPs without knowing the network nor its >> current traffic load external to the waiting queue of incoming packets at >> any router And - imho - this mantra prevents any reasonable handling of >> genuine network layer objectives: like handling traffic congestions >> (avoiding them if possible in the first place dissolving them where needed). >> A network layer technology which has no idea, how to direct flows such that >> some would bypass the congested area to the left while some others to the >> right is not future prone. It is stupid and unknowledgeable!!! >> >> Heiner > > Hi Heiner, > > although your msg seems addressed to me, I believe you meant to bring up the > questions to the RRG, right? > > Lixia
_______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
