MAE-Central

Mailman List Mirror (Read Only)
1

> Sorry, but I can't find a Worldcom press release anywhere. I don't feel
> right cutting and pasting the entire article, but the location is slated to
> be Dallas.
>
> (BTW, isn't it scandalous that MFS would copy the PacBell NAP and build a
> MAE using S'com BPX switches? I went back and checked the nanog archives
> and compiled a list of all the ISPs that swore they would never connect to
> an ATM NAP. How many are planning to disconnect from the MAEs when the ATM
> switches come up?)

Yes and no. Sure a lot of people that said they would not connect to a ATM
NAP, but things do change. The current FDDI NAPs are just not able to
support the current load and their is no good way to expand them. ATM has
changed a lot in the last 4 years. ATM switched have come a long way, sure
they are still not where I would like to see them, but they are getting
there. I don't think it matters anyone, the whole public NAP idea (I
think was a good idea) is dead.

I don't think the point is really worth arguing. It's not the fact that
they chose a particular technology.

I think it was particularly nice that they asked their potential
customers what they should deploy.

Who knows...maybe the did ask, but I don't think they asked the right
people.

Dave (who's waiting to see a NAP built with a GSR (or similar) )

2

Dave Siegel <dave@rtd.net> writes:

Dave (who's waiting to see a NAP built with a GSR (or similar) )

Almost. Well, that is, this is almost what you are waiting for.

What you should want is a NAP that scales upwards from a level
below the interfaces that the GSR can give you.

In effect, what you want is a NAP that looks like this:

  {ethernet,atm,POET,HSSI}--7507--POS---1
                blabla------7507--POS---2
                      0---POS---customer
                1---POS---customer
                      2---POS---customer

of course, in order for this to work, you really
want to be running MPLS on all the devices from
the *connectee* inwards.

This gives you a multi-media connection to a NAP
at speeds ranging from slow (you could do DS0s on
a 7507, for example) to fast (you could do STM-16c/OC48c
out the 12012).

Note that I was even really nice and left "atm" up there
as a potential access method. This is similar to what
Milo and I wanted to do with the MAE-WEST conspiracy to
let the NSF declare the PAC*Bell and MAE-WEST facilities
to be co-priority-NAPs. Unfortunately someone (ahem)
played politics better than us on that one front. On the
other hand, the PAC*Bell NAP has hardly been a model of
stunning success as a result...

Anyway, the idea is that you can colocate or not colocate
at this facility as you see fit, and you can use several
access technologies including some carrier's ATM fabric.
The NAP is extensible -- you could have a really big ATM
channel into the 12012 with lots of VCs talking MPLS, for
example, if that was really popular.

There are some interesting questions about what to do when
multiple load-balanced OC48s among several 12012s don't
provide enough bandwidth at a decent cost, but those
interesting questions plague other parts of the Internet
where that will be a ceiling faster (probably).

Deployment problem #1: MPLS availability.

Interim gross hack #1: GRE tunnels across a private
small-i internet using RFC-1918 space. (GRE tax is high,
but it is perhaps less gross a hack than several other
possibilities that have sprung to mind).

The JUUNIPERMCIWORLDPALMPEXETC people reading this may
wish to advance alternatives to the 12012, or a supplement
for the 12012 for "robustness". tli has, after all,
also proposed designs very similar to this; i think
one was even posted to NANOG...

  Sean.

P.S.: POET (packet over E3/T3) is very cool as a sort of
      lower-speed alternative to point-to-point POS. It
does very well in this type of environment... Thank you auntie Cisco.