How about we stop discussing what we're allowed to discuss? Tony
|-----Original Message----- |From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf |Of Robin Whittle |Sent: Saturday, July 19, 2008 6:14 PM |To: Routing Research Group |Subject: [RRG] RRG scope avoids practical concerns | |Here are my thoughts on the current and recent scope of this |discussion list. | |It seems it doesn't matter much how compatible a potential solution |is with reality. As long we can discuss it in theoretical terms, |without getting into messy technical details, then it can be in |scope for the RRG. | |Meanwhile, we are not supposed to discuss potentially practical |proposals - or to discuss anything in the detail required to test |its compatibility with business needs, technical limitations etc. | | |We have been directed not to discuss actual proposals and to focus |on "architectural" issues (implicitly "higher level") instead of |"engineering": | | http://psg.com/lists/rrg/2008/msg01551.html (Lixia) | | > - my notion of the RRG task is to develop an architectural | > solution to routing scalability. | > | > - We should step up a level from looking specific versions of | > IP at this stage of solution development. Our solution has | > to be an architectural change, and should work for either | > version. | |Discussing LISP, APT, Ivip, TRRP or Six-One Router is out of scope. | | http://psg.com/lists/rrg/2008/msg01285.html (Tony) | | > Now, can we please stop discussing proposals? | |Mobility is out of scope for now: | | http://psg.com/lists/rrg/2008/msg00815.html | |The focus is on major change, to last "indefinitely" - "effectively |forever", rather than "band-aid" approaches: | | http://psg.com/lists/rrg/2008/msg01559.html (Tony) | | > It seems likely that if we do in fact make a shift to v6, then | > it would be effectively forever or at least long enough to | > exceed the life span of anyone currently on the mailing list. | > I'd very much prefer that we left our grandchildren something | > that we could all be proud of. | |and a "clean" approach: | | http://psg.com/lists/rrg/2008/msg01564.html (Tony) | | > My version of 'clean' is much strong than just meeting the | > design goals. It also has to do with complexity, overhead, | > fit, and harmony. | |But this does not suit people who want to discuss IPv4, IPv6 and |clean slate proposals in parallel. | |IPv4 and IPv6 solutions are in scope: | | http://psg.com/lists/rrg/2008/msg01539.html | |however discussions are to be directed towards an IPv6 solution, |with perhaps an IPv4 solution as a secondary consideration: | | http://psg.com/lists/rrg/2008/msg01535.html | (Tony - rough consensus 2008-05-13) | | > |Our recommendation should be applicable to IPv6. It may or | > |may not also apply to IPv4, but at the very least must provide | > |a path forward for IPv6. | > | > It's my judgement that we have rough consensus on this. There | > is dissent, notably from Robin and Bill, but overall, it seems | > that we have rough consensus. | | | http://psg.com/lists/rrg/2008/msg01559.html (Tony) | | > If we do find something that is both clean AND can be | > back-ported to v4, I would definitely support that. | |Yet there is insufficient attention to the differences between IPv4 |and IPv6: | | http://psg.com/lists/rrg/2008/msg01551.html (Lixia) | | > IPv4/v6 share the same architecture; the only major fundamental | > difference is their address space size. | > | > Our solution has to be an architectural change, and should | > work for either version. | |There are immense differences between IPv4 and IPv6 when it comes to |developing a scalable routing solution. IPv6 has a much lower |installed base, much greater address space capacity, 4 times the |number of bits to play with etc. | |The address differences make Six-One Router potentially practical |for IPv6 and completely impractical for IPv4. The address length |differences mean that map-encap schemes have a much higher |encapsulation overhead for IPv6 than for IPv4. Six-One Router has |no such overheads. (I am not convinced the IPv6 solution must be in |principle the same as the IPv4 solution.) | | |Recently Heiner, Iljitsch and Tony have promoted discussion of |geographically aggregated addresses. This is a scalability fix |which requires ISPs and end-user networks behave as if they did not |need certain things they do need - in order that the routers have an |easy task. | | http://psg.com/lists/rrg/2008/msg01815.html | (Bill showing Heiner's proposal can't meet business needs.) | | http://psg.com/lists/rrg/2008/msg01829.html BH | http://psg.com/lists/rrg/2008/msg01859.html RW | |Tony perhaps admitted that geo-aggregation was more of academic than |practical interest: | | http://psg.com/lists/rrg/2008/msg01860.html | | > My point was an academic one: if it was possible to get some | > degree of multi-lateral cooperation from providers, then | > geo-aggregation at a very coarse level with relaxed rules is | > _technically_ feasible. | |Geo-aggregation is technically feasible because it is a technical |no-brainer. There is no need for new engineering - either new |router functions or any overlay network such as map-encap or |translation (Six-One Router) schemes etc. | |Geo-aggregation couldn't be applied to IPv4, so this is a scheme for |a radically revised IPv6, or a clean-slate architecture. So it |could only help with the routing scaling problem if we could wean |most users off IPv4 onto a completely new and incompatible Internet. | |All the work of geo-aggregation is in the fields of mathematics, |address administration and in marketing/enforcement - somehow |convincing all ISPs and end-user networks to adopt its onerous |restrictions on addressing, connections between networks, the |traffic they need to handle for other networks etc. This last |aspect is and will surely remain impossible. | | |So the fact that a proposal is completely impractical is not a |problem for the RRG. | |The fact that discussions involve real technical details - as does |any useful discussion of LISP, APT, Ivip, TRRP, Six-One Router etc. |- IS a problem for the RRG. | |It is apparently fine to discuss things on the RRG list as long as |we steer well clear of the messy details of how something would work |in the current version of reality. | |The RRG's scope prevents us from discussing IPv4-specific solutions, |despite the facts: | | 1 - The IPv4 Internet is the only Internet with a routing | scaling problem. | and | 2 - IPv4 is the Internet which is relied upon by all users. | | |So I think the RRG list is not suitable for discussing the practical |aspects of any proposal, or any proposal which is directed to |solving the IPv4 problem soon and to solving any IPv6 problem if and |when one occurs. | |Meanwhile, time ticks by, the DFZ routing table keeps on growing: | | http://bgp.potaroo.net | |TCAM FIB routers become obsolete: | | http://psg.com/lists/rrg/2008/msg01851.html | |or at least very tricky to use in the DFZ. | |The March 2009 (RRG reporting deadline) approaches and we have |achieved consensus on next to nothing. | | |The RAM list is closed: | | http://www.ietf.org/mail-archive/web/ram/current/msg01895.html | |and discussions beyond the scope of the RRG are directed to the |architecture-discuss list: | | https://www1.ietf.org/mailman/listinfo/architecture-discuss | |which has had no substantial activity since 2007-05. The scope of |architecture-discuss specifically precludes discussion of the sorts |of details which make or break actual solutions: | | Discussions that drill down and dwell on specifics of | individual protocols or technologies are to be discouraged, | redirected to appropriate other fora, or re-cast to | discussions of broader implications for Internet architecture. | | |This is the state of discussion lists which concern the fascinating |and immensely important question of how to restructure the |Internet's routing and addressing system. | |There seems to be an overly strong focus on high-level |"architecture" at the expense of practical, engineering matters. | |I think discussion needs to involve all these levels. Architecture |without sufficient attention to engineering detail often results in |buildings which look "good" (however defined) on the outside, but |with heating and cooling systems which don't function properly, |which are difficult to maintain, with exteriors which become tatty, |and which may not meet the needs of the occupants. | |Network architecture without sufficient attention to backwards |compatibility leads to systems which are far too poorly adopted to |make a difference to the routing scaling problem, e.g. IPv6. | | |Maybe clean-slate discussions and those concerning proposals which |are inherently impractical (geo-aggregation) should be on a separate |mailing list from those concerning proposals which are meant to be |practical for IPv4 and IPv6. The IPv4 and IPv6 discussions are |related, and constrained by reality - but clean slate and |theoretical discussions are not so constrained. | |I regard radical revisions of IPv6 - such as changing to GSE or |geo-aggregated addressing - as having the serious adoption hurdles |which are typically found with "clean slate" designs, without the |potential benefits of starting afresh. | | - Robin | | | |-- |to unsubscribe send a message to [EMAIL PROTECTED] with the |word 'unsubscribe' in a single line as the message text body. |archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg | -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
