frame-relay is like that, because it's a layer 2 technology. Use a routing protocol together with poin-to-point subinterfaces, and you will have no issues anyway.
It seems Paolo has resolved such a case in the past :-)
I try not to have people use FR PVC keepalives because sane network designs do not need that.
Now for history channel hour here's how FR PVC keepalives got developed.
Back in the past millenium some interworked FR-ATM-FR network was unable to convey reliable PVC status in LMI, plus the customer did not wanted to use dynamic routing because they tough they knew better. So after much whining and business case and this and that, IOS BU commits to implement PVC keepalives as a featurette. Unfortunately I don't remember the name of the guy that coded it to give proper credit, but he was, surprise surprise, an Indian.
So he coded the thing and sends an image to me for testing, probably a 2500 affair.
I stuff it on a couple routers and test to the best of my abilities. It worked pretty much right away, write some docs, goes into IOS, case closed, next !?!
I've really no idea how much people are still using it today, with FR quickly becoming legacy.
Paolo, I like the networking history channel :-). I have never used this keepalive in FR-ATM-FR (that is FR-FR PVC endpoints). We had no issues with this. We do had issues with ATM-ATM-FR (that is ATM-FR PVC endpoints). When we were shutting the ATM side, the FR side would not go down. This was causing issues with the activation of backup static routes on the FR side (we had OSPF running anyway). A, I can't remember more details. Every technology is next-generation until proven legacy! :-)
The cause is a fault in the FR network. You cannot fix it, but using a routing protocol, you can activate a backup.
Probably other option is Reliable static routing. But i have seldom seen this deployed in any production.
But its tested good in the Lab anyway.
Hope by this time you guys might have googled it up !