[arin-ppml] Rationale for /22

[Ted Mittelstaedt]

Jon Lewis wrote:
> On Tue, 28 Jul 2009, Scott Leibrand wrote:
> 
>> No, we're talking about multihomed organizations here.  If my 
>> singly-homed customer gets a /24 from me (out of one of my /16s), then 
>> that doesn't add to the table (the only announcement is my /16).  If, 
>> however, a multihomed customer gets a /24 from me, they'll announce 
>> the /24 as well (both to me and to their other upstream), thereby 
>> adding an additional route to the global table (for anyone who doesn't 
>> filter /24s, which very few networks do today).
>>
>> If the multihomed downstream customer gets their /24 from ARIN instead 
>> of from me (their upstream), then it still adds one route to the 
>> table.  The only difference is that it can't be filtered without 
>> affecting reachability (for example, by someone with hardware that can 
>> only do 256k routes).
> 
> The distinction some people may not be getting is that if I know ARIN 
> allocates from a /8 nothing longer than /20s, then if I'm running out of 
> routing slots, I can use a prefix-list to ignore anything /21 (or maybe 
> /22) or longer from that /8.  If ARIN allocates /24s from a /8 or 
> probably longer net, then I need to accept those /24s.  That's the 
> theory anyway.
> 
> Having looked into this some time ago while using Sup2's for BGP, I know 
> the unfortunate reality is, even in /8s where there is a RIR published 
> minimum allocation size, you'll find clue-deprived networks 
> deaggregating their allocations and not announcing the aggregates.  If 
> you filter on RIR allocation minimums (even with a bit or two of 
> padding) and don't point default at a network that doesn't filter 
> similarly, you're going to have reachability issues.
> 
> Doesn't this nullify the first point?  i.e. ARIN shouldn't allocate 
> /24s, because we want people to be able to filter on RIR allocation 
> minimums without losing reachability.  We already know that doesn't work 
> without default routing.
> 
> What other real world reason is there for not lowering the bar to /24?
> 

The same reason that the highways are posted 55Mph but the cops only
pull you over if your doing 65 or above.

NRPM currently lists /23 as the minimum under section 4.2.2.2  (ie:
multihomed orgs have to demonstrate efficient utilization of an
upstream /23 and how are you going to do that if your multihomed
and you don't advertise a /23?) and they even stretch it to /24
with the wishy-washy "demonstrate the efficient utilization of a minimum 
contiguous or noncontiguous /23 (two /24s) from an upstream."  The
implication is a small ISP can have 2 discontiguous /24's in
production use - but ARIN doesn't itself assign /24's for this
so they are basically in the position the highway cop is.  In
other words the speed limit says /20 (section 4.3.2.1) but they will 
ignore the fact your running at /24 speed.

Then there's more of this in section 4.4 where they assign /24's with
the statement "including public exchange points, core DNS service 
providers" well how are you gonna have a "core DNS service provider"
on a /24 that's not fully reachable?

In other words the implication in the NRPM is that only "special"
people like critical infrastructure providers, or people who are
in the process of obtaining their "reserved" /22's are expected to
be running below /20 in size.  The rest of the normal Internet isn't
supposed to be using anything smaller than a /20

So, ISP's who filter set their boundary at /24 because it's a few
bits off /20, to allow themselves a bit of wiggle room

If you change it so that the bar is lowered to /24 then ISPs that
filter will have to reduce down to /26 to be absolutely sure that
they catch those clueless out there who get their /24 and subnet it
into /25's or /26's and advertise those.

Ted