If GR was enabled initially on Cisco and then disabled later, Juniper would still show the stale timer in 'show bgp neighbors'. This retention of routes on Juniper would lead to a traffic drop for the restart time which was initially requested by Cisco (while GR was enabled on it)

1. Consider an eBGP peering between Juniper and Cisco. Lets assume BGP GR configuration is default on Juniper. By default, Juniper only supports helper mode for BGP, without any additional GR configuration. Lets consider GR restart capability is configured on Cisco. So at this point, here is how the 'show BGP neighbor' output will look like on Juniper for the Cisco BGP peer:

2. Now, lets assume that the GR capability is completely disabled on Cisco. After this change, Cisco does not tear down the BGP session and as a result does re-initiate the BGP session with new capabilities which excludes GR. So, Juniper router does not have a way to understand if the GR capability has now been removed on Cisco. Juniper assumes the same capability as we can see in the 'show bgp neighbor' output on Juniper:

3. In this scenario, if the BGP between Cisco-Juniper flaps, Juniper would still retain these routes from Cisco for the restart time (120 seconds in this particular case) and would keep advertising these routes to upstream neighbors attracting traffic towards Cisco. This may lead to a traffic drop for at least 2 mins until an alternate BGP peer is preferred for these impacted prefixes

4. In the scenario where BGP-GR capabilities are deleted on Cisco, the user can manually tear down the BGP once so that the peering comes up with new capabilities

5. For a BGP peering between Juniper-to-Juniper, whenever there is a change in restart capability on any one end, the session is torn down automatically and re-established  so that the new capabilities can be negotiated, as reflected in below output: