[ppml] RE: ppml 2007 (was blank)

[Owen DeLong]

I think you missed my point.  As an example... Does the CIO of American
Airlines consider American Airlines an ORG, or does he need to consider
that AMR is the ORG and go to them?  The whole idea of an "ORG" is so
ambiguous that using it as a limiting factor in a policy seems absurd.
Not because it is unenforceable, but because noone can figure out how
to comply.

Owen


--On Friday, February 14, 2003 3:00 PM -0700 Steve Rolapp 
<steve at rovingplanet.com> wrote:

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