There are MANY ways of doing this, but to keep things clear, organised, secure, and balanced, I would set up an OCSP responder configuration for each issuing certificate.
All of this comes from painstakingly tedious testing and configuration done while setting up my own CA that issues it's own leaf/EV certificate via an intermediate CA.
So, sign a new OCSP responder certificate from each issuing level (might as well make it a CRL signing certificate also). This results in 7 total certificates in this case.
In each cert, the caIssuers should point to the immediate issuing CA, and the OCSP extension (authrityInfoAccess) should point to the immediate issuing CA OCSP delegate like so;
Server to IMCA2-OCSP
IMCA2, IMCA2-OCSP to IMCA1-OCSP
IMCA1, IMCA1-OCSP to ROOT-OCSP
ROOT-OCSP to ROOT-OCSP
Root obviously needs to be trusted by whatever computer is verifying.
Each certificate can have multiple caIssuers/OCSP URIs, and an OCSP responder can respond for multiple different CAs if supported.
In my case, I use Apache, a CGI handler, an Expect script, and exec a local instance of openssl ocsp do the OCSP work. The OCSP request includes the issuer hash, which I then look up, and respond using the appropriate CA.
Question 2 is a bit vague, but in this setup, the trust anchor at each level of verification is the immediate issuing CA. So for Server, the IMCA2-OCSP responder only verifies up to IMCA2. I highly recommend this, simply to isolate validation errors to each level. Note that I'm using the same address for all OCSP requests, so this doesn't result in extra OCSP servers being set up.
You can add more intermediates all the way up to the root and include them in the response, but the benefits are almost non-existent. The response would verify that the signatures and certificates are valid all the way up, but any OCSP client worth using would also check the revocation status of each cert... Which means another trip to an OCSP responder anyways.
This entire setup is a top down configuration, load, and security independent setup. OCSP responses for root CAs should ideally be long lived, while lower down, the CAs should be updated frequently. This corresponds to the lifetime of your certificates. For example, my leaf certificates are valid for 30 days, and my issuing OCSP responses are cached for 1 day. My CA certificates are valid for 1 year, and their issuing OCSP responses are cached for 30 days. My rule of thumb is to keep OCSP responses cached for max 1/10th the validity of the shortest issued certificate.
Side note- unless there is a distinct need for a second intermediate I'd skip building one. Root can build as many intermediates as it wants, and each can be used for a different purpose. Each intermediate can issue as many leaf certificates as it wants for whatever purpose. Creating an intermediate that can create intermediates is a bit much. You more likely want to disable that functionality to avoid Hugh path lengths. Even CAs that issue CA certificates to other entities seem to issue from their root.
As always, PM or comment if you need any clarification and I'll edit accordingly.
