I'm of the same opinion as Peter on this. I'm firmly in the PPPoE camp.

Generally speaking the only real case of opposition is the MTU at 1492. However in saying this I feel like it is a non issue with mss adjustment. If the software takes note of the change in mss then there shouldn't be a problem. UDP deployments as far as I have come across are only small packets so once again a non issue.

As a service provider we very easily could increase the MTU to allow for 1500. The issue is that we need to do mss adjustment towards the customer for tcp applications they are hosting (web server, rdp, etc.). Not all CPE's support 1500 MTU PPPoE. This is the primary issue with this. If we increase to allow for it how do then determine which CPEs need the mss adjustment to 1452 and which don't? If all CPE's allowed for 1500 MTU PPPoE we would do this. Until that point it is what it is unfortunately.

Cheers,

Hamish

On Thu, Sep 14, 2017 at 6:48 AM, Brian Gibbons <brian@outersite.co.nz> wrote:
On 13/09/2017 6:38 p.m., Peter Lambrechtsen wrote:
I'm firmly in the PPPoE is the only way to run a fixed broadband network.


Well said

The Internet has done very well using Point to Point links from provider to CPE since the days of SLIP.

DHCP is for wireless and keeps us in a job :)

Cheers

BG


You can change customers IP addresses easily by just kicking them and they come back in worst case 90 seconds (or 5 mins if it's a EUBA connection for the session to timeout). Can't do that on IPoE unless you have stupid low lease times.
RemoteID and CircuitID are inserted in the PPPoE payload so you can auth them without requiring credentials. Much like you use option 82 on IPoE.
No support for username and password so if your friendly LFC has screwed up the provisioning so you can't auth them on RID/CID you can't ask your customer to put in "heyfindme" in their username on the router and they magically appear in the radius logs and then tell the LFC to sort it.
All LFCs support 1508 MTU so if your router and BNG does it then you can get a full 1500 sized packets which you can on Spark.
Routed networks are easy you just allocate a subnet to sit behind the router.
You don't need to waste a /31 per customer and thus 2 public IPs per subscriber or have some dirty flat routed networks across all your customers when each customer is a separate layer 2 network so you have a /22 or something and have a dedicated default route per subnet. PPPoE you only need a single real IP allocated to the interface and then only 2 IPs per subnet being broadcast and network rather than a routed IP too thus losing another ip per range.

Using VLAN 10 means you can use .1q tagging from the CPE and have real working QoS over the link. If you don't need QoS then no need for VLAN 10. But once you've gone down the tagged route it's hard to move back as then you have a customer config nightmare.

Find arguments against the above and I may listen. But until then I am completely sold on PPPoE vs IPoE.

Sent from my phone so excuse the brevity.

-------- Original Message --------
Subject: Re: [nznog] Dialup over Ethernet
From: Don Stokes
To: nznog@list.waikato.ac.nz
CC:

I'm firmly in the PPP Must Die camp.

As far as I can make out, PPPoE is a thing because ISPs built PPP & Radius infrastructure for dial-up, used it to for ADSL (because that was the only way Telecom would let you do it), and continue to use the same back-end stuff to drive PPPoE for ADSL, VDSL, UFB and anything else they can get to speak it.

It has the advantage that IP address management with PPPoE & friends is fairly straightforward, and you don't go wasting IP addresses, given that everything speaking native IP over Ethernet expects to see a subnet with a network, broadcast and gateway address in a /30 or bigger subnet, an issue I addressed here. This is important, because UFB is VLAN-per-circuit; you can't just lump a bunch of clients into a single IP subnet, a la Citylink in the old days.

UFB has PPPoE brains that allows the PPPoE handshake to inform the ISP what service a PPPoE packet, independent of the VLAN tags, which in turn can be fed to a Radius server to identify a customer. (There's also DHCP brains to do the same for DHCP requests. Both are service-order-time options.) I don't believe anyone is actually using usernames/passwords to identify customers any more, but I won't be surprised if I'm wrong. It's not like dial-up where the customer could be coming from anywhere.

Note that PPPoE in most configurations has an MTU of 1492, not 1500 (because there's an 8-byte PPPoE/PPP header between the MAC header and the IP payload). Which is another reason PPPoE needs to be killed. I'm not sure if 1500 MTU PPPoE (i.e. 1508+ MTU Ethernet) is supported by either ISPs or UFB. I believe UFB circuits are happy to take the larger frames, but since I've not tried to work with it, I can't say for sure.

-- don



On 09/13/2017 05:53 PM, Ewen McNeill wrote:
A client had a (business) customer switch over to UFB and needed assistance reconfiguring the (Mikrotik) router being attached to the ONT -- it turned out whoever first set up the Mikrotik (sensibly) assumed it'd be seeing IP packets over VLAN 10, but actually the ISP required IP packets over PPPoE over VLAN 10 in order for it to work.

Looking around it appears this client's customer's ISP isn't the only one that is requiring PPPoE over VLAN tagging over Ethernet for their UFB connections.�� Is there a reason other than "let's make everything look like 1990s dialup so it works with our legacy equipment" for the bit/CPE CPU overhead of PPPoE on UFB, including imposing the lowered usable MTU and PMTU discovery headaches on the end user?

The only one that really comes to mind is "user/password authentication" (rather than needing to collect CPE MAC addresses which seems to happen with, eg, Vodafone cable/FibreX).�� But it's not clear to me why, eg, 802.1X isn't used for the user/password authentication in that case; or DHCP with some extension to pass a "secret" identifier. 20-bytes-per-packet-forever seems a large overhead to pay for user/password authentication at CPE power on.... (Maybe in the beginning there's "lack of CPE support" -- but we're a few years into the UFB rollout, and lots of ISPs seem to be supplying their own ISP-badged CPEs anyway, which could presumably implement whatever was needed.)

Ewen
_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
https://list.waikato.ac.nz/mailman/listinfo/nznog


--
Don Stokes, don@nz.net, 021 796 072

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.



This e-mail message has passed virus scanning by Outersite Technology.

_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
https://list.waikato.ac.nz/mailman/listinfo/nznog

_____________________________________________________________________
This e-mail message has passed virus scanning by Outersite Technology.

This e-mail message has passed virus scanning by Outersite Technology.

_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
https://list.waikato.ac.nz/mailman/listinfo/nznog




--
Cheers,

Hamish