TLS 1.3: HKDF-Expand In RFC5869 I found that the function of the HKDF-Expand on the input assumes the parameter $L$ which denotes length of output keying material in octets ($\leq 255*\text{Hash}_{Length}$), and then the $N$ is computed as $\operatorname{ceil}(L/\text{Hash}_\text{Length})$ and $L$ is a multiple of $\text{Hash}_\text{Length}$, i.e. the number of output blocks equals $N\in [1,..,255]$.

But when analyzing the use of this function in TLS 1.3 to form a key schedule, I see that the input of this function for $L$ parameter is Hash.length when calling the Derive-Secret function for each generated key:

DeriveSecret(EarlySecret, "ext binder" | "res binder", "") = 
    HKDF-Expand-Label(EarlySecret, "ext binder" | "res binder" | Hash(""), Hash.length ) = 
        HKDF-Expand(EarlySecret, "ext binder" | "res binder" | Hash(""), Hash.length) 

i.e. $L$ = Hash.length and $N = 1$? And so for each key.

I'm sure that I'm wrong somewhere but I do not understand where.
As commented by Maarten Bodewes, derived secrects are not session keys. In TLS 1.3, a "derived secret" and a label are further fed into the HKDF.Expand function to generate the desired session/traffic key, secret nonce/IV, resumption key, etc. I think such an intermediate HKDF.Expand step makes a better key separation for security purpose, e.g., corrupting a traffic key intuitively leaks no information about a resumption key because they are not generated from the same "derived secret".

Btw, HKDF.Extract essentially converts a high-entropy input (not sampled from a uniform distribution), e.g., a DH result, to a fixed-length pseudorandom key, while HKDF.Expand takes a pseudorandom key and a label to generate a random string (which for example could be either a derived secret or a session key).