I do not see anything in CRH draft which would act as a hardware friendly fixed size context/app/service id field which would direct any further SID lookup to happen in separate SID tables.
Thx, R. On Sat, Sep 25, 2021 at 6:23 PM Gyan Mishra <[email protected]> wrote: > > Interesting you mention indexing as CRH in fact moves the forwarding state > to the FIB, thereby eliminating the MSD issue & uses indexing bits serving > as pointers from the CRH FIB. > > Indexing and indirect address using pointers is definitely an interesting > alternative way of tacking the compression issues. > > Kind Regards > > Gyan > > On Sat, Sep 25, 2021 at 11:11 AM Robert Raszuk <[email protected]> wrote: > >> 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 >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email [email protected] <[email protected]>* > > > > *M 301 502-1347* > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
