At 04:36 AM 12/18/2002 +, Sean M.Doran wrote:
I have found peering to have additive value; a lot of 1-2 Mbps peering
sessions can save as much money for you as a single large traffic peer.
The more traffic, the stronger the case for peering.
Sadly, this completely ignores the cost of impl
I have found peering to have additive value; a lot of 1-2 Mbps peering
sessions can save as much money for you as a single large traffic
peer. The more traffic, the stronger the case for peering.
Sadly, this completely ignores the cost of implementing and maintaining
peerings. BGP does not e
On Tue, Dec 17, 2002 at 11:25:58AM -0800, dre wrote:
> Prothat include capex+opex to a variety of vendors (creating vendor
> dependence) with new "extra" routers (equipment), and seemingly
> costly exchange point "extra" connectivity, with "extra" racks and
> power requirements with monthly re-occ
On Mon, Dec 16, 2002 at 10:53:26PM -0800, William B. Norton wrote:
>
> Right, it is crude, but in an economy where business decisions
> require "Quantifiable *Proof*", this is quantifiable and easy to
> do. Some Peering Coordinators are putting together business
> plans now for peering at the I
> > > Also, that method has the same "knowing the routes" problem as netflow.
> > > Whereever you are getting your list of ASN's route ASN.*"'s routes, there
> > > is pretty much no way they are accurate (for an ASN of ANY size).
> >
> > The vast majority of the routes will be an intersection o
Quantifiable Proof and "Peering Profiles"...see below.
At 08:53 PM 12/16/2002 -0800, Joe Wood wrote:
On Mon, 16 Dec 2002, Joe Abley wrote:
> I think the idea was to say "well, from the mrtg graph, the difference
> between this circuit with all my _9327_ traffic and this circuit
> without any _
On Mon, Dec 16, 2002 at 11:41:12PM -0500, [EMAIL PROTECTED] wrote:
>
> > Also, that method has the same "knowing the routes" problem as netflow.
> > Whereever you are getting your list of ASN's route ASN.*"'s routes, there
> > is pretty much no way they are accurate (for an ASN of ANY size).
>
On Mon, 16 Dec 2002, Joe Abley wrote:
> I think the idea was to say "well, from the mrtg graph, the difference
> between this circuit with all my _9327_ traffic and this circuit
> without any _9327_ traffic, at what I might reasonably estimate their
> peak time to be, looks to be about 2 megs or
At 09:16 PM 12/16/2002 -0500, K. Scott Bethke wrote:
Impressive numbers but of course, slackers aside, if it was your connection
and resources wouldnt you want more accurate information than just a guess?
Yes, but I am also sympathetic to the challenges to ISPs in this economy,
and the challen
> > > based on ALL the ASN's of the people on the peering switch.. but in most
> > > cases anyone pushing any real traffic will probably not have fine grained
> > > samples enough to determine a peering relationship based on a single AS
> > > with this method. Maybe Im wrong but hey if you are
> On Monday 16 December 2002 07:37 pm, Joe Abley wrote:
> > If you are interested in traffic *to* a particular destination, surely
> > you could just tweak localpref on routes based on an as-path filter?
>
> And then quantify it how? Ie; useful Netflow-like "x Mbps to AS x, y Mbps to
> AS y" sta
> > based on ALL the ASN's of the people on the peering switch.. but in most
> > cases anyone pushing any real traffic will probably not have fine grained
> > samples enough to determine a peering relationship based on a single AS
> > with this method. Maybe Im wrong but hey if you are taking 2
> Hi all -
>
> Here is the problem: Everyone wants to know how much traffic would
> ultimately be passed in peering relationships at an IX before signing
> up/building into an IX.
>
> I heard an interesting solution recently to estimating the traffic volume
> destined to an AS in the absence
On Monday, Dec 16, 2002, at 22:47 Canada/Eastern, Grant A. Kirkwood
wrote:
On Monday 16 December 2002 07:37 pm, Joe Abley wrote:
If you are interested in traffic *to* a particular destination, surely
you could just tweak localpref on routes based on an as-path filter?
And then quantify it ho
On Monday 16 December 2002 07:37 pm, Joe Abley wrote:
> If you are interested in traffic *to* a particular destination, surely
> you could just tweak localpref on routes based on an as-path filter?
And then quantify it how? Ie; useful Netflow-like "x Mbps to AS x, y Mbps to
AS y" statistics?
--
On Monday, Dec 16, 2002, at 22:28 Canada/Eastern, Richard A Steenbergen
wrote:
On Mon, Dec 16, 2002 at 09:16:55PM -0500, K. Scott Bethke wrote:
based on ALL the ASN's of the people on the peering switch.. but in
most
cases anyone pushing any real traffic will probably not have fine
grained
On Mon, Dec 16, 2002 at 09:16:55PM -0500, K. Scott Bethke wrote:
>
> based on ALL the ASN's of the people on the peering switch.. but in most
> cases anyone pushing any real traffic will probably not have fine grained
> samples enough to determine a peering relationship based on a single AS
> w
On Mon, Dec 16, 2002 at 05:46:10PM -0800, William B. Norton wrote:
>
> 1) You adjust routing to prefer one transit provider or the other for the AS
> 2) Shift traffic to the particular AS from one transit provider to the
> other, noting the change in the loads on the transit providers.
Ouch. Am
Hi Bill,
Impressive numbers but of course, slackers aside, if it was your connection
and resources wouldnt you want more accurate information than just a guess?
This may be effective for an IX decision if you created some sort of a map
based on ALL the ASN's of the people on the peering switch..
Hi all -
Here is the problem: Everyone wants to know how much traffic would
ultimately be passed in peering relationships at an IX before signing
up/building into an IX.
I heard an interesting solution recently to estimating the traffic volume
destined to an AS in the absence of NetFlow or t
20 matches
Mail list logo
