> Q1: Should the draft describe how to use QUIC as one of the reliable > transports after initial communication? That is up to the authors and > working group. If someone wants to do the work to specify it, and coordinate > with the QUIC folks to make sure we get it right, then I see no reason we > can't do so. It would however delay the work.
Well, we don't say how you use a TCP connection once the connection is established. I mean, you simply send and receive data. What do you think would need to be said for QUIC, in this context? > Q2: Should the base LISP mechanism be changed to use QUIC instead of UDP? > While a fair quesiton in general, that is out of scope for this draft. And > given that we have a pile of LISP documents about the UDP based mechanism in > the hands of the RFC Editor, I would really like to see us finish our work > before we decide to change its underpinnings. I am sure it could be done. > Once we have completed getting the PS documents out, if someone wanted to > write a draft on how to replace the base UDP with QUIC, go through all of the > protocol implications, include a comparison of state and time issues so as to > make an evaluation practical, and then ask the WG to consider it, well, it > would be up to the WG. But it would need a lot more than "how about we > replace UDP with QUIC?" I agree we should not generally specify this. Not just because we have documents in the queue, but because we need more experience with QUIC to decide its a better way to go. There are a lot of assumptions and reliability put into LISP for sending and receiving datagrams and the state require to have many connections maintained between ITRs and ETRs would be much larger (order of magnitude) than the mesh of TCP connections we see amoung BGP peers, for example. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
