[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RRG] Re: Charging for updates in BGP



Hi Robin,

Robin Whittle wrote:
> Hi Michael,
> 
> Continuing from:
> 
>   Re: [RRG] Separation vs. Elimination
>   http://psg.com/lists/rrg/2008/msg02583.html
> 
> we were discussing charging for BGP updates, as part of discussing
> similarities and differences between Ivip and BGP.
> 
>>> In both cases, there is a global system which enables packets
>>> addressed to some prefix to be sent to some router.  Ivip only works
>>> as an addition to the BGP system.  BGP works on its own.  BGP's
>>> handling of changes is slow and expensive - and difficult or
>>> impossible to charge end-users for when they make a change.  Ivip's
>> Why? Say I'm your customer, and we have a configured BGP session. You
>> count the number of updates that arrive over that connection per month,
>> and then charge me per update once a month.
> 
> OK, I am an ISP and you are an edge network with your own PI space, generating
> changed advertisements for whatever reasons, such as multihoming service
> restoration and/or incoming traffic TE.  I assume you have one or more other
> ISPs as well.
> 
> I could charge you per update, but it would probably only make business sense if
> all the other ISPs did the same, at the same rate.  If they didn't charge, or
> charged less, I would be at a competitive disadvantage.
> 
> Why would I want to do this, unless I was forced to do so by my upstream providers?
> 
> Why would they want to force me to do this, when I could choose some other
> upstream provider which didn't force me to do so too?
> 
> 
> Let's say I am ISP-1 and you multihome with ISP-2.  If ISP-1 and ISP-2 have very
> different connections to the rest of the Net, when you change your advertisement
> from one to the other, the effects may ripple through and cause messages to, and
> changes of best path in, potentially every router in the DFZ.
> 
> If ISP-1 and ISP-2 share the same single upstream provider, or perhaps the same
> two upstream providers . . . then no matter how often you change the way you
> advertise your prefix with ISP-1 and ISP-2, you are probably only burdening
> these two ISPs and a few routers at the edge of the common upstream provider(s).
> 
> So there is a wide variability in the impact of your update, depending on the
> structure of the interdomain connections and how the routers are configured.  In
> that case, how fair is it to charge you the same fee per update, when the impact
> it has on the rest of the DFZ depends on things which are largely outside your
> control?
> 
> 
> I figure charging for each BGP changed advertisement could be done, like this,
> via some technical and commercial arrangements.  However, it would only make a
> marginal impact on the routing scaling problem.  Another arrangement might be to
> have some global registry of ASes and their PI prefixes - where the ASes have
> all agreed to pay some fee per update, to some central fund, and there is some
> technical arrangement to monitor the changes they make, so the payments can be
> seen to be correct.  But how would that work?  Some changes might not be
> detectable except very close to the upstream ISPs of each edge network.

I believe you have made my point for me -- this is technically feasible
with BGP, but probably not economically feasible.

As I understand it, you argue that a similar payment system *will* be
economically feasible under Ivip. It seems you claim this only because
Ivip is designed from the ground up to require this. But then it seems
to me that, if an ISP would say no to the question: "should I charge my
customers when they change their reachability in BGP?", then they would
also say no to the question: "should I deploy a system (Ivip) that
requires me to charge my customers when they change their reachability?"

-Michael

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg