LSPS2 & LSPS4 - How to run simultaneously? Unique SCIDs

[SeverinAlexB]

In the last spec meeting (1st of Nov), we decided to run LSPS2 and LSPS4 simultaneously so clients can use whatever they want to receive JIT channels. Running them at the same time though, raises questions about what LSPS is responsible in case of an incoming HTLC. They will both process the HTLC which leads to race conditions.

An easy solution to this problem is to give LSPS2 and LSPS4 unique SCIDs (route hints). In this case, arriving HTLCs indicate what LSPS it will proceed with. This should solve (all?) our issues.

I have one concern with it though:
We will use one bit of the SCID (64 bits) to distinguish between LSPS2 and LSPS4. This shrinks the SCID space by 1. Implementation will probably use 1 bit to distinguish between real and alias SCIDs already. This means 2bit are lost.

2bit are no problem. We are using the SCID here as an implicit versioning scheme though. The more LSPSx (aka breaking changes) we have, the more bits we would need. I don't think this is a complete deal breaker but has to be kept in mind.

What do you guys think?

@TheBlueMatt I heard you had a concern with this solution?

[ErikDeSmedt]

The idea of using a bit to distinguish between LSPS2 and LSPS4 looks sound.
However, I don't think we should require it in the spec.

Clients only have a limited number of SCID's and can remember if it is LSPS2 vs LSPS4.
The server can assign a bit to distinguish an LSPS2 from LSPS4. However, I would consider this as an implementation detail.

[SeverinAlexB]

Not sure I agree it is an implementation detail. How else would you distinguish between the two versions?
If we can come up with multiple ways to do the same then great. But for now, it seems like this is the only way to go?

[SeverinAlexB]

In todays LSPSpec meeting, we agreed to use different SCIDs to run LSPS2 and LSPS4 simultaneously. It is up to the implementor on what SCID they use as long as they are different between LSPS2 and LSPS4.

Referencing #50 so when we get back to it, we'll remember.

[ZmnSCPxj-jr]

Should reference #37 as 60 is just a backup

[cdecker]

This is a thing that has often been misunderstood: the SCIDs do not have to be globally unique, just locally unique to the forwarding node. This means that the LSPS can either chose different ranges for SCIDs used in each use-case, or they can annotate the SCID in their local storage with the use-case. It does not make a difference. The SCIDs can also just be numeric DB IDs for all we care, as long as the LSP can retrieve the annotation when forwarding they should be happy.

AS such SCIDs should span the 2D room of (peer_id, use_case), and anything else doesn't matter. When forwarding we are effectively using the short_channel_id as an alias for the node_id to forward to anyway (non-strict forwarding as it was later called), so why not use these semantics here too?