[arin-ppml] Clarification on "a block designated for that purpose"

[Steve Bertrand]

On 2010.02.25 04:04, michael.dillon at bt.com wrote:
>> When I came up with 'a block designated/reserved for that 
>> purpose', I was not attempting to segregate the IP space into 
>> another classful environment.

> Note that IPv4 today is still classful. We don't have 
> Class A, B and C any more, but we still have class D
> multicast and RFC 1918, and a few other special use
> classes.

These are 'hard' classes (ie. classes that require major vendor overhaul
and operational learning curves and expenses to get over). I guess I
agree with you that what I'd like to see is creating a _form_ of class.

> It is a GOOD thing if ARIN applies classful thinking
> and uses a designated block for address allocations
> which providers will likely want to treat AS A CLASS
> and apply the same policy towards them.

Agreed. A 'soft' class system. One founded on policy and documentation,
that can be changed if the policy is changed. One where network people
and business policy makers can form their own internal policies around
if they choose to, but there will be no ill-effects if they don't.

>> - it's an ARIN allocation, and it falls within the 'special IX' space
>> - we weight the traffic differently, and allow it for an 
>> extended period

> That is a class of address. If the special IX space was
> a list of 379 scattered allocations ranging from /24 to
> /19, you would do more work than if it was all from a
> single ARIN /15 block. The CLASS exists regardless of
> whether ARIN does the sensible thing or not.

Exactly. Easier for reporting, easier for filtering/PBR etc, but
requires no operational changes/impact for those who might not need/want
to do traffic 'classification' within their network.

>> There are no restrictions. Again... I'm not asking for ARIN 
>> to create a "boundary" here.
> 
> Sure you are. Otherwise you would ignore this issue entirely
> and work with someone like Cymru to set up a registry to
> track all the special case blocks.

That's a thought, but wouldn't it be easier if we did the documentation
this time around since we have the chance, and let Team Cymru focus on
their new projects? ;)

fwiw, I believe that ALL blocks are "special case". ie. it's a special
case if I need single-homed PA, another special case if I need a
multi-homed /48, ISP /32, IX, infrastructure etc, and I'm hoping that
its not too late to configure a documentation system for it.

>> As an engineer/operator, I just 
>> would find it easier that if the IP space was to be 
>> segregated, that it be segregated in a way that it be 
>> documented publicly, so that ops *could* make 
>> routing/forwarding decisions on the documentation if they *chose* to.
> 
> I agree with you that this is a good thing.
> Classes are good, and subclasses like this are within the
> scope of ARIN's charter. We may not determine network operations
> activity, but we have always tried to fit in with it as
> long as it was consistent with the public interest.
> 
> When ARIN started, network operators used classful filtering
> on incoming BGP announcements since they knew that ARIN's minimum
> ISP allocation on certain /8s, was /19. ARIN had defined the class
> and operators leveraged that information.

We have another chance to use leverage again then. With the relatively
few v6 blocks currently allocated/assigned by ARIN, with documentation,
ops could once again be able to identify not only the minimum/maximum
_size_ of the prefix from the block, but also what its _purpose_ is (or
supposed to be).

What prompted my OP was a few off-list comments/discussions that I had.
Some were saying that I was trying to create "classes", and some "classful".

The terminology got me until I read your response. I would like to see
'classes of networks' (documentation only), but not 'classful networks'
(ie hard boundaries).

Steve