Linux BNG

[baldur.norddahl at gmail.com (Baldur Norddahl)]

Den 14/07/2018 kl. 19.09 skrev Raymond Burkholder:
>
> Where do you have this happening?  Do you have aggregation switches 
> doing this?  Are those already in place, or being planned?  Because I 
> would make a suggestion for how to do the aggregation.

The POI (Point of Interconnect) with the incumbent telco is one customer 
per vlan using QinQ. This telco owns all the copper and runs the VDSL2 
DSLAMs. They give us a transparent ethernet tunnel to the CPE. We own 
the CPE. Internally the incumbent uses a MPLS network to transport the 
VLANs. We in turn also use MPLS with L2VPN to transport the traffic to 
one of two datacenters.

In addition we have our own FTTH network in the ground. This is GPON on 
Zhone equipment. To make things easier we made the Zhone GPON OLT 
emulate the same one VLAN per customer setup.

The incumbent have telco buildings in each city area. Typically distance 
between buildings is 10 km. In each such building they have a room where 
alternative telcos, like us, can rent rack space. The only available 
power is -48V DC. We currently only have Zhone MXK GPON switches and ZTE 
MPLS switch equipment in these facilities.

Our current BNG solution is some big iron routers (ZTE M6000). This is a 
device that will do things like 4 million routes in hardware and move 
many Tb/s (not that we have traffic anything near that level). It works 
well enough but is not perfect. I think a discussion of the BNG 
limitations of ZTE M6000 would be a different thread.

One of the problems with ZTE M6000 is the price and that goes double for 
any alternatives mentioned here (Cisco, Juniper etc). Right now I am 
facing the prospect of investing in more line cards for M6000. I can buy 
a few servers for the price of one line card and perhaps get a solution 
that is more "perfect".

As to VXLAN the Zhone MXK can not do it and it is not an option for the 
POI with the incumbent. It would be an alternative to running MPLS but 
we are happy with the MPLS solution.

I have considered OpenFlow and might do that. We have OpenFlow capable 
switches and I may be able to offload the work to the switch hardware. 
But I also consider this solution harder to get right than the idea of 
using Linux with tap devices. Also it appears the Openvswitch implements 
a different flavour of OpenFlow than the hardware switch (the hardware 
is limited to some fixed tables that Broadcom made up), so I might not 
be able to start with the software and then move on to hardware.

Regards,

Baldur