> Interesting points, and although orthogonal to the analysis in "Do
> ATM-based Internet Exchange Points Make Sense Anymore?", I am including
> these in the appendix to show these alternate views of the world. Am I
> missing any of the major (fact-based) views?
>
There is this "small" thing tha
At 01:13 PM 8/9/2002 -0700, Bill Woodcock wrote:
> > Personally, I don't believe that ATM is 'bad' for
> > shared-fabric exchange point. I mean, it works, and solves several
> > problems quite easy: a) it's easily distributed via SONET services to
> > folks who are not next to th
Hi all - Thanks for all the feedback and keep it coming ! I'll summarize
the 80 or so responses so far.
As an aside, I especially liked this paper request:
"I'd like to see a copy of your paper - please fragment it into 48
byte chunks."
A couple points seem to come up from a bunch of
Hi all -
I have walked about 30 people through the "Do ATM-based Internet Exchange
Points make sense anymore?" white paper and have received some really good
feedback, suggestions and price points to calibrate the Peering Financial
Model. I have applied these calibrations and I am ready to re
-to: [EMAIL PROTECTED]
>Subject: Re: Do ATM-based Exchange Points make sense anymore?
>
>
>On Fri, 9 Aug 2002, Nenad Trifunovic wrote:
>
>> It appears that for analysis purposes one has to separate access
>> from switching. How much payload one brings to the exchange depend
Thus spake "Petri Helenius" <[EMAIL PROTECTED]>
> > What functionality does PVC give you that the ethernet VLAN does not?
> >
> That´s quite easy. Endpoint liveness. A IPv4 host on a VLAN has no idea
> if the guy on the "other end" died until the BGP timer expires.
>
> FR has LMI, ATM has OAM. (a
Thus spake "Alex Rubenstein" <[EMAIL PROTECTED]>
> > What functionality does PVC give you that the ethernet VLAN does not?
>
> Shaping, for one.
There is nothing inherent in Ethernet which precludes shaping. Low- and
mid-range routers can do it just fine. If your core router doesn't, speak wit
> I suppose the discussion is what do you want from your exchange pt
> operator and what do you NOT want.
At the IXP level, "bits per month" always trumps "bits per second",
and usually trumps "pennies per bit" as well. There are now a number
of companies trying to sell wide area ethernet -- e
Paul just hit on it. At how many layers do you want protection, and
will they interfere with each other. Granted not all protection
schemes overlap. If there if not a layer 1 failure, and a router
maintains link0 but the card or routers has somehow failed and is no
longer passing packets,
On Sat, Aug 10, 2002 at 05:42:32PM -0400, Alex Rubenstein wrote:
>
> > What is the current max speed of frame relay in any common vendor
> > implementation (I'm talking routers here).
>
> Doesn't OC48 POS on GSR and Jewniper do FR?
Welcome to MAE Chicago/New York, http://www.mae.net/FE/. But M
> If the connection fabric between your routers has an MTBF best measured in
> hours or days, then you've got bigger problems than you'll solve with LMI.
Agreed. However, I think the debate may be over the (un)reliability of
routers connected to the exchange, not the exchange itself.
-- Ale
> What functionality does PVC give you that the ethernet VLAN does not?
Shaping, for one.
> What is the current max speed of frame relay in any common vendor
> implementation (I'm talking routers here).
Doesn't OC48 POS on GSR and Jewniper do FR?
>
> --
> Mikael Abrahamssonemail: [EM
On Fri, 9 Aug 2002, Nenad Trifunovic wrote:
> Can you, please, explain why you didn't consider Frame Relay
> based exchange in your analysis?
I'd imagine because no real 'high-speed' FR switch exists (as in, oc12 or
above).
-- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reub
On 10 Aug 2002, Paul Vixie wrote:
> why on god's earth would subsecond anything matter in a nonmilitary situation?
Telemedicine, tele-robotics, etc, etc. Actually, there's a lot of cases
when you want to have subsecond recovery. The current Internet routing
technology is not up to the task;
On Sat, Aug 10, 2002 at 11:20:44AM -0400, Richard A Steenbergen wrote:
>
> On Sat, Aug 10, 2002 at 06:09:05PM +0300, Petri Helenius wrote:
> >
> > If the software MTBF would be better, convergence would not be an issue.
> > As long as it's an operational hazard to run core boxes (with some
> >
On Sat, Aug 10, 2002 at 06:09:05PM +0300, Petri Helenius wrote:
>
> If the software MTBF would be better, convergence would not be an issue.
> As long as it's an operational hazard to run core boxes (with some
> vendors anyway) with older piece of code than six months, you end up
> engineering
Paul Vixie wrote:
>
> warning: i've had one "high gravity steel reserve" over my quota. hit D now.
>
> > The issue I'm trying to address is to figure out how to extend the robustness
> > that can be achieved with tuned IGP's with subsecond convergence across
> > an exchange point without suffe
Mikael Abrahamsson <[EMAIL PROTECTED]> writes:
> On 10 Aug 2002, Paul Vixie wrote:
>
> > why on god's earth would subsecond anything matter in a
> > nonmilitary situation?
>
> It does when you start doing streaming anything, say TV or telephony. I
I submit that it doesn't matter for voice or
Mike Hughes wrote:
> With the shorter timers or fast-external-fallover, a very short
> maintenance slot at a large exchange can cause ripples in the routing
> table. It would be interesting to do some analysis of this - how far the
> ripples spread from each exchange!
We do BGP instability rese
On Sat, 10 Aug 2002, Mikael Abrahamsson wrote:
> It does when you start doing streaming anything, say TV or telephony. I
> agree that this wont be solved using any current L3 or above protocol
> since BGP takes quite a while to recalculate anyway. Any redundancy has to
> be pre-calculated or on
On 10 Aug 2002, Paul Vixie wrote:
> why on god's earth would subsecond anything matter in a nonmilitary situation?
It does when you start doing streaming anything, say TV or telephony. I
agree that this wont be solved using any current L3 or above protocol
since BGP takes quite a while to recal
warning: i've had one "high gravity steel reserve" over my quota. hit D now.
> The issue I'm trying to address is to figure out how to extend the robustness
> that can be achieved with tuned IGP's with subsecond convergence across
> an exchange point without suffering a one to five minute dela
Paul Vixie wrote:
> Adding complexity to a system increases its cost but not nec'ily its value.
> Consider the question: how often do you expect endpoint liveness to matter?
The issue I'm trying to address is to figure out how to extend the robustness
that can be achieved with tuned IGP's with s
> > What functionality does PVC give you that the ethernet VLAN does not?
>
> That´s quite easy. Endpoint liveness. A IPv4 host on a VLAN has no idea
> if the guy on the "other end" died until the BGP timer expires.
>
> FR has LMI, ATM has OAM. (and ILMI)
Adding complexity to a system increases
On Fri, Aug 09, 2002 at 01:13:04PM -0700, Bill Woodcock wrote:
>
> > Personally, I don't believe that ATM is 'bad' for
> > shared-fabric exchange point. I mean, it works, and solves several
> > problems quite easy: a) it's easily distributed via SONET services to
> > folks who ar
-based Exchange Points make sense anymore?
> What functionality does PVC give you that the ethernet VLAN does not?
>
That´s quite easy. Endpoint liveness. A IPv4 host on a VLAN has no idea
if the guy on the "other end" died until the BGP timer expires.
FR has LMI, ATM has OAM. (and ILMI)
Pete
On Fri, 9 Aug 2002, William B. Norton wrote:
> One point a couple other folks brought up during the review (paraphrasing)
> "You can't talk about a 20% ATM cell tax on the ATM-based IX side without
> counting the HDLC Framing Overhead (4%) for the OC-x circuit into an
> ethernet-based IX." Si
> What functionality does PVC give you that the ethernet VLAN does not?
>
That´s quite easy. Endpoint liveness. A IPv4 host on a VLAN has no idea
if the guy on the "other end" died until the BGP timer expires.
FR has LMI, ATM has OAM. (and ILMI)
Pete
On Fri, 9 Aug 2002, Nenad Trifunovic wrote:
> It appears that for analysis purposes one has to separate access
> from switching. How much payload one brings to the exchange depends
> on port speed and protocol overhead. In that light, Frame Relay
> can bring similar amount of payload as Ethernet
d Trifunovic <[EMAIL PROTECTED]>
>CC: [EMAIL PROTECTED]
>Subject: Re: Do ATM-based Exchange Points make sense anymore?
>
>
>>Can you, please, explain why you didn't consider Frame Relay
>>based exchange in your analysis?
>
>I don't have much insight into
>Can you, please, explain why you didn't consider Frame Relay
>based exchange in your analysis?
I don't have much insight into Frame Relay-based Internet Exchange Points ;-)
The majority of IXes around the world are ethernet-based, with some legacy
FDDI and a few ATM IXes. It is in these areas
> Personally, I don't believe that ATM is 'bad' for
> shared-fabric exchange point. I mean, it works, and solves several
> problems quite easy: a) it's easily distributed via SONET services to
> folks who are not next to the ATM switch, b) it makes interconnection
> between ne
]
>Delivered-to: [EMAIL PROTECTED]
>Delivered-to: [EMAIL PROTECTED]
>Delivered-to: [EMAIL PROTECTED]
>Subject: Re: Do ATM-based Exchange Points make sense anymore?
>
>
>Hi again -
>
>A couple points (based on some interactions with folks privately).
>
>This is not an
33 matches
Mail list logo
