[c-nsp] ASR9k - IPoE termination

[Pshem Kowalczyk]

Hi,

We're testing IPoE termination on ASR9ks and ran into a small, but annoying
issue.
Our subs will terminate on PW-Eth interfaces, that ultimately connect to a
L2 broadcast domain (access network, this is not something we can change).
So when there are two BNGs attached to the same broadcast domain they both
can see the same DHCP-Discovery packets which results in both of the BNGs
building a session for the sub, both BNGs pass the DHCP-Discovery onto the
actual DHCP servers that allocate them IPs. Many CPE's will send
DHCP-Request to both BNGs as well, but then the sub's CPE only takes one
lease and completely ignores the other, so the second session remains idle
for the duration of the lease (we use the 'proxy' functionality) and
ultimately drops. This is not too bad for subs that end up with different
IPs on both BNGs, but for a case where there is a static IP involved - the
same IP ends up on both BNGs (that happily advertise it into the rest of
the network), which blackholes a portion of the traffic until the 'idle'
session times out. Not ideal.

The overarching requirement here is that we have to provide basic
redundancy (so the session can connect to the second BNG if the first one
drops).

So far I've come up with the following scenarios:
1. Active and backup PWEs
  - won't work as there are 2 independent entry point from the broadcast
domain into the MPLS cloud.
2. Somehow checking the state on radius or DHCP servers and either not
allowing the session in (radius) or not responding (or at least delaying
the response) to requests (DHCP)
 - the difficulty here is in determining reliably if the session should be
allowed or not
 - there might be a delay in radius accounting propagation
 - many tested clients sends a high number of DHCP-Discovery packets in
short time, which results in race conditions between the radius/dhcp setup,
as they hit different BNGs/radius/dhcp servers

Ideally I would like delay the building of the session on one bng (similar
to pado-delay in the PPPoE world). Any idea on how this can be achieved?

kind regards
Pshem