<div class="gmail_quote">Bill,</div><div class="gmail_quote"><br></div><div class="gmail_quote">I argue that we do try our best to do #3 as you have defined it below</div><div class="gmail_quote"><br></div><div class="gmail_quote">
"3. Create an addressing policy which is an enabler for a broad range<br> of rational routing policies and let the overall routing policy find<br> its own equilibrium."</div><div class="gmail_quote">
<br></div><div class="gmail_quote">There is a balance, however. The needs of the ARIN community for assignments and allocations could easily be in conflict with routing needs. We have seen that over and over. For a while it was extremely apparent when we were running out of "class B" blocks and started allocating bit aligned blocks of "class Cs" but there was no CIDR. So the routing table exploded and the ISPs had to scramble around to deploy BGP that would handle huge blocks of "class Cs" It was a very unpleasant time and my customers at the time were not at all happy with the slowness of the network. </div>
<div class="gmail_quote"><br></div><div class="gmail_quote"> When we moved the minimum allocation from a /19 to a /20 first we argued at length about the routing implications and then we actually watched the routing table over time to see the effects. There even used to be a Routing Table Measurement and Analysis (RTMA) working group as part of ARIN to bring routing table information to the community as a way to help with address policy decisions. </div>
<div class="gmail_quote"><br></div><div class="gmail_quote">With IPv4 address space running out I can easily see scenarios where the ARIN community will want assignments and/or allocations that directly conflict with routing. Some will gain consensus and some probably won't. WIth IPv6 we have in essence classfull addressing again. At some point will we relive these scenarios? Probably. </div>
<div class="gmail_quote"><br></div><div class="gmail_quote">It isn't that the ARIN community doesn't consider these things when developing good policy. These things are always discussed and considered but in the end addressing policy has to also meet the needs of the community. ARIN has meetings jointly with NANOG for that very reason. It is essential that addressing policy has input from the communities it affects. </div>
<div class="gmail_quote"><br></div><div class="gmail_quote">----Cathy</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">
010 at 6:13 PM, William Herrin <span dir="ltr"><<a href="mailto:bill@herrin.us">bill@herrin.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Thu, Feb 4, 2010 at 7:21 PM, Barbara Roseman<br>
<div class="im"><<a href="mailto:barbara.roseman@icann.org">barbara.roseman@icann.org</a>> wrote:<br>
</div><div class="im">> I think that's a fair restatement of what I was saying,<br>
>except you left out the part about uniqueness vs.<br>
>routeability. My points were twofold:<br>
><br>
> 1) ARIN can only offer unique registration of IP<br>
>addresses, they cannot offer unique use of<br>
>addresses -- nor can anyone else because<br>
>Bad People tend to ignore the rules, and Ignorant<br>
>People are, well, ignorant.<br>
<br>
</div>Hi Barbara,<br>
<br>
Okay. That reads as a reasonable statement to me. I don't follow how<br>
it bears on the routing policy issue.<br>
<br>
Or at least I don't see a way that ARIN could alter its process to<br>
make announcements inconsistent with the ARIN registrations easily<br>
filterable. If such a thing was possible, I'd surely want to see an<br>
ARIN policy proposal as, no doubt, would every ISP on the planet.<br>
<div class="im"><br>
<br>
> 2) The ARIN community and the NANOG community<br>
>have discussed repeatedly that it's not simple cause<br>
>and effect from ARIN's allocation/assignment policies<br>
>to operator's routing policies, though the influence is<br>
>extreme. If the connectivity provider is large enough,<br>
>as CJ notes, than they can do whatever they want.<br>
<br>
</div>Okay. So because providers are already able, for a time, to make<br>
unreasonable choices which defy the defacto standards adopted by the<br>
overwhelming majority of their peers we should not adopt practices<br>
that enable more flexibility within the set of -reasonable- choices? I<br>
don't follow.<br>
<div class="im"><br>
<br>
On Thu, Feb 4, 2010 at 7:09 PM, <a href="mailto:cja@daydream.com">cja@daydream.com</a> <<a href="mailto:packetgrrl@gmail.com">packetgrrl@gmail.com</a>> wrote:<br>
> Bill,<br>
> I see what you're saying here but the reality for me was that for close to a<br>
> year a very large ISP didn't pay attention to ARIN's allocation of parts of<br>
> <a href="http://24.0.0.0/8" target="_blank">24.0.0.0/8</a>. They were big and I was little and so they won at least for a<br>
> time.<br>
<br>
</div>That's disappointing in this day and age, but then we're talking about<br>
the same folks who thought their customers wouldn't cry bloody murder<br>
when they cut off communications with cogent. If you ever have<br>
problems with them carrying your routes again, drop me a line so I can<br>
start claiming service credits. That'll get their attention. :)<br>
<div class="im"><br>
<br>
> ARIN has no control over filtering/routing policies. At a recent NANOG<br>
> there was a panel where ISPs in no uncertain terms told the community that<br>
> they do not want ARIN policies to include anything about routing policy. I<br>
> believe at this point that most of the RIRs have removed routing criteria<br>
> from their IPv6 policies for that very reason.<br>
<br>
</div>Hi Cathy,<br>
<br>
Poor control is not the same as no control and getting ARIN policy out<br>
of the way of ISPs setting routing policy is not the same as saying<br>
and doing nothing about routing policy.<br>
<br>
In a very real sense, addressing is routing is addressing. Each<br>
follows from the structure of the other. An addressing policy which<br>
does not impact routing policy is simply inconsistent with reality.<br>
<br>
I'll repeat that for emphasis: There's no such thing as addressing<br>
policy which does not impact routing policy. It can't exist.<br>
<br>
Thus the choices are:<br>
<br>
1. Create an addressing policy which implicitly shapes routing policy<br>
through the accidents of its structure.<br>
<br>
2. Create an addressing policy which is informed by and explicitly<br>
shapes a uniform routing policy.<br>
<br>
3. Create an addressing policy which is an enabler for a broad range<br>
of rational routing policies and let the overall routing policy find<br>
its own equilibrium.<br>
<br>
<br>
What we do now is sometimes #1 and sometimes #2. For example:<br>
<br>
A. The unfilterability of traffic engineering is an accidental<br>
side-effect of CIDR address allocations. Because they're all mashed<br>
together in the same pool, operators can't tell the difference between<br>
easily filterable TE and unfilterable multihomed downstreams.<br>
<br>
B. Accepting /24 reassignments to multihomed customers regardless of<br>
size is informed by the /24 boundary present in DFZ routing policy.<br>
<br>
C. CIDR allocation (instead of simply assigning a linear range of<br>
addresses) is an explicit attempt to bring about aggregation within<br>
the routing system. It's routing policy directly encoded as addressing<br>
policy.<br>
<br>
<br>
I think we'd be wiser to pursue course #3: enable a broad range of<br>
sensible routing policies and then step back out of the way.<br>
<div><div></div><div class="h5"><br>
Regards,<br>
Bill Herrin<br>
<br>
<br>
--<br>
William D. Herrin ................ <a href="mailto:herrin@dirtside.com">herrin@dirtside.com</a> <a href="mailto:bill@herrin.us">bill@herrin.us</a><br>
3005 Crane Dr. ...................... Web: <<a href="http://bill.herrin.us/" target="_blank">http://bill.herrin.us/</a>><br>
Falls Church, VA 22042-3004<br>
_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
</div></div></blockquote></div><br>