Re: [Re: [RE: MPLS billing model]]
Alex Rubenstein <alex@nac.net> wrote:
we are still in the testing phases, but i believe that we are planning to use a port+traffic billing scheme, if/when we go live and start trying to sell it
do you mean:
$port + $traffic_through_port
or:
$port + $traffic_over_vpn_tunnel
I ask this, because, it's very possible that the customer facing port could be a VLAN trunk, and that there would be a hub-and-spoke config to multiple leaf ports; other variations exist, as well.
good question...i don't think that we had considered that. the expectation was that most of the ports would be serial. guess that is another wrench i can throw at the project ;) thanks /joshua
-- Alex Rubenstein, AR97, K2AHR, alex@nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
"Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence." - Stephen Hawking -
On Tue, Nov 25, 2003 at 03:29:26PM -0500, joshua sahala wrote:
Alex Rubenstein <alex@nac.net> wrote:
we are still in the testing phases, but i believe that we are planning to use a port+traffic billing scheme, if/when we go live and start trying to sell it
do you mean:
$port + $traffic_through_port
or:
$port + $traffic_over_vpn_tunnel
I ask this, because, it's very possible that the customer facing port could be a VLAN trunk, and that there would be a hub-and-spoke config to multiple leaf ports; other variations exist, as well.
good question...i don't think that we had considered that. the expectation was that most of the ports would be serial. guess that is another wrench i can throw at the project ;)
In a working transport system, what goes in must come out. So, if you add all the ports in a common direction (in or out), you'll at least get a nice aggregate even if you can't measure individual virtual circuits properly due to whatever brokeass vendor you're using. :) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
In a working transport system, what goes in must come out. So, if you add all the ports in a common direction (in or out), you'll at least get a nice aggregate even if you can't measure individual virtual circuits properly due to whatever brokeass vendor you're using. :)
... which doesn't take into account distance. Assume for a moment you sell a customer a port in Newark, NYC, and London. Clearly, a bit from nyc to newark should be priced differently than one from nyc to london. Agreed?
On Tue, Nov 25, 2003 at 06:16:43PM -0500, Alex Rubenstein wrote:
In a working transport system, what goes in must come out. So, if you add all the ports in a common direction (in or out), you'll at least get a nice aggregate even if you can't measure individual virtual circuits properly due to whatever brokeass vendor you're using. :)
... which doesn't take into account distance.
....or in-cloud replication (IP multicast, L2 multicast). eric
Assume for a moment you sell a customer a port in Newark, NYC, and London.
Clearly, a bit from nyc to newark should be priced differently than one from nyc to london.
Agreed?
On Tue, Nov 25, 2003 at 06:16:43PM -0500, Alex Rubenstein wrote:
In a working transport system, what goes in must come out. So, if you add all the ports in a common direction (in or out), you'll at least get a nice aggregate even if you can't measure individual virtual circuits properly due to whatever brokeass vendor you're using. :)
... which doesn't take into account distance.
Assume for a moment you sell a customer a port in Newark, NYC, and London.
Clearly, a bit from nyc to newark should be priced differently than one from nyc to london.
Agreed?
Yes... Based on the current market, the circuit from NYC to Newark is going to be way more expensive than a larger circuit from NYC to London. :) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
participants (4)
-
Alex Rubenstein -
Eric Osborne -
joshua sahala -
Richard A Steenbergen