LCP echo interval going to down to 3 seconds is apparently expected behaviour, if the previous LCP echo request on the 10 second interval did not receive a response - the interval is lowered temporarily - so currently, Zen advise the term-req is being sent because the Zen end doesn't think that mine responded. However from my dumps earlier it did, these dumps are as late in the process/flow as I can take them so they're 'on the wire' up to the modem. No real data on why I could reproduce the issues at certain times, almost on-demand, with UDP traffic/tunnels but not TCP.
Interesting/confusing aspect, even though I receive and reply to the 10 second interval LCP echo request which is shown by the tcpdump, the Zen end thinks mine didn't respond and so lowers the interval to 3, my end receives again and responds. If the link were dead, then surely I would not expect to receive the LCP echo on the 3 second interval, twice, and respond to it both times? Or, if there is a fault the fault only sometimes impacts the upstream - to allow me to receive and see their echo request, even after the remote end thinks my end did not respond. Whilst coincidences do happen, the problem starting from the word go on the migration should add some weight against it being a line fault (and no sync drop, ever).
After a bit of a slow start investigating at the required low level, finally, Zen are hopefully coming into their own and showing why they have the reputation they do. The last few days/week I've certainly been more encouraged by the technical updates coming back and their desire to continue investigating.