[ppml] "Recommended Practices" procedure
Jason Schiller (email@example.com)
jason.schiller at mci.com
Thu Jun 29 17:15:54 EDT 2006
On Thu, 29 Jun 2006, Scott Leibrand wrote:
> On 06/29/06 at 12:20pm -0700, Owen DeLong <owen at delong.com> wrote:
> > I think the cooperating filter policy suggestion is about the best way to
> > handle this. If two ISPs want to cooperate and open holes in their PA
> > blocks with each other, that doesn't mean anyone else has to. Yes, it
> > does mean multihoming for those customers is slightly less reliable than
> > for customers using PI space, but, I don't see a big downside to that.
> I agree. However, I would recommend suggesting it in a "Recommended
> Practices" document, as doing so doesn't pollute the global table, just
> yours and your peers'.
Although somewhat difficult, the problem isn't getting each of the
customer's upstream ISPs to send the more specifics between their peering
sessions, the customer is presumably paying their upstream ISPs to carry
The problem is getting all the other default free ISPs to carry the
route. Sources that buy transit from someone other than the customer's
upstream ISPs will be dependent on the upstream ISP that provided the PA
IP space, unless they also carry the more specifics.
I suppose you could charge someone to carry non-customer PA /48s. But
shouldn't the same also be true for PI /48s?
Provider: "Oh you want to get to company XYZ that is using PI space?
Well, they aren't a customer of ours. Either you can pay us to put their
/48 route in out table or contact compnay XYZ and ask them to pay us to
put their /48 route in our table."
Customer: "But that's extortion!"
Jason Schiller (703)886.6648
Senior Internet Network Engineer fax:(703)886.0512
Public IP Global Network Engineering schiller at uu.net
UUNET / Verizon jason.schiller at verizonbusiness.com
The good news about having an email address that is twice as long is that
it increases traffic on the Internet.
More information about the ARIN-PPML