[j-nsp] SRGB Allocation

[Andrew Alston]

HI Mark,

Long time no talk.

So – there are fundamentally different things to consider in SR-MPLS – for one thing – and this is kinda lacking in the market – because Node SID’s are typically static – you need a system to track the allocations and avoid duplicate allocations.  Duplication allocation of Node SID can be pretty nasty – effectively you end up with an almost anycast situation.

Adjacency SID’s are less of a problem since they are effectively locally significant – but again, you ideally want to track these if you are doing static.

Now – obviously on the node sid – that’s a lot less labels than you may end up with on the adj sid side, and typically you only go static adj sid if you need to do some pretty careful steering.

We at the moment use a database approach to this – and have very strict rules and checks and balances in place.  We also though do use a lot of static adj sid’s for steering purposes so our database is pretty huge.

Where this can also get more complicated – is when you are doing SRMS – at that point you need to allocate for the SRMS blocks as well – in as limited a capacity as you can since while a 64k SRGB may seem huge – when you start burning through blocks of 256 labels at a time and its getting deaggregated – this can get used pretty fast in a large network.

Thanks

Andrew


From: juniper-nsp <juniper-nsp-bounces at puck.nether.net> On Behalf Of Mark Tinka
Sent: Tuesday, 11 August 2020 16:51
To: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] SRGB Allocation



On 11/Aug/20 15:42, Andrew Alston wrote:

> Sorry for starting a new thread - I wasn't actually subscribed and your email querying about SRGB allocation was brought to my attention by one of your friendly Juniper Ambassadors, so hopped on to give you my thoughts.

Welcome to the list, Andrew. I'm surprised you haven't been on here
until now, actually. I'll send you an invoice for your new weekly tithe
amount for that :-).


> So - With regards to the SRGB Label Range - there are a number of things you need to ask yourself before you go down this road
>
> Firstly - is this a multi-vendor network or a single vendor-network. This is very important - because there is at least one vendor out there who does not support an SRGB range that ends in > 256k - and if you get it wrong you end up with issues trying to fix it.
>
> Secondly - my advice is to make your SRGB range as wide as possible to avoid problems down the line. We use a 64k label range which we then break up into fixed blocks per geographic location across the 15 odd countries we operate in.
> We are currently using 195000 going up - which leaves us still compatible with the Huawei gear.
>
> This however carries another caveat - if you look at devices like the Cisco ASR920 they only support a much more limited SRGB range - last I checked and unless its changed, its limited to something like 16k labels, so you gotta consider that as well.
>
> Rolling this out - we set the label range on each router - and then did rolling reboots to bring it inline - theoretically the routers can move stuff around to free up the labels - practically speaking that doesn’t work 2 well, so a restart was the best option we had.
>
> Hope this helps - please let me know if you need any other info or if I can be of assistance, we've been running SR-MPLS going all the way back to 17.x train, and so we've pretty much seen it all 😊

Not sure if you saw my post, but what I was asking is, especially for
those who have real-world experience with SR-MPLS deployment so far, if
we (by we I mean the industry, not just vendors or operators) do this
label allocation in SR-MPLS differently, what would that be, if the
thought is even worth entertaining.

We are only looking at SR-MPLS deployment in about 5 - 7 years from now,
so can't speak from any experience, just positing.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net<mailto:juniper-nsp at puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp>