How aboutan honest discussion that deals with the real causes of the scalability problem! Thescalability (size) issue only unveils how miserably bad the (most important)IETF routing paradigms are. Particularly: 1) DistanceVector A glimpseto intra-domain routing shows that there is an alternative. Brian’s statement“forget Dijkstra” is terribly wrong. Correct is: “simple Dijkstra is notenough”. After 6years discussion Geof Huston had to remind people that the RIB size is moreworrying than the FIB size. Millions of routes are being collected due togrowth and tighter meshing. Though not a single one needs to be collectedprovided though not a single one is really needed. DV eats up the storagememory and eats up the performance due to the amount of the update churn. Theimprovements achieved by LISP be acknowledged. But there are millions of useful(detouring) routes in addition which DV does not detect and will never be ableto detect. In addition, hereby TE is hampered in many ways. DV prevents havinga rearview mirror, i.e. it doesn’t provide the “upstream routes”. This preventsintelligent solutions for dealing with congestions and for balancing traffic ingeneral (avoiding congestions in the first place, time-of-day routing,…). Youcan only get solutions like re-ECN where the source is informed (!) who iseventually far away from the point of congestion and who has no knowledge aboutthe network and its current overall traffic situation at all. This is TE likeDiffServ: based on not-knowing what is going on outside. A lastpoint:The ISP business model. Yes, with DV an ISP may deliberately preventbeing used as transit by not forwarding its reachabilities to some non-payingneighbor-ISP. I.e. this comes for free. But question for the experts: And whatif that neighbor disbelieves him and sends him packets nevertheless? Imho,TARAwould be able to handle this business relation issue by means of additions theknowledgeable experts are invited to contribute. 2) Prefixbuilding Prefixbuilding is best in case you have no better solution.Pure TARA doesn’t need anysingle prefix nor any single AS number. However, for reasons of incrementaldeployment it would still need them with respect to those reachabilities thatare attached to non-TARA- routers. If some oneinsists on building prefixes that fits for routing he/she has to acknowledgethat E.164 is the best of all. Yes, it has good and bad implications: politicalones (= good and bad), administrationalones (ITU-T versus IETF; = neutral), Istanbul-effect (= bad) So far, theprefix building concept is the one and only reason for preventing fast next hopdetermination (applies to Dijkstra-based intra-domain AND DV-based inter-domainr.) i.e. for preventing Moore’s law applicability. It prevents any smarter FIB. 3)Multicast addresses More thanten years ago I sent an email to Scott Bradner comparing the multicastaddresses with the compartments in trains: both are relicts due to the past,there, because the first train would draw a few coaches, here because LANshave/need multicast addresses. Approx. a billion of addresses could be madeavailable for unicast (as to relax the Ipv4 address depletion problem) by meansof 1 Multicast-Protocol Type combined with the sender’s unicast address as toreplace the multicast address. In case the counter argument were “thisundermines all the deployed multicast solutions” then I would add “good so”(see next). 4)Multicast forwarding I heavilyquestion ALL existing multicast solutions. I am also wondering why multicastdoesn’t play any role at all in the RRG-discussion. My proposed solution wouldbe “cascade tree forwarding”, enabling state-less multicast to approx. 99,9 %of the involved routers. It is thecombination of all these holy cows which blocks the view to a brighter routingtechnology, where there is no discrepancy between intra- and inter-domainrouting, nor between CES and CEE, and where better technological tools wouldbe given to the hands of the next generation of students.
Heiner -----Ursprüngliche Mitteilung----- Von: Aaron Falk <[email protected]> An: IRTF Routing RG <[email protected]> Verschickt: Mo., 26. Apr. 2010, 15:21 Thema: Re: [rrg] RG futures Work in the IRTF is initiated, in general, by the folks who want to do it. Thus it is a more bottoms-up organization than the quotes below would imply (c.f RFC2014, section 2.2) and the RG leadership plays a key role. My role is to guide and provide oversight. So, I think Eliot is asking an excellent question: what does this group want to do next? It's *your* group (or at least, those of you who want to continue to collaborate). Are there no other research areas in routing that folks want to work on? --aaron On 4/25/10 11:04 AM, Ran Atkinson wrote: >> Eliot Lear originally wrote: >> >>> What do people want to do next with this group? >>> >> Scott Brim responded: >> Declare victory, put it to sleep, and let Aaron decide what to do with it. >> > RFC-2014 which is normative, indicates that the RG charter is a matter > for the IRTF Chair, IRSG, and IAB. > > RFC-4440, starting bottom of Page 2, specifically says: > The IRTF Chair is appointed by the Internet Architecture Board (IAB), > and charters IRTF research groups (RGs) in consultation with the > Internet Research Steering Group (IRSG) and with approval of the IAB. > > That says decisions about a future charter for this RG are in the hands > of the IRSG, IRTF Chair, and IAB, rather than being within the scope > of the RG itself. > > That seems entirely consistent with what Scott said. > > Ran _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
