On 13/09/17 18:21, Nathan Ward wrote:
In both EUBA and UFB, Chorus or the LFC inserts a headers in to the DHCP or PPPoE messages that convey the Circuit ID and Remote ID. Remote ID is the most commonly used for authentication and corresponds to a provider reference number (ASID in Chorus world, for example).
DHCP relay with additional parameters defining the origin ONT also seems like a sensible way to identify back to the premises in question, if you're doing IP straight over VLAN 10 (etc). That was the sort of "DHCP extension" I had in mind as an alternative to username/password authentication in PPPoE. If PPPoE also has a similar extension at the discovery phase (where the ONT/fibre provider can inject more identification details) then that too seems less problematic than requiring the end user to configure dialup-style PPPoE username/password details (as appears to be required by my client's customer's ISP). But you do still have the PPPoE overhead, and state.
PPPoE’s benefit is LCP keepalives for fast failover. Without them, you need a BNG system that either: > a) has low DHCP timers, or; b) has BFD /similar and you have CPE that support it, or; c) has state syncing with another box
BFD (https://en.wikipedia.org/wiki/Bidirectional_Forwarding_Detection) seems like another obvious "we should arrange to have CPEs that can do this" feature if one were building out a network like UFB from scratch. BFD's overhead is rather less than 8-bytes-per-frame-forever, even at, eg, one BFD exchange per second. Running PPPoE to get LCP keepalive seems a fairly heavyweight solution to the "we'd like faster than 5 minutes failover if a ISP core device dies". Clustering devices for HA ("state syncing with another box") is a fairly common approach (although not without its own set of edge cases to get right in the clustering protocol). Ewen