Mailing List Archive

SRGB allocation
Hi list,

For those that have already deployed SR-MPLS, I would be curious to know which methodology you have followed when defining the SRGB label range? Have you just consciously taken an overlapping label range and then during a maintenance window restarted RPD so that other protocols using the overlapping dynamic label range would re-program, or have you managed to find a big enough contiguous unused label range in your network to be used as SRGB?

In our very modestly sized network, the currently running protocols (LDP, RSVP, BGP-LU, MP-BGP) seem to occupy the dynamic label pool 16-999999 very sparsely, leaving not-so-many contiguous free ranges. I'm not having particularly hard time in finding an unused label range in our network, but I'd just be curious to hear how others have managed this.

Antti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: SRGB allocation [ In reply to ]
Hi, Antti,

We have considered multiple options, including the graceful automated RSVP-TE LSP restart, etc. But, in the end, reboot wins.

I would also recommend thinking about allocating the Segment IDentifiers and corresponding SR-MPLS labels in advance to ensure cross-vendor transparency (as they have different default SRGB ranges). It is also important to consider different MPLS implementation specifics, e.g. how MPLS label manager actually allocates the labels.

--
Vladimir Blazhkun (via iPhone).

> On 11 Aug 2020, at 12:27, Antti Ristimäki <antti.ristimaki@csc.fi> wrote:
>
> ?Hi list,
>
> For those that have already deployed SR-MPLS, I would be curious to know which methodology you have followed when defining the SRGB label range? Have you just consciously taken an overlapping label range and then during a maintenance window restarted RPD so that other protocols using the overlapping dynamic label range would re-program, or have you managed to find a big enough contiguous unused label range in your network to be used as SRGB?
>
> In our very modestly sized network, the currently running protocols (LDP, RSVP, BGP-LU, MP-BGP) seem to occupy the dynamic label pool 16-999999 very sparsely, leaving not-so-many contiguous free ranges. I'm not having particularly hard time in finding an unused label range in our network, but I'd just be curious to hear how others have managed this.
>
> Antti
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: SRGB allocation [ In reply to ]
On 11/Aug/20 13:54, Vladimir Blazhkun wrote:

> We have considered multiple options, including the graceful automated RSVP-TE LSP restart, etc. But, in the end, reboot wins.
>
> I would also recommend thinking about allocating the Segment IDentifiers and corresponding SR-MPLS labels in advance to ensure cross-vendor transparency (as they have different default SRGB ranges). It is also important to consider different MPLS implementation specifics, e.g. how MPLS label manager actually allocates the labels.

I'm curious to hear how those who have deployed SR-MPLS feel about this
piece of the migration/adoption.

It's at the back of my mind, but as we aren't currently deploying
SR-MPLS, I haven't given it much thought. But I do know that it's
something one has to carefully think about.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
SRGB Allocation [ In reply to ]
(Apologies if this appears twice, seems my subscription wasn't right the first time!)

Hi Antti,

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.

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 ????

Thanks

Andrew Alston
Group Head Of IP Strategy - Liquid Telecommunications
Juniper Ambassador

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: SRGB Allocation [ In reply to ]
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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: SRGB Allocation [ In reply to ]
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@puck.nether.net> On Behalf Of Mark Tinka
Sent: Tuesday, 11 August 2020 16:51
To: juniper-nsp@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@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp<https://puck.nether.net/mailman/listinfo/juniper-nsp>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: SRGB Allocation [ In reply to ]
I vote for static Adj-SID allocations for the SR-MPLS. It makes operations much more convenient as one might arrange a map of interface name (index) to an Adj-SID.

--
Vladimir Blazhkun (via iPhone).

> On 11 Aug 2020, at 16:58, Andrew Alston <Andrew.Alston@liquidtelecom.com> wrote:
>
> 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.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: SRGB Allocation [ In reply to ]
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 juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp