Subject: [spring] Flat vs non-flat SIDs

From: Robert Raszuk <[email-masked]>
Date: Sat, 25 Sep 2021 17:11:35 +0200

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

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 25 Sep 2021 12:23:04 -0400

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-masked]> wrote:

> 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-masked]
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 26 Sep 2021 00:51:29 +0200

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-masked]> wrote:

>> Yes, originally where SR started there was comparison with flat MPLS
>> label space (except that space was always locally significant). Now we are
>> 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 ?
>>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 25 Sep 2021 23:06:59 -0400

The big difference between CRH & SRv6 is that SRv6 contains the SID and CRH
header 16 bit or 32 bit SID contains an index or pointer to the actual SID
which is encoded in an CRH FIB which can be populated manually via CLI,
PCEP or Netconf/Yang.

Since the CRH SID contains an index to the actual SID IPv6 address, it is
not subject to MSD issues that SRV6 has and thus can have extraordinary
long strict paths without any constraints.

The one caveat to the initial layer of indirection is an extra lookup.

The similar  concept of CRH style  indexing could be applied to SRv6 with a
few bits as mentioned or maybe even done close to identical but via the
SRv6 PGM framework.

Thanks

Gyan
On Sat, Sep 25, 2021 at 6:50 PM Robert Raszuk <[email-masked]> 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.
>>
>>> 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.
>>>
>>> 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.
>>>

*Gyan Mishra*

*M 301 502-1347*