VPP is the whole stack in this case, L2 to L7, so just after ip-local processing is done and packet is handed to UDP port 4342 handler, one could try to infer if the packet is QUIC or LISP. Not saying it’s easy or fast :-)
This can potentially work only because LISP, UDP and QUIC are all implemented within VPP, i.e., same process. So this probably cannot be generalized. Florin > On Mar 22, 2022, at 9:23 AM, Dino Farinacci <[email protected]> wrote: > > But by default QUIC would have to run on UDP port 4342 to deliver packets to > a LISP process in user space (since QUIC is in user space too)? > > Dino > >> On Mar 22, 2022, at 9:17 AM, Florin Coras <[email protected]> wrote: >> >> On Mar 22, 2022, at 8:13 AM, Dino Farinacci <[email protected]> wrote: >>> >>>> QUIC is a fully fledged transport in VPP’s host stack so yes, it can >>>> listen on any port. It’s based on quicly [1] and northbound, towards the >>>> app, it exposes an API similar to the one used by other transports, e.g., >>>> TCP, UDP, TLS. The VPP internal APIs are not POSIX compliant. >>> >>> So if an implementation used VPP to implement LISP over QUIC, could the >>> LISP implementation listen on UDP port 4342 and QUIC port 4342 so to speak? >> >> Not by default. QUIC listening on 4342 is equivalent to UDP listening on >> 4342. However, UDP in VPP can be used from outside the host stack, the use >> case being tunnels like LISP, so in theory a “demultiplexer" could be >> implemented. >> >> Florin >> >>> >>> We need both datagram support (UDP) and QUIC support at the same time on >>> the same ETR. >>> >>> Dino >>> >>> >> > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
