North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Service Provider Exchange requirements
- From: John Fraizer
- Date: Sun Oct 22 21:19:08 2000
Mike: I don't know what PGP you're using but, I get nothing from
them. Just blank page.
Now, on to our regularly scheduled reply...
On Sun, 22 Oct 2000 email@example.com wrote:
> > How about ethernet versus ATM? With VLANs and high speed such as
> > Gig/10Gig, I can get speed and one to many arrangements (at least for
> > lower speeds). Should Ethernet be point to point or optionally
> > multiaccess in nature?
> ATM is a fine edge technology for lower speed access.
> Ethernet is inherently "multiaccess" (can you say CSMA-CD?)
Why would one use a VLAN in a shared-media exchange? The only legit
reason I can think of is to enforce the "next-hop-self" rule and prevent
peer A from exposing direct peer B routes to peer C.
Do you really want to have to set up a VLAN for every peering session on
the exchange? You've just added the headaches of an ATM exchange point to
an ethernet exchange point.
Write and even more importantly, ENFORCE the AUP for your exchange point
and shared media works wonderfully. Someone fails to "play fair" and you
shut their port off. It's just that simple.
> > Is Diff-Serv or ATM QoS a requirement or can 85-90% of requirements
> > be met with loss/latency service as the baseline?
We haven't even began to come close to the switch capacity at CMH-IX but,
in the event that we do, fabric upgrades are part of the original
plan. With exception of peers flat out running out of pipe into the
exchange fabric, I am at a loss to understand why many of the
"commercial" or "for profit" exchange points are constantly having
If peer X and peer Y are exchanging 120M of traffic between each other,
put them on the same blade, in the same switch! If switch<->switch links
are buried, increase their size or number. If the participants at an
exchange have outgrown the technology used at that exchange, upgrade the
> Overprovisioning solves nearly all QoS concerns. There are
> very few QoS requirements.
Agreed. You can never have too much capacity.