[c-nsp] ISP / MPLS "POP" design

[Mark Tinka]

On Friday, November 08, 2013 08:12:04 AM CiscoNSP List 
wrote:

> If you lost a PE, would you migrate those customer tails
> to an alternate PE? (Assume you would to minimise
> downtime?)

This is why we moved to MPLS in the Access, via the Cisco 
ME3600X platform.

With this box, we were now able to offer services directly 
at the access port connecting to the customer's CPE. IPv4, 
IPv6, l2vpn's, l3vpn's (and in the future, Multicast) were 
now being handed off right in the Access. So your only 
concern here is failure of the switch, which motivates 
customers to buy a second link to another switch, either in 
the same or different fibre ring.

Upstream PE router failure is a non-issue in this case since 
the Access rings are, well, rings :-).

> Im interested in how PE failures are dealt with in large
> networks.

When your provider sends you a maintenance notification that 
there could be an outage when they replace the control plane 
on the PE router your service is connected to, they don't 
typically offer you the option of migrating to a PE router 
which will not be undergoing maintenance - certainly not for 
free anyway.

However, to your point, when you trunk a Layer 2 switched 
network to a PE router, all the options previously mentioned 
are how most operators have dealt with this issue (i.e., 
EEM, mirrored VLAN configurations, e.t.c.). 

There is some new tech. that vendors are now starting to 
push where there is inter-chassis state shared for services 
such as NAT, PPPoE, DHCP, e.t.c., which is helpful in 
Broadband scenarios where customers are backhauled to a 
single BRAS, but can quickly be migrated to another BRAS in 
times of failure, helped by inter-chassis state replication.

Inter-chassis state replication is hardware dependent, and 
may not be supported for all the features you need. I know 
it's being developed quite significantly on the ASR1000 
platform, for example, and I did implement it once for NAT44 
so that set-top boxes in an IPTv network don't lose 
connectivity to VoD content if one of the NAT routers 
failed. Feature versatility was a bit lean back then (2011), 
but it has developed quite extensively in the last two 
years.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20131108/79bf4e9f/attachment-0001.sig>