Subject: [lisp] Comments on draft-kouvelas-lisp-map-server-reliable-transport-07 presentation at LISP WG

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Mar 2022 06:09:49 -0700

I had two comments.

First comment:

Make the new proposed r bit in the Map-Notify adjacent to the 8-bit Record Count field. This way if we need a field in the future from the reserved bits they can be contiguous.

Second comment:

In the draft, it should be stated that LISP uses QUIC port 4342. That is the demux layer for QUIC so it can deliver received LISP packets to the LISP application. Joel has asked a QUIC expert how to phrase this.

I believe, but not sure, that if you run LISP over QUIC, the header has a single UDP header, which is used for QUIC.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Mar 2022 09:18:07 -0400

I am checking with a QUIC expert.
 From some preliminary checking, it looks like QUIC runs over a well 
known UDP destination port.  So we can't run QUIC over a separate UDP 
destination port for LISP.  I have asked what we should do to specify 
that the QUIC connection is for LISP.

Yours,
Joel

On 3/22/2022 9:09 AM, Dino Farinacci wrote:
> I had two comments.
> 
> First comment:
> 
> 
> Make the new proposed r bit in the Map-Notify adjacent to the 8-bit 
> Record Count field. This way if we need a field in the future from the 
> reserved bits they can be contiguous.
> 
> Second comment:
> 
> 
> In the draft, it should be stated that LISP uses QUIC port 4342. That is 
> the demux layer for QUIC so it can deliver received LISP packets to the 
> LISP application. Joel has asked a QUIC expert how to phrase this.
> 
> I believe, but not sure, that if you run LISP over QUIC, the header has 
> a single UDP header, which is used for QUIC.
> 
> Dino
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Mar 2022 06:23:36 -0700

> From some preliminary checking, it looks like QUIC runs over a well known UDP destination port.  So we can't run QUIC 

Right, usually 80 or 443. But that is app specific for the former.

> over a separate UDP destination port for LISP.  I have asked what we should do to specify that the QUIC connection is for LISP.

There has to be a demux layer for QUIC clients and I have to guess that it is port number based. Or every app would have to get an IANA assigned QUIC codepoint. I checked iana.org and there are no details about this.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Mar 2022 09:26:59 -0400

As far as I can tell, QUIC is always UDP destination port 443.  Waiting 
to hear from my email.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Mar 2022 06:34:10 -0700

The VPP guys built a socket API interface to QUIC using listen() calls on the application port of choice:

So I think if we say "listen on port 4342 for QUIC connections" isn't an incorrect phrase. Might not be the best one but we'll get guidance from your contacts.

Dino

> On Mar 22, 2022, at 6:26 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> As far as I can tell, QUIC is always UDP destination port 443.  Waiting to hear from my email.
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Mar 2022 10:27:13 -0400

Heard back from a QUIC expert.

As long as we do not want to use QUIC over HTTP, we can use whatever UDP 
port we want to carry QUIC.
I would note that since we may want to have the same node provide 
connectionless (UDP-based) LISP and connection orient (TCP or QUIC) 
LISP, it seems that if we want a well known UDP destination port it 
should be different from 4342.

Also, when we use QUIC for LISP we do need to specify what the 
destination connection-ID (the QUIC internal ID) will be.  There is a 
lot of flexibility on that.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Mar 2022 07:44:39 -0700

> Heard back from a QUIC expert.

Thanks for the quick response.

> As long as we do not want to use QUIC over HTTP, we can use whatever UDP port we want to carry QUIC.

Okay, I don't think we need to run LISP over HTTP/QUIC.

> I would note that since we may want to have the same node provide connectionless (UDP-based) LISP and connection orient (TCP or QUIC) LISP, it seems that if we want a well known UDP destination port it should be different from 4342.
> 
> Also, when we use QUIC for LISP we do need to specify what the destination connection-ID (the QUIC internal ID) will be.  There is a lot of flexibility on that.

Right now we use port 4342 for both TCP and UDP. I say, we spec that we use a connection-ID value of 4342 for QUIC. And we are done with this issue.

Comments?

Dino

---

From: Florin Coras <[email-masked]>
Date: Tue, 22 Mar 2022 07:54:52 -0700

Hi Dino, Joel, 

Just as an FYI. 

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. 

Should also note that LISP in VPP today works only over UDP. 

Regards,
Florin

[1] https://github.com/h2o/quicly

> On Mar 22, 2022, at 7:44 AM, Dino Farinacci <[email-masked]> wrote:
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Mar 2022 11:04:38 -0400

As I understand it, we need both a UDP port number and a destination 
connection ID.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Mar 2022 08:13:04 -0700

> 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…

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?

We need both datagram support (UDP) and QUIC support at the same time on the same ETR.

Dino

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 22 Mar 2022 11:15:50 -0400

LISP "native" and QUIC can't listen to the same UDP port.  Not 
well-defined for dispatching.

Yorus,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Mar 2022 08:20:43 -0700

> LISP "native" and QUIC can't listen to the same UDP port.  Not well-defined for dispatching.

You can TCP listen on port 4342 and UDP listen on port 4342 right now at the same time. So you *should* be able to do the same with a new transport. But I think its implmentation dependent. Hence my question to Florin (for VPP/quicly).

Dino

---

From: Florin Coras <[email-masked]>
Date: Tue, 22 Mar 2022 09:17:59 -0700

> 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

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Mar 2022 09:23:58 -0700

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-masked]> wrote:
>

---

From: Florin Coras <[email-masked]>
Date: Tue, 22 Mar 2022 10:10:46 -0700

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-masked]> wrote:
>

---

From: Florin Coras <[email-masked]>
Date: Tue, 22 Mar 2022 10:13:02 -0700

Agreed.

Florin

> On Mar 22, 2022, at 8:15 AM, Joel Halpern Direct <[email-masked]> wrote:
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Mar 2022 11:18:23 -0700

> 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 say…

That is what I wanted to avoid, because if a QUIC packet with port 4342 is sent to a old system, then the LISP code will think its an invalid packet type. And you can't determine capability because you can't send UDP 4342 packets.  ;-)

> 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. 

Yes, Joel and I determined that. QUIC has to run in the LISP process. This is a pity architecturally. I think we should use the connection-id API, as Joel mentioned. Cleaner.

Dino

---

From: "Alberto Rodriguez-Natal (natal)" <[email-masked]>
Date: Tue, 22 Mar 2022 22:01:21 +0000

> Yes, Joel and I determined that. QUIC has to run in the LISP process. This is a pity architecturally. I think we should use the connection-id API, as Joel mentioned. Cleaner.

Clarification question. Does this mean that we would send QUIC-based LISP messages to UDP port 4342 and it’s up to the LISP stack to demultiplex between vanilla UDP-based LISP and QUIC-based LISP?

Alberto

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Mar 2022 15:30:36 -0700

> Clarification question. Does this mean that we would send QUIC-based LISP messages to UDP port 4342 and it’s up to the LISP stack to demultiplex between vanilla UDP-based LISP and QUIC-based LISP?

Yes, and that is unfortunate. Joel suggested the idea, to be safe, just allocate a new UDP port number for "LISP over QUIC". So an implementation can demux either port in the same process or use a demux layer, run in another process, if it chooses.

Dino