[c-nsp] Metro / NGN hardware/design

[Rubens Kuhl Jr.]

> My first issue is with VPLS, aside from requiring very expensive hardware,
> is it reliable enough for this? (we're the national telco, this will be
> carrying 999/911/112 calls)

Since you are designing the network ground-up, you can use whatever
fits best, and VPLS definitively isn't.
I think L3 is the tool for this job, but I can see a point in
PBB/PBB-TE designs so I would take a (cautious) look at it.
> Would it make sense to build a seperate highly-reliable layer 2 network just
> for the voice to focus on getting extreme uptime out it, and another
> higher-capacity, feature-rich network for the broadband/ethernet services?

Only if they are truly separate networks, and the voice load can take
over the data network if primary voice network fails.

> Any suggestions on how to go about building such a layer 2 network with
> cisco kit? Any opinions of Cisco's REP? ME6524s in each main exchange,
> ME3400s in each mini-exchange, running REP?

ME6524s can't do REP these days; they will soon, but I'm trying for
week to know what is Cisco's definition of soon.

> A gige ring (or several) running around the island linking all of the
> mini-exchanges? A wdm ring (or several) delivering hub-and spoke
> connectivity from each mini-exchange to each main exchange?

Follow the physical topology, failure modes and outside threats
(someone digging near the fiber, drilling oil, chem leakage, local bad
guys, outside invasion forces).

> Because of the voice nature, convergence should be as low as is
> realistically possible, preferably with the likelyhood of human error
> reduced as much as possible.

Redundant networks can survive equipment failures much easier than
human error; simpler networks stand human error better. If you have
two networks, and only one of them (the data services network) is
being constantly touched by operators to provision new services, the
other network will probably survive a long time before someone messes
with it. But it can happen, so your procedures should keep changes
from being done at both networks in some window (say, a week), so
there is always one for the voice traffic to flow.


Rubens