Re: [RRG] RRG scope avoids practical concerns

In einer eMail vom 20.07.2008 03:14:58 Westeuropäische Normalzeit schreibt rw@firstpr.com.au:

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