Re: [spring] Flat vs non-flat SIDs

[Gyan Mishra <[e-mail]>]

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 <[e-mail]> wrote:

>
> 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 <[e-mail]> 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 <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spring
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email [e-mail] <[e-mail]>*
>>
>>
>>
>> *M 301 502-1347*
>>
>> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*