[ppml] "Recommended Practices" procedure

> 4. Regardless of the technical merits, 2005-1 is good for at least one
> thing: it sends a strong message to the IETF saying in substance "In
> case you have not noticed, it's about time to stick your head out of
> somewhere and actually deliver something that could be accepted by both
> the op community and the end customer".

No, it sends quite the opposite message. It says, in effect, "Hey, aside from
your strict topological addressing plan, that ipv6 stuff is good enough for
us. So we'll just ignore the only thing that makes ipv6 routing scale and
deploy it anyway".

And no, I do not think that ipv6 is deployable with strict topological
addressing (as the IETF naively specified) because the whole concept of an
"address" is hopelessly non-scalable in ipv6 (and in IPv4, for that matter;
but I think we have consensus that IPv4 won't scale into the next century).

If you open the Pandora's box of "PI addressing" instead of demanding a
scalable routing architecture, the game is over.

> Catch #1: the reasons shim6 has been rejected is because many
> technically enabled persons have assessed that it can _not_ be fixed
> (whatever it means by their criteria) by fine-tuning it. Shim6 has 4
> major issues:
> 
> a) It's not finalized yet.
> b) No real-world implementation.
> c) TE nightmare.
> d) Requires multiple addresses per host.

Actually, the major issue with shim6 is that it is attempting to build
implementation "upgrades" to work around a fundamental architectural flaw.
Basic design/engineering practice sugegsts that this won't result in an
elegant, non-complex, or deployable solution. Trying to design shim6 without
fixing (incomatibly changing) ipv6 "address" semantics was pretty much a lost
cause from the start if such a solution was the goal.

> Catch #2: the IETF has noticed; they do not need your reminder neither
> motivation. I personally know, have met several times, and have a
> profound respect for many of the individuals involved there. I
> personally think that two or three are completely full of it and I
> disagree with score of others; that being said, and contrary to some
> conspiracy theories, and acknowledging that the IETF has some
> shortcomings and limitations, the fact of the matter is that the IETF is
> not this evil entity that tries to screw ARIN or somebody else. As said
> earlier, the IETF has failed to deliver an IPv6 multihoming solution but
> it's certainly not because they have not tried.

The solution space was too constrained for the multi6/shim6 effort to have
a realistic shot at success. Once a decision was made not to modify ipv6
protocol semantics (out of concern for the vast installed base that existed
when multi6/shim6 started), the solution was virtually guarenteed to be
complex, ugly, and of limited value. Again, basic design/engineering
practice.

> The way out of this mess is a BGP replacement that could handle
> large-scale PI.

BGP isn't the issue and devising a replacement for BGP doesn't attack the
fundamental problem.

Co-mingling endpoint identification and topological location pretty much
guarentees that the single number space that you use for "addressing" can't
provide both the flexibility (proof against renumbering) and scalability
(routing that can be summarized at abstraction boundaries) that you want.

	 --Vince