Honestly if you're concerned with best practices and keeping your LSDBs nice and neat, ready for fast convergence, I would recommend ensuring that your OSPF areas are constructed well. Keep LSAs that don't need to be in an area summarized, and don't let a single area grow too large.
Opaque LSA's are used to extend the capabilities of OSPF, and to allow for transmission of arbitrary data that OSPF does not necessarily need to care about. For example, if you were writing an application and you decided you wanted to use OSPF to transport the application's data but you did not want OSPF to use this data for its own purposes, ie route calculations.
There are three types of Opaque LSA's (in context of the subtype of the Opaque LSA, similar to other LSA types), which determine the scope of flooding of those LSA's:
- Type 9 - link-local scope
- Type 10 - area-local scope
- Type 11 - AS scope
The Opaque LSA has 32 bits allocated for the Opaque Type (8 bits) and the Opaque ID (24 bits). There are (AFAIK) currently four Opaque types that have been allocated by the IANA:
- Traffic Engineering LSA - used for MPLS-TE
- Sycamore Optical Topology Descriptions - likely proprietary. I wasn't able to find much info on this, other than the fact that John Moy works for Sycamore.
- Grace LSA - used for OSPF graceful restart
- Router Information LSA - Intended (but not yet implemented AFAIK) to supplement the options field to allow for communication of optional capabilities between neighbors. Currently the options field is only 8 bits and there is only a single bit that can be used that just determines if a neighbor supports Opaque LSA's. This RI LSA would provide TLV values to signal support of up to 32 different capabilities between neighbors without needing to add more bits to the options field in the LSA.
In regards to practical application of the Opaque LSA, likely the most common implementation you'll see of this in the wild is in MPLS traffic engineering. In OSPF extensions for MPLS traffic engineering, Opaque LSA's are used to communicate traffic engineering interface parameters (such as maximum bandwidth, maximum reservable bandwidth, unreserved bandwidth, etc) throughout an area in order to populate the traffic engineering databases of the routers within the area.
As for "how to use it" - you shouldn't have to, unless you're writing code that you would need to use it. In terms of practical application on a routing platform, on platforms I have experience with, there's not a specific knob you need to turn that "enables" Opaque LSAs. These should be implicitly enabled if you implement something that has dependencies on them, such as MPLS.
Best Answer
You cannot change the LSRefreshTime because it's hard-coded as an "architectural constant" in the OSPF RFC.