Re: 1GE L3 aggregation

[Mark Tinka <mark.tinka () seacom mu>]

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.