On 4/25/06, <b class="gmail_sendername">Howard, W. Lee</b> <<a href="mailto:Lee.Howard@stanleyassociates.com">Lee.Howard@stanleyassociates.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

I've made some changes to this message:<br>I removed other mailing lists.  I'm not a subscriber.<br>I changed to plain text formatting.<br>I tried to focus on ARIN public policy proposals.<br><br>Matthew Petach wrote:<br>

> > dynamicity.  Huston's study indicated that there are folks whose BGP<br>> > announcements flap (due to TE) intentionally 1000's of times a day.<br>> BGP flap dampening is already well understood for limiting the impact

<br>> of flapping routes on your CPU, if that's a concern; it has no bearing<br>> on address allocation policy decisionmaking.<br><br>Dampening works, for the value of "works" which equals "suppressing new

<br>(better?) information about the path to a network," which is often equal<br>to "misrouting data because a new path was not calculated."  If,<br>following<br>this proposed policy, aggressive dampening becomes commonly required by

<br>operators to maintain their networks, it might have a bearing on support<br>for this policy.</blockquote><div><br>Concern was raised about end networks changing routing state too quickly<br>for modern CPUs to handle; the way we handle that today is to dampen

<br>successive transitions once they reach a certain threshold level.  I see no<br>reason why the current mechanism in use today in the IPv4 world should<br>not work just as well on the IPv6 network.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

> pool.  The policy cannot allow itself to be shaped by the<br>least-capable<br>> routers, or we'll be chaining ourselves to the past,unable to make<br>adequate<br>> forward progress so long as there's any network out there that's still

<br>running<br>> old hardware that's unwilling to upgrade.<br>> I agree we need to be reasonable--but please, let's not "dumb down"<br>the<br>> v6 internet just because some people aren't willing to step up to the

<br>plate and<br>> upgrade their routers when needed.<br><br>For values of "unwilling" approaching "unable."  As the number of<br>prefixes<br>approaches infinity, and the beta cycle (or dynamism) approaches zero,

<br>the<br>CPU required will approach infinity.  Even if you decide to recalculate<br>routes once a month, memory requirements increase, potentially beyond<br>what<br>current or foreseeable routers can handle.  Yes, this is a reductio ad

<br>infinitum argument; the trouble is that there is not common agreement on<br>what the break point is, or how fast it might approach.<br><br>If it takes six months of testing to be confident in a new core router,<br>and you replace 5% of your routers every week, and you ignore all other

<br>maintenance, you could replace your core in a year.  Another year for<br>distribution and edge.  Any other kinds of devices take another year,<br>for testing and rollout.   That's assuming you employ as many engineers

<br>as needed, and ignore other work.<br><br>I certainly don't mean you have to agree that these issues should be<br>paramount in policy-making, but I think that before being ignored, it<br>should be acknowledged that otherwise competent operators potentially

<br>have a serious problem.</blockquote><div><br>The point I was making is that if we limit IP allocation policies<br>based on hardware upgrade cycles, we shackle ourselves to <br>the ISP that decides that they should be able to run just fine

<br>with their IGS or AGS+, and therefore no additional prefixes<br>can be allocated because they're unwilling _or_ unable to<br>upgrade.<br><br>If we start putting limits on what can be assigned due to <br>concerns about what some providers may be unwilling to 

<br>upgrade in their core, are we also going to entertain <br>proposals to limit IPv4 allocations so that those selfsame <br>providers won't have to upgrade their IPv4 routers either?<br><br>Let's be realistic.  We don't have any limits on how much

IPv4 deaggregation we'll support, we just trust the routers to scale up to support the growth--why are we attempting to treat IPv6 differently?  Do we not expect IPv6 to take  over for IPv4 in the forseeable future?

<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Provider independence is here already, period.  It's too late to try<br>to put

<br>> the horse back in the barn<br><br>I don't understand what you mean here.  Do you mean "policy proposal<br>2005-1<br>is in last call and I believe it will be approved"?  The last call part<br>of<br>the process exists for a reason; the AC will review comments about

<br>2005-1<br>before deciding whether to promote the proposal.  Or are you talking<br>about other regions, which set their own policies?</blockquote><div><br>I mean 'In the IPv4 internet of today, multihoming is a fact of

<br>life, and is expected by businesses.  If IPv6 is ever intended <br>to be more than an academic mastubatory exercise, the<br>policies associated with IPv6 allocations will need to support<br>a similar or better level of provider independence for businesses

<br>as the existing IPv4 allocation policies.'<br><br>To that end, yes, I support 2005-1.  I anticipate it being approved. <br>If it is not approved, and none of the other possible proposals<br>for IPv6 multihoming for enterprise networks are approved, I

<br>see no reason to think that IPv6 will ever be used as anything<br>other than an experimental protocol utilized by small groups<br>of researchers.<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

