[ppml] RE: ppml 2007 (was blank)

Steve Rolapp steve at rovingplanet.com
Fri Feb 14 17:00:44 EST 2003


The way I understand the proposal was that the purpose was to allow
small to medium orgs to be able to get a block assignment if they were
multihomed.  There was no teeth in the proposal to ensure that those
getting the assignment should be allowed and I believe that became one
sticking point.  

Yes, its difficult to ID who is part of another org.  While it is
difficult to identify who should or should not be classified as multiple
orgs, as a CIO or network director, I would not put my company in a
position where its connectivity could suddenly be cut because of fraud.


What that requires is that the RIR's have to have a mechanism to affect
the routing tables (gads!).  Should that be tied to whether this moves
forward?  I don't feel so.  But lets do get the issues out there.  As I
have said before, I really feel this needs to happen.  I have been
affected and along with others I know.  It sounds like a lot of other
people commenting on this list feel the same way.

Lets start a new thread that lists the issues for and against and start
addressing them.  Right now a lot of the comments have been in that
direction (as has yours).  I am new to the list.  Is there a moderator
and are they/he/she willing to start building a subthreads for each
issue?  I would really like to see it move forward and would like to
hear from the RIR's and ISP's on this also.

I'll throw what I think are the issues so far:

Aggregation
  Block sizes
IP address pool
  Swamp use
  Reallocations
Org qualification
  Multihoming
  Company size
RIR administration
  Policing

  
Thanks,

Steve Rolapp

> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Friday, February 14, 2003 12:45 PM
> To: Steve Rolapp; ppml at arin.net
> Subject: Re: [ppml] RE: ppml 2007 (was blank)
> 
> Since we're starting to split really fine hairs (hares? poor
bunnies)...
> 
> How do you even plan to identify, let alone enforce the ORG limit,
when
> all the orgs would have to do is simply continue to function/interact
> with ARIN as multiple ORGs.  Heck, under existing policies, one ORG
> where I worked turned themselves into multiple ARIN customers just to
> simplify the process of getting the address space they needed for
rational
> localization of IP blocks.  How do you expect ARIN to identify that
the
> ORGs should be considered a single ORG.  How do you identify a single
> ORG vs. multiple ORGs.  Is a subsidiary an ORG, or does the parent
company
> have to be involved in ALL IP issues for the subsidiary?  Would
American
> Airlines be able to get IP space for the airline, or would AMR have to
> handle all IP space for American, AMR Combs FBOs, and the various oher
> AMR companies?  Sorry, the whole issue of 1 block per ORG just doesn't
> work out in the long run, because there's no way to identify an ORG.
> 
> Owen
> 
> 
> --On Friday, February 14, 2003 11:43 AM -0700 Steve Rolapp
> <steve at rovingplanet.com> wrote:
> 
> >
> > 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
> 




More information about the ARIN-PPML mailing list