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 bmanning@vacation.karoshi.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 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

On Mon, 23 Oct 2000 hardie@equinix.com wrote:

...

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.

One reason we've looked at is the ability to seperate multicast traffic from unicast traffic without having to have seperate physical media. In general, it can be used whenever you want to keep some traffic out of the way of other traffic. Another possible reason along those lines for ethernet based exchanges would be allowing jumbo frames on some VLAN seperate from the basic shared-media exchange. regards, Ted Hardie

If your switch is MCAST aware, you should be able to keep mcast traffic on ports tagged for it to begin with. If your switch isn't mcast aware. you need to find a new switch. As for jumbo frames, will someone remind me what the benefit of using a larger MTU on the edges than you have in the core is? Is the edge device going to aggregate 6 1500-byte packets into a single 9000-byte jumbo frame for me? --- John Fraizer EnterZone, Inc

You mention John Meylor was going to write an Informational draft about using RGMP, as I understood I though RGMP was Cisco proprietary.... if so that could be limiting, but did John and his group write the Informational draft- if so where can I get a copy of it. Thanks Richard Smith Firstnet Leeds email: rsmith@firstnet.co.uk **************************************************************************** ****** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. The views expressed in the email and files transmitted with it are those of the individual, not the company. If you have received this email in error please notify rsmith@firstnet.co.uk ******************************************** ************************************** -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of hardie@equinix.com Sent: 23 October 2000 18:52 To: John Fraizer Cc: hardie@equinix.com; mduckett@bellsouth.net; 'nanog@merit.edu' Subject: Re: Service Provider Exchange requirements

If your switch is MCAST aware, you should be able to keep mcast traffic on ports tagged for it to begin with. If your switch isn't mcast aware. you need to find a new switch.

MCAST aware means different things in different environments. Ideal is a switch that knows which multicast groups a particular port has joins on, rather than simply whether or not it is getting multicast traffic. In an ethernet fabric used as an exchange point, you have inter-AS multicast traffic, so sniffing IGMP doesn't do any good. Sniffing PIM sparse mode for joins would work. In some environments, you might be able to use RGMP to tell the switch which groups have been joined on a particular port (John Meylor mentioned over beer at the Cogent social that his group might consider writing up RGMP as an informational draft, so that number of enviornments may go up).

As for jumbo frames, will someone remind me what the benefit of using a larger MTU on the edges than you have in the core is? Is the edge device going to aggregate 6 1500-byte packets into a single 9000-byte jumbo frame for me?n

If it is not clear, I am talking about using jumbo frames on ethernet VLAN used in an exchange point; this would provide a migration path for service providers who have jumbo frames to the edge, because they could trade them over the exchange point frabric. They could, of course, do the same thing over a private interconnection. regards, Ted Hardie

On Sun, Oct 22, 2000 at 10:34:29PM +0000, bmanning@vacation.karoshi.com wrote:

...

I'll give a few more hints as to what I'm looking for.. Did you answer my questions? :)

Now, now, if you guys keep counting, I'm going to start a purse for the winner and everyone will have to chip in for asking questions and giving answers. :*) [.. MPLS discussion clipped ..] You could use MPLS inside the exchange to provide a transport for IP. But, one could argue that it would have limited usefulness (what amounts to LANs is as you already stated below always easily overprovisioned), given that last time I checked we didn't have something like true peering at the LSP level to peer the actual paths etc etc.. I think you would need something that serves as a clear demarc. I really don't want to mention the ATM P-word, but something which serves as conceptually similiar step; preferably without all the other ATM'ness about it. Nor does anyone seem to have much operational clue as to what something like a true MPLS exchange would look like. I'd love to hear counterpoints.. On the other hand, that challenge alone seems interesting enough that one should perhaps try. :-) I would contend, though, that only somebody wants to peer MPLS BGP-VPNs, the take rate at an exchange point might be rather low, given that people might be so skiddish with these sorts of things that special arrangements between two or more interested parties will probably be forged. Kind of brings up an interesting thought.. does it make sense for and exchange point to perhaps have multiple "planes" on which various things are exchanged? If so, it would perhaps operationally make things a little easier... depending on what was chosen for the plane itself. [..]

...

Is Diff-Serv or ATM QoS a requirement or can 85-90% of requirements be met with loss/latency service as the baseline?

Overprovisioning solves nearly all QoS concerns. There are very few QoS requirements.

True. This obviously assumes that everybody brings their own gear to the party and whatever people do inside of it is nobody else's business as long as it plays nice, doesn't disturb anyone else, bla bla .. as defined by the AUP. Are the AUPs for the various exchange points posted anywhere? How can one get a hold of them? On a much more important point, what *ARE* people's expectations for SLAs etc when it comes to exchange points, be it private and or public? (and I'm asking specifically for what people would like to see rather than what's actually happening. although, both is interesting.) Please speak up.

...

What special arrangements should be made for hosting (e.g., local caching or streamers)? Yes, I'm stretching here a bit.

Reassure your exchange clients that you are -NOT- in direct competition with them.

I agree with you here. I think having colo facilities *NEAR* a NAP but having an obvious (design and otherwise) difference between them is good(tm). Forcing anything above and beyond on traffic exchange is bad, and given how picky we SPs are we probably have all sorts of other/different ideas for how to do just about everything, take rate will probably be low. No? Cheers, Chris -- Christian Kuhtz Architecture, BellSouth.net <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm Atlanta, GA "Speaking for myself only."