[arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

[Kevin Kargel]

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Owen DeLong
> Sent: Thursday, June 02, 2011 2:14 AM
> To: Benson Schliesser
> Cc: arin-ppml at arin.net List
> Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM
> 8.3
> 
[Much snippage to comment on a single point]
> 
> Quite frankly, if you sell a /19, you really don't have to announce the
> /17, /18, and /19. You could just continue to
> announce the /16 knowing that the recipient's /19 would override your /16
> announcement.

The only real reason not to advertise the /16 is that if their /19 networks (read BGP sessions) go completely down you *could* then receive and pay for traffic *to* their netblock, even if you blackhole it.  This could affect your peak use (billing statistic) or possibly create a DoS type situation at your edge if your pipe/router is not sized to accommodate the resultant aggregate traffic or if their network is under a DDoS attack.  

This will probably not be an issue for anyone actually utilizing a /17.  I am just nit-picking.

Kevin


> 
> There is little or no benefit to you announcing the /17, /18, and /19
> instead of the /16.
> 
> > Clearly, limiting what people can receive will have an effect on
> disaggregation - reducing the number of blocks allowed per-recipient-per-
> time-period will encourage buyers to acquire as much as they can afford as
> a single block, rather than many small blocks over time.  That's good.
> But just as disaggregation occurs today at the "whim" of the announcing
> AS, it will continue to do so under the regime described above.
> >
> 
> I think this is somewhat inevitable and not really an address policy
> matter.
> 
> > ARIN could attempt to limit this by only accepting disaggregation in
> Whois by +N (e.g. +1 or +2) bits of prefix-length per year.  Of course,
> that means holders of very large blocks will have a hard time selling
> their unused space - they may need to disaggregate by larger values of N
> in order to meet demand under a "justified need" regime - so some kind of
> sliding scale might be useful, based on original block size.  Otherwise,
> for a uniform value of N this policy would limit the supply of address
> blocks (and probably drive up prices).
> >
> 
> We have long since examined the idea of fixed values of N per unit time
> deaggregation as you propose above and determined that it was beyond
> dysfunctional. As such, I think that rehashing it here really isn't worth
> while. I realize this discussion occurred before you were active on PPML,
> but, if you want to review it, I suggest reviewing the archives for 2008-
> 2, 2008-15, and 2009-1.
> 
> > I'm personally inclined to view this (+N idea) as market distorting, and
> probably ineffective since ARIN doesn't control BGP anyways. But I offer
> it for your consideration, regardless.
> >
> 
> Understood, and, in this case, I actually agree with you.
> 
> Owen
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.