[ppml] RE: ppml 2007 (was blank)

[Steve Rolapp]

Comments below.

Steve Rolapp

> -----Original Message-----
> From: McBurnett, Jim [mailto:jmcburnett at msmgmt.com]
> Sent: Friday, February 14, 2003 10:21 AM
> To: Steve Rolapp; ppml at arin.net
> Subject: RE:
> 
> 
> >The issue of a fixed block size bothers me.  I have noted that
comments
> >seem to set the lower limit to a /24.  For an organization
> >that does not
> >provide hosting services to others, that size should be overkill in a
> >world that requires organizations to have the core network NATed for
a
> >sensible security.  If you look at the BGP routing tables, you will
> >indeed find /25-/27 out there.  Whether an organization pulls
> >a /24 or a
> >/27, its out on the net.  Follow the heart of the idea on cidr to
this
> >also.
> 
> OKay, I agree that a /24 is overkill... BUT some ISPs will filter
> small blocks I have seen it.  CIDR is great, but some filter that
too..

This isn't to say that won't happen.  Every ISP can make their own
decisions but they have to live with those when their customers
complain.  If it becomes known that an ISP has decided to not listen to
these routes and people can't get there, their customers will leave.
Competition will drive this.  I have personal experience in showing
companies that are blackholing routes.  It always gets fixed.

> >Organizations can not be assigned more then one block.  Mergers of
> >companies that are each assigned a block must relinquish one
> >in 180 days
> >of the completed merger.  Failure to do so voids both blocks and ASs.
> 
> This won't work.  Company A merges with Company B. Offices in Canada
and
> the US.
> Large research facility in W city and corp HQ in X City with
> Manufactuering Plants
> in Y and Z Cities. If more than 1 office is so critical they need to
> Multi-home,
> this would prevent that if they are using /24s or they have to
renumber
> for a
> /23....

Lets take the assumption that the merger happened such that A had three
of those offices and B had one. If a /24 was the min then A would have
needed a /22 leaving an unused /24 for the merger.

Lets take the assumption that they each have two offices.  This is the
sticking point. They each have a /23.  As I read 2002-7, an org could
have only one block.  That means they must give up both unless they can
get an a joining block for one of them.  Bad news but it's the price of
business.

I'm not really that cold.  This goes back to the issue of block size.
Unless these companies are all hosting providers, which precludes them
anyway, the address space we are talking about is overkill.  Two real
issues ensue. Can one of the existing blocks be subnetted to accomidate
the needs or has the org grown to the point it needs a bigger address
space (an issue without a merger).

In both cases there is a forced need to re-architect the IP space.  But
this really is part of business and it can be managed.  The sudden loss
of a provider and the IP space from them is not.
 
> >Multihoming is not cheap.  I will get hate mail for this probably but
> >the proposed fees are too low.  Make sure that those doing
> >this have the
> >resources to keep it going and ARIN has the resources to take it
away.
> >Failure to pay fees in a timely manner are grounds for voiding the
> >space.
> YES, it is not cheap.  But the whole point is to make it easier for
the
> small-mid sized companies to multi-home. So you think ARIN and other
RIR's
> should become the finance police in a sense to prevent the fly by
night
> from
> becoming multi-homed and going under? If a company is that stupid, let
em.
> And then Let ARIN or Other RIR make the money for the extra
assignments.
> Failure to pay is always that way though...

I am not saying set an artificially high price but ARIN does need to be
responsible for getting the space back whether it be with help from the
ISP's or the courts.  That does have a cost and what was given appeared
to not take that into account.

> Taking it away how ? ARIN can't change a routing table.
> ARIN would need help from every backbone provider to do this..

Agreed.  IETF would need to be involved such that part of the next rev
of BGP might include valid AS and IP blocks that's fed from the RIR's.
I didn't say it could happen over night but instead said lets start
working towards it.
> 
> Jim
> 
> 
> >The issue here shouldn't be whether to do this but instead how to
> >proceed.  This is a needed solution that needs to be implemented.
> >
> I agree here... We need to discuss all options.
> 
> Jim