Yep, it's reasonable (each IRF Member of the IRF Stack - so each 5700 - has a single SFP+ link to a port of SFP+ module installed into the 5400R zl2 chassis...so you can start with at least 2 SFP+ links - and go up to 8 if you have budget for transceivers and FO cables - between the ToR and the 5400R zl2): a ports trunk made through a BAGG (Yes, configured to use LACP on its member ports) between the IRF Stack and the 5400R zl2 chassis.
That way you will achieve (a) resiliency against cable/physical port failures and (b) enhanced throughput between the Rack's ToR level and the access level...especially considering that your Servers are connected to ToR and your clients are connected to the 5400R zl2 chassis.
Pay attention to distribute as much as possible each of your BAGG's member ports on the 5400R zl2's SFP+ module (a) to avoid SFP+ ports oversubrscription [*] and (b) to provide resiliency against the single SFP+ Module failure (if you are forced to use just a single SFP+ Module on 5400R zl2 chassis and to collect there all your SFP+ ports of the BAGG...then there is nothing you can really do against this SFP+ Module failure)...same on the IRF Stack side...probably distributing your BAGG's member ports into both IRF Members would be a good idea (provided that logical IRF ports 1 and 2 between them are respectively binded to aggregated 10G member ports, see - just an example - this discussion about IRF Stacking topology with only two IRF Stack members).
[*] It's about correctly planning SFP+ (or 10GbE) interfaces channels (to Switch's fabric) grouping/usage (also valid when you are going to use those interfaces as BAGG's members) to avoid oversubrscriptions on the SFP+ Module when single interfaces are forced to sustain wire-speed throughput.
