[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RRG] RRG scope avoids practical concerns
How about we stop discussing what we're allowed to discuss?
Tony
|-----Original Message-----
|From: owner-rrg@psg.com [mailto:owner-rrg@psg.com] 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 rrg-request@psg.com 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 rrg-request@psg.com 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