[j-nsp] SRGB Allocation
Mark Tinka
mark.tinka at seacom.com
Tue Aug 11 10:51:49 EDT 2020
On 11/Aug/20 15:57, Andrew Alston wrote:
>
> 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. This is protein.
It would seem, to me, that this is going to gain a lot of BCOP
experience as time goes on and more folk deploy. Looking forward to that.
Mark.
More information about the juniper-nsp
mailing list