[c-nsp] MPLS speakers behind unreliable link

[Pshem Kowalczyk]

Hi,

We're in early stages of a project that is supposed to connect
multiple small MPLS-speaking devices over DSL links. Currently we're
investigating various options (lab trials will come later) and I would
like to get your input. If you find the idea to be completely
ridiculous - let me know ;-)

The whole network will consist of 500-1500 PE devices (28xx and
possibly some other vendor counterpart) using DSL. Those devices will
connect the the core MPLS network to provide end-to-end connectivity
for the end users in various sites. Bandwidth requirements are very
low (up to 20Mb/s per site).

We're considering two main scenarios:
(remote PE is a small device at the end of the DSL line, local P/PE is
a bigger device connected over GigE or POS to the MPLS core).

1. The core network provides a single VPLS domain all remote PE belong
to. That VPLS domain is used to run separate MPLS between the remote
PEs. The biggest problem we can see so far is the fact that this will
create a very big broadcast domain, possibly spanning over 1000km,
with many devices directly attached to it over DSL and as a result -
quite unstable. We're not sure if ISIS or OSPF can handle such
situation gracefully.

2. Somehow connecting all the remote PEs to local P/PEs (multiple
remote PEs connected to one local P/PE) and using local PE as sort of
aggregation point, that would hid the instability of the DSL network.
We haven't done anything like this before, so I'm not even sure if it
can work - using ISIS create L1 domains from the remote PEs, make the
local P/PEs a L1L2 devices and use L2 to connect to the core. Would
label distribution work in a scenario like that assuming LDP for the
next-hop and MP-BGP for vpn information? After all a ISIS L1 is a
completely stub network, so it shouldn't see any routes from L2. Is
that the case also for LDP (i.e. LDP will not generate a label for a
FEC (prefix) that is not advertised into a L1 domain?)

The main reason for this setup is cost and expected reliability. We
can not use L2TP since some of the remote PEs will provide PWE3 using
a vendor specific solution, all they can use for transport is MPLS (or
IP).

Thanks for your input,

kind regards
Pshem