> Trying to stop provider independent addressing in IPv6 is simply<br>another way<br>> of saying 'IPv6 addressing is broken, let's just stick with IPv4<br>instead' -- because<br>> that's what the practical outcome is.

<br><br>Are you asserting that IPv6 is, or is not, "broken"?  Is a PI policy<br>like 2005-1 intended to "fix" IPv6 or is it simply meeting the original<br>requirements from the IETF?</blockquote><div><br>

IPv6 without provider independent allocations is broken, and will never be widely adopted.  2005-1 is one possible suggestion on how to fix it.  I support 2005-1 as a well thought out means to fix an otherwise broken protocol.

<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Any addressing scheme that tries to<br>> deny the need for provider independent addressing is less capable for

<br>> businesses than what they have today in the IPv4 world, and will<br>therefore<br>> not be used.<br><br>Interesting assertion.  In the context of 2005-1, which provides<br>specific<br>"bridles" to use your metaphor, are you suggesting it should move

<br>forward,<br>or not?  Whether it is too permissive or too restrictive is another<br>interesting question, but doesn't sufficiently inform the process.</blockquote><div><br>Yes.  I have previously stated on other threads, and will 

<br>continue to state that 2005-1 should move forward, or if<br>there is sufficient concern about wording, that one of its<br>progeny or siblings should move forward; but without<br>some form of provider independent allocation scheme

for non-ISP multihomed networks included in the IPv6 allocation policy, IPv4 will continue to be the dominant network platform, and no level of critical mass will be reached to support widespread IPv6 deployment.

<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> So.  Given that PI allocations are going to happen in IPv6 just as<br>they have in

> IPv4, When you say, "just as they have in IPv4," what do you mean?  Do you mean, "any applicant in the first ten years will get one with little justification, and anyone after that will have to provide documentation of their need"?

<br>2005-1 isn't identical to IPv4, but uses IPv4 as its basis.</blockquote><div><br>I think 2005-1 is sufficiently similar to the current IPv4 allocation<br>system for my language to be applicable.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

> I *do* agree that stipulating that only the largest possible aggregate<br>assigned<br>> to a given AS *should be* announced by the AS is a reasonable addition<br>to<br>> the policy to help encourage aggregation, and prevent stupid routing

<br>mistakes<br><br>In this context, do you oppose 2005-1 since it lacks such a<br>recommendation?<br>If this is an RFC2119 "should" then can the policy stand without it?</blockquote><div><br>No, I don't oppose 2005-1 as it stands.  I'm tossing out an idea

<br>for an addition that might help those who live in fear of route<br>table expansion feel more comfortable with it.<br>Strictly speaking, though, even with no changes, no amendments,<br>no adjustments, I think 2005-1 is more than adequate, and can

<br>be approved as it stands without fear of the internet melting down<br>due to its adoption.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

> I don't see why the discussion is dragging out for so long.  This<br>isn't rocket<br>> science.   Let's just nail the policy down, and move on with more<br>productive<br>> work.<br><br>Is that a statement for or against 2005-1?

</blockquote><div><br>Yes.  I am hoping to see IPv6 become something other than<br>a theoretical protocol developed as an amusing experiment;<br>therefore, I support 2005-1.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

As to your statement about rocket science. . . developping consensus<br>among<br>people with opposite perspectives is distinctly difficult.  I've never<br>tried rocket science, but I know of some nuclear physicists who find

<br>consensus-building to be challenging.</blockquote><div><br>That's nice.  If we don't come to consensus and move<br>forward, this rocket is never going to lift off.  And if IPv6<br>doesn't take off, then we'll see some *real* challenges

<br>when IPv4 space starts getting scarce, and the black<br>market for v4 space starts to solidify.<br></div><br>You're worried about routing table growth in IPv6?  Imagine<br>what it'll be like when v4 space runs out in 5-8 years and

suddenly those nice class A aggregates are being sliced and diced into /22 sized chunks for everyone screaming for provider independent, routable space.  Suddenly, supporting PI space in IPv6 won't seem that bad.

The same routing table slots are going to get used, period; all we're discussing here is whether we set up the policy such that they can be used for IPv6 routes, or if we force them to be used for IPv4 prefixes.

<br><br>I'm supporting 2005-1 because I'd prefer to see those<br>prefixes handled on the IPv6 internet.  It sounds like<br>you'd prefer to say 'no' to IPv6 PI space, and instead<br>have your routing slots consumed by IPv4 prefixes

<br>instead, and that's certainly your choice.  I'm just<br>trying to point out why I think it's a more short-sighted<br>choice that will end up locking us more tightly into the <br>IPv4 world, and why I favour the other choice, which is 

<br>to support 2005-1 or one of its ilk, and help bring the<br>IPv6 internet into the current millenium.<br><br>Matt<br><br></div>