[spring] Flat vs non-flat SIDs

[Robert Raszuk <[e-mail]>]

All,

Watching this discussion on how to compress SIDs (modulo what is the best
choice of compressed SID length) a question popped up which perhaps would
be very helpful to clarify.

SR architecture RFC defines notion of global and local SIDs.
Compression analysis discusses state analysis in section 2.3 in respect to
global SIDs by listing few parameters N, I, A, D & V which are essentially
defining SID applications or types.

In all cases the SID or cSID list remains globally flat across all
services. Well yes SIDs have some structure via appended function and
arguments needed in network programming but the question I am struggling
with is not about those.

It seems to me that for data plane scaling instead of always constructing
huge flat lookup trie it may be quite beneficial to have in the front of
each SID a few bits fixed pointer actually directing the real lookup to a
proper service or application table.

Yes, originally where SR started there was comparison with flat MPLS label
space (except that space was always locally significant). Now we are
talking globally (within a domain) significant space which does multiply
this N times.

With that I just want to post this question or really a doubt if no matter
what compression is chosen should we not consider to define a fixed demux
space which can help to divide and conquer data plane with no worries that
if I add few more letters to "N, I, A, D & V chain ... (say S- for slice,
G- for 5G, G'-for 6G etc..." my routers are not going to collapse ?

Again just to restate I am not talking here to come back to locally
significant SIDs. Not at all. Domain wide significant SIDs are cool. I am
talking about making the globally significant compressed SIDs to be
prepended with notion of service(s) they are constructing in a
given network.

- - -

As we have been via MPLS deployments in the past one of the often requested
features was application/services prioritization. If we have one flat SID
space this may not be easy.

Thx,
Robert