Re: Your class 'B' address space

[Austin Schutz <tex () shrubbery net>]

On Mon, Sep 28, 1998 at 04:21:27PM -0400, John Todd wrote:
> [Warning: Long post.  Get another cup of coffee before reading.  To save time
> for those of you looking for the short answer: "Mark - start peering with your
> upstreams with a small announcement of /23 or /24, and you'll be fine -
> there's

        There was a presentation at NANOG recently which detailed the use
of NAT for multihoming. You may be generating too much traffic to use NAT.
It might also be worthwhile to have redundant connections to the same transit
provider.
        There are still a few providers around with free C space. You
might consider trying that approach. As mentioned, a /16 is a fairly large
amount of space to be wasting. 

>  If your "primary" upstream from whom you've received a /24 is advertising
> your /24 in a larger aggregate, and you also are advertising your /24 through
> at least one other NSP that is not Sprint (the other possibly being Sprint or
> some other NSP) then you have two valid inbound paths with acceptable
> redundancy.  You could also ask your primary upstream to "de-CIDRize" their
> own
        If your primary upstream connection goes away you are then blackholed
with respect to sprint, etc. as well as all of sprint's singly homed customers,
of which there are many.

> reasons that (from what I understand) Sprint and AGIS block those routes:
> overfull and unstable routing tables.  You're creating the same end result
> with
> the same number of announcements, and using up valuable IPv4 space as a side
> effect.  Double plus ungood.
        I think only single plus ungood in this case, for the wasted space.

> I will certainly not say that you won't have some
> number of customers that can't get to your service.  If you're that concerned
> about them, pull in T1s from both Sprint and AGIS - they'll announce routes
> from customers that they won't accept (at least, Sprint seems to - can't say

        What about the 'handful of others'? This is ludicrous.
> Essentially, I disagree that the premise for your address requirements of any
> size to ARIN is valid based on the information that you have revealed thus
> far.  If you have 5,000 hosts that all must see the Internet and are running
> web servers, then it's a different story.  But if you're just a few dozen (or
> even hundred) servers, a /24 or /23 should be sufficient for an acceptable
> delivery-of-service level.

        Yes, I disagree with the address requirements as well. I don't think
it's unreasonable for a large generator of traffic to want routable space.
Perhaps there should, as mentioned, be additional guidelines from which the
registries make a decision? How about a small area of space dedicated to
those who have a real reason to have a /24-/20 size block?
        If the reason for filtering small block of space is to keep small
companies not generating a lot of traffic from polluting routing space I
don't think this applies.

        Austin