PPPoE/IPoE, any recommendations for upgrade?

Hi,

We are currently using PPPoE in our network. I have seen some articles
regarding migration of so-called legacy PPPoE to IPoE. After reviewing some
of them and implementing IPoE in lab environment using Cisco ASR I didn't
fine it that much beneficial to migrate whole system as I need to change a
lot of things. For example:
- I need to add it's support to our radius and obviously BSS system (E.g.
using NAS-PORT-ID instead of username).
- For the addressing part, as I have already using distributed BNG's, I
need to change some of our policies. (For example assigning address blocks
is much easier in PPPoE using framed-route)
- I need to change our customers CPE configuration to use Ethernet
encapsulation.
- I haven't used DHCP in large scale environment.
- I don't have any clear Idea/understanding regarding its
maintainability/troubleshooting and also security.
(Please add if I'm missing any other issue which may run into if I migrate
to IPoE)

Although it has some benefits, I'm not sure if it's that essential to
migrate.
Would you please kindly?
- Share your Ideas/experiences/best practices in this regard?
- If you are already using IPoE, tell more why should I upgrade?
- Considering a DSL network with more than 800K customers using PPPoE, do
you recommend this migration?

Kind Regards,
Nasser

The IPoE and IPoEoADSL I have done didn't need radius, didn't need BNG, didn't need a lot of the complications you're talking about. It could basically be realised in any decent L3 switch as default gateway for the customers instead of needing BNG.

So I'd say if you want to get full potential of IPoE you need to do simplification as well, otherwise there is little use in doing the work if he only thing you want to change is from IPoPPPoE to IPoE encapsulation and keep all the other stuff you're doing.

IPoPPPoE requires special CPE and router at your end to achieve high speeds, because they need to support encapsulation/decapsulation of packets at whatever speed you provide. The number of devices that do this is a lot smaller than the ones that do decent speeds with just IPoE.

So some people will say migrating to IPoE from IPoPPPoE buys them nothing, because they feel they need all the mechanisms they currently use. Greenfield deployments might say "hey, we can do this without a lot of the needed mechanisms for IPoPPPoE" and save a lot of money and complication.

> - If you are already using IPoE, tell more why should I upgrade?

The IPoE and IPoEoADSL I have done didn't need radius, didn't need BNG,

didn't

need a lot of the complications you're talking about. It could basically

be realised in

any decent L3 switch as default gateway for the customers instead of

needing BNG.

So I'd say if you want to get full potential of IPoE you need to do

simplification as

well, otherwise there is little use in doing the work if he only thing you

want to

change is from IPoPPPoE to IPoE encapsulation and keep all the other stuff

you're

doing.

IPoPPPoE requires special CPE and router at your end to achieve high

speeds,

because they need to support encapsulation/decapsulation of packets at

whatever

speed you provide. The number of devices that do this is a lot smaller

than the

ones that do decent speeds with just IPoE.

So some people will say migrating to IPoE from IPoPPPoE buys them nothing,
because they feel they need all the mechanisms they currently use.
Greenfield deployments might say "hey, we can do this without a lot of the

needed

mechanisms for IPoPPPoE" and save a lot of money and complication.

--
Mikael Abrahamsson email: swmike@swm.pp.se

Thanks for your reply. I'm would like this simplicity if I could keep same
functionalities I have in PPPoE. By functionalities I mean:
  - AAA
  - Triple-ply services and classified accounting per service
  - Possibility to suspend a user service in case of over-quota
  - applying fair-share policies

Do I have any option to have simplicity and same functionality together?
  
Regards,
Nasser

Yes, but you'd have to do things differently than you do today. Well, you don't do AAA in that case. You use DHCP option 82 to identify what port, and use that instead of AAA.

So instead of doing everything in the BNG, you have to do it at the access port using SNMP to poll counters and change port policy there.

If this is not your liking, then you have to keep the BNG.

Suspend or shut down a user is easy, just disable their port on the DSLAM
or change their port to a VLAN that only allows them to access/pay their
bill.

Going to PPPoE to IPoE increases the net throughput right?

There are alternative solutions. We're looking at using one from ABN for a
customer that perseveres all of the AAA functionality and supports IPoE
with the same integrationhooks as PPPoE and handles both at the same time
to make transition easier. The project is being staged right now but
anyone who wants to be kept in the loop in how it goes can contact me off
list.

Junos OS Subscriber Management?

http://www.juniper.net/documentation/en_US/junos13.1/information-products/pathway-pages/subscriber-access/index.html

Hi,

I used to work for Redback (who were acquired by Ericsson), and their SmartEdge BNG supports a feature called CLIPS. CLIPS is basically IPoE towards the clients (DHCP based), but with BRAS features. The mac address of the client will be authenticated against your RADIUS and you can pretty much use the same policies as you're used to on PPPoE (with the exception of multicast-related policies of course). I'm not sure, but I think other vendors have similar features nowadays. This might help your migration.

Thanks,

Sabri