[ppml] RE: ppml 2007 (was blank)

[McBurnett, Jim]

> 
> 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.  
This is done.
2001-2 gives me the ARIN approval to have a Class C- 
This is how I got my Class C.

> 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.

HMM I know an ISP with at least 3 ORG IDs..

 
> 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.
This is a topic that has been covered to such a high degree many of us, just
give up..


> 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.

No real moderator, That I have ever noticed..
Start the thread with a topic whenever you feel.
If it touches a thread in someone it will continue..

 
> 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

Steve-- Check this out:
http://www.arin.net/policy/2001_2.html
Some of those issues are too big enough for a single thread.
J


>   
> 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
> > 
> 
>