Re: [spring] Flat vs non-flat SIDs

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 <hayabusagsm@gmail.com> 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 <robert@raszuk.net> 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
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
>
>
> *M 301 502-1347*
>
>