|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Service Provider Exchange requirements
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 protected] 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 problems. 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 technology! > > Overprovisioning solves nearly all QoS concerns. There are > very few QoS requirements. Agreed. You can never have too much capacity. --- John Fraizer EnterZone, Inc
|