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
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
