[ppml] "Recommended Practices" procedure

[Michel Py]

>> Michel Py wrote:
>> 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.

> Marla Azinger wrote:
> I am curious though.  The way you view Shim 6 and its
> creations/workings is very dire.

BTW I'm not the only one that views it that way; 2005-1 is in last call
to provide PI instead, meaning the majority of the ARIN community
considers shim6 not to be a viable solution. Besides, it's not dire,
it's realistic. Shim6 is the last multihoming option the vast majority
of enterprises would deploy; it's the result of over 10 years of work in
the IETF. If it is not fixed by now, what makes you think that it could
be fixed later? How many more years?


> This suggestion only addresses PI.  Why is everyone stuck on PI?
> There are large networks that need these capabilities (multihoming)
> as well.  We need solutions that enable Upstream Providers to
> employ multihoming as well.

The only difference between an organization getting a PI block from ARIN
or a PA block from ARIN is the name. 2005-1 removes the hypocrisy that
organizations that are not ISPs and want to get a PI block will call
themselves a LIR, distribute 200 /48 blocks to their buddies and
employees and be left with 99.99% of what has a striking resemblance
with a PI block.


> But the "perception" that I am left with over the years is that the
> IETF seems a bit unreachable. Yes, this is partly because I have not
> had the money or priviledge to attend an IETF conference

I have attended several IETF meetings on my own time and money, and I'm
not the only one. As of being unreachable, I do not agree either. If you
have something worthy to contribute, you can do it on mailing lists. As
Owen said though, it does take a lot of time.


> So to hear you say they dont need my reminder or theory of motivation
> is disheartening, but from where I sit my perception is that they do.

You underestimate the difficulty of the problem. If you had spent months
or years trying to solve this issue you would not think like this.


> We need to take action now, not sit in silence hoping
> this nightmare passes us by.

I'm sorry to break your heart but you're a few years late.


> Owen DeLong wrote:
> However, there are other solutions. We need to
> go back and re-examine true ID/LOC splits.

<ego>
Music to my ego's ears, as he truly thinks he has produced the best
ID/LOC so far. Better than 8+8 and GSE.
</ego>
I'm curious though, what makes you think that solutions that were
discarded years ago are suddenly going to become the next best thing?
The people that shot them in flames are still there; besides, they were
far from perfect and at least half of the reasons that made the op
community discard shim6 are valid for ID/LOCs as well.

> Doing it with an extension header would be
> harder on the silicon engineers

They won't do it. This is one of the many things we discussed in ipv6mh
meetings; a Spaniard from Marcelo Bagnulo's team came up with an idea
involving headers; we had Fujitsu and Cisco and they said with a large
smile that a new header in hardware could be considered, especially if
someone happened to give them a few hundred million dollars to develop
it. Nice try, no cigare. Owen, we worked years on this thing.


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

Wrong, wrong.

Q: Why don't we give IPv6 PI to everyone?

A: Because IPv4 PI was bad, so IPv6 will be bad.

Q: Why was IPv4 PI bad?

A: Because they were too many prefixes in the GRT.
   Among other things, this led to:
   a) Costly RAM upgrades.
   b) BGP routers going bezerk when large number of routes flapped.

Q: Is IPv4 PI still bad?

A: Not as much as it used to be, as router power has increased
   faster than the number of prefixes.

Q: Why will IPv6 PI be bad?

A: Since the RAM upgrade issue is now mostly irrelevant, the fear is
   that we don't know how many prefixes we can handle [if we give PI
   to everybody] before routers go bezerk again because the BGP
   process can't handle large route flaps.

It's not a BGP problem you said?


The bottom line is: keeping BGP as-is has the same appeal to router
vendors as PA-only has to established operators. Keeping BGP as-is is
the guarantee that there will be a need for updates as the routing table
grows. That's why now they're lobbying to exhume unproven/never deployed
ID/LOCs from the grave instead of working on a scalable version of BGP
that could also have features such as secure interface to the RIR's
databases so we could filter bogons and prefix hijacks right of the bat.


> IETF is definitely not ignorant, but, it is
> overweighted with vendors

> <vaf at cisco.com>
> BGP isn't the issue and devising a replacement for BGP
> doesn't attack the fundamental problem.

:-D

Michel.