In einer eMail vom 20.07.2008 03:14:58 Westeuropäische Normalzeit schreibt [EMAIL PROTECTED]:
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 By means of TARA (topology aggregating routing architecture): The more remote a link the looser it is, the looser the link the more stable it is, the more stable the link the less routing churn occurs, the less routing churn occurs the more time can be spent on dealing with practical concerns (i.e. OTHER practical concerns than the scalability problem which will be gone forever) Heiner
