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. _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
