On 20/Jun/16 16:07, Baldur Norddahl wrote:
On 2016-06-20 08:50, Mark Tinka wrote:
We don't run l3vpn's for infrastructure requirements. We only run them if a customer wants an l3vpn service. Mark.
For a long time we only had one l3vpn customer: our self. It is a good way to separate the control network from the internet. So our config was "vrf default" = IGP and remote access to devices, "vrf internet" = the thing we deliver to customers.
Okay. Internally, we use l3vpn's for equipment management as well, but not for other services except customer l3vpn requirements. So we don't do Internet in the VRF, for example.
There are two reasons we are not doing l3vpn with ip termination at the access edge devices anymore:
1) We have our own GPON switches and this is our original business. We later connected to the ILEC to resell DSL service on their DSLAMs. The ILEC delivers customers as Q-in-Q with one vlan per customer. Unfortunately our access edge devices do not support layer 3 Q-in-Q termination, so we had no other choice than to backhaul the DSL customers in a l2vpn. We then reconfigured our GPON service to emulate the same Q-in-Q one VLAN per customer so we only have one way to do things.
2) IP address scarcity. We used to allocate IP addresses to the edge devices in blocks of 64 (/26 subnet). But this still creates inefficiency where one area has free address space and another area is out. Also it is much work to constantly allocate new address blocks. It is easier with the centralized solution because customers can be pooled together irrespectively of where they actually live using the supervlan feature.
So these sound like BNG deployments, which I'm okay to centralize for reasons I mentioned before. The issue we were talking about was general Business or IP Transit customers following the same topology. At any rate, it's your network, so you know best. I just wouldn't centralize things for these types of customers for reason I mentioned before.
Also we have trouble with a bad IPv6 implementation, that made the network unstable when we did IPv6 termination at the access edge. This has since been solved. But it is a reminder that we sometimes end up with different solutions than planed due to bugs and other unforeseen trouble.
A day in the life of a network operator. But happy to hear your IPv6 deployment has gone well. Mark.