[ppml] "Recommended Practices" procedure

[Michel Py]

Marla,

> Marla Azinger wrote:
> However, I also believe policy can change.

So do I, otherwise I would not support 2005-1.


> So why shouldnt this policy just be motivation to make shim6 work?

Keep in mind that I _do_ support this policy, the short answer is that
it's wishful thinking too little too late, read below for full
rationale.


The way I see 2005-1 is as follows:

1. The decision to allocate PI is an engineering decision, not a policy
one. ARIN is stepping on the IETF toes doing this.

2. The IETF has failed to deliver an IPv6 multihoming solution for 11+
years running, which is precisely why ARIN has put 2005-1 in last call.

3. There is risk involved with 2005-1, but this risk is manageable. I
don't believe PI prefixes handed out by 2005-1 can ever be reclaimed,
but the policy can be changed back as you pointed out.
To those who scream about early adopters getting an unfair edge, I say
this: early adopters take risk and spend money late adopters don't; IPv6
desperately needs early adopters, having a PI block does not pay for the
risk and the spending, shut up.
Besides, many organizations already have a PI block, and those who don't
can easily lie about their needs and become a LIR if they want one bad.

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".


So far, so good. But now here are the catches:

>> So why shouldnt this policy just be motivation to make shim6 work?

> 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


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.

Let's say a) and b) could eventually be solved. Remains to be seem
though.
c) and d) are structural design issues that are deliberate design
choices. No changes to shim6 can make operators happy with TE issues
neither could they convince enterprises that multiple PA addresses per
host is a supportable solution.


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.



> So why shouldnt this policy just be motivation to make shim6 work?

You're sending the wrong message to the IETF. Shim6 is not economically
and politically deployable given the current conditions. I can't speak
for Mike O'Dell WRT GSE, but I can speak for MHAP and it's not
economically and politically deployable given the current conditions
either.

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

Michel.