Hi Louis,
One last bit from my side as well ...
You are correct that this topic is too wide to discuss on this thread.
Also, I sense that you perhaps have the use-case and applicability in your
mind. Could I request you to consider putting that into the draft so we
could understand the
Hi All，
Thanks for your discussion, here are some informations to help understanding
better.
1. About the application scenario, please refer to the following draft.
https://datatracker.ietf.org/doc/draft-gong-teas-hierarchical-slice-solution/
Flex-Algo can be associated with the level-1
Hi Louis,
First we need to ascertain if it is necessary before we get things flooded
into IGPs. Then we can get to the evaluation of whether or how "evil" it is.
The VLAN analogy seems incorrect to me and a debate on that may be
orthogonal to this topic. I'll wait for the "necessity" to be first
Hi Les,
Thanks. Please see inline [lc3]
/Louis
From: Les Ginsberg (ginsberg)
Sent: Wednesday, April 12, 2023 11:49 PM
To: Louis Chan ; Acee Lindem
Cc: lsr ; Krzysztof Szarkowicz ;
Weiqiang Cheng
Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for
Flex-Algorithm
Krzysztof,
On 12/04/2023 17:50, Krzysztof Szarkowicz wrote:
Hi,
On 2023 -Apr-12, at 17:48, Peter Psenak wrote:
[External Email. Be cautious of content]
Krzysztof,
On 12/04/2023 17:41, Krzysztof Szarkowicz wrote:
Hi,
It is the question, if we could for example have more than 20 (e.g.
Hi Krzysztof,
I got the impression that the use-case/need for these VFA SIDs in the first
place was to carry some indication in the packet for local treatment at
each hop (e.g,, bandwidth profile or QoS treatment?) in the data path since
the forwarding is based on FlexAlgo.
If not, then I am not
Hi,
> On 2023 -Apr-12, at 17:48, Peter Psenak wrote:
>
> [External Email. Be cautious of content]
>
>
> Krzysztof,
>
> On 12/04/2023 17:41, Krzysztof Szarkowicz wrote:
>> Hi,
>>
>> It is the question, if we could for example have more than 20 (e.g.
>> 200), for 200 different service
Hi Krzysztof,
A further question is if it is necessary to carry this "service bandwidth
profile" information in the IGPs in the first place. Why not indicate this
just in the packet? Wouldn't that be a better way to help scale IGPs by not
introducing this into IGPs in the first place? ;-)
One
Krzysiek,
Then let's call it by it's name - you want packet marking to represent
different PHB at segment endpoints.
Yes that may be a valid ask. Not sure if we should embed this in SIDs.
Remember SRH has space for additional function parameters and not
everything needs to be placed into SID or
Krzysztof,
On 12/04/2023 17:41, Krzysztof Szarkowicz wrote:
Hi,
It is the question, if we could for example have more than 20 (e.g.
200), for 200 different service bandwidth guarantees (but having only
one - or handful - SPF calculation domains, where one SPF calculation
domain is one
Louis –
I am having increasing difficulty in correlating what you say in this thread
and what is actually written in the draft.
Please see responses inline. Look for LES2:
From: Louis Chan
Sent: Tuesday, April 11, 2023 7:46 PM
To: Les Ginsberg (ginsberg) ; Acee Lindem
Cc: lsr ; Krzysztof
Hi Changwang,
please see inline ##PP3:
On 12/04/2023 16:46, linchangwang wrote:
Hi Peter,
Please see inline [changwang lin].
Changwang,
please see inline (##PP2):
On 12/04/2023 15:13, linchangwang wrote:
Hi Peter
Please see inline [changwang lin].
We've met the same problem
Ok you can use 20 flex algos today with no extension. Is going to another
level of nesting really necessary ?
On Wed, Apr 12, 2023 at 4:52 PM linchangwang
wrote:
> Hi Acee
>
>
>
> An operator's backbone network is divided into different flex algorithms
> planes according to different SLA
> Number of LSPs in the entire network: 140 * 20 * 32 * 200/1497=12000 LSPs
>
> The performance of IGP has always been affected by the size of the entire
> network's LSDB,
> and even if the periodic flooding time is reduced, there will still be
> convergence issues.
How total number of LSPs in
Hi Acee
An operator's backbone network is divided into different flex algorithms planes
according to different SLA requirements of users.
A flex algo represents a service requirement, such as bandwidth requirements.
20 flex algorithms represent 20 different service bandwidth guarantees,
Hi Peter,
Please see inline [changwang lin].
>Changwang,
>please see inline (##PP2):
On 12/04/2023 15:13, linchangwang wrote:
> Hi Peter
>
> Please see inline [changwang lin].
>
>> We've met the same problem when applying Flex Algo in SRv6 network.
>
> what problem exactly, can you
Hi Weiqiang,
I’m also curious as to how you are using 20 different flex algorithms. Is this
just a hypothetical scenario
to illustrate the mathematics or do you have an actual use case?
> On Apr 12, 2023, at 09:31, Peter Psenak wrote:
>
> Changwang,
>
> please see inline (##PP2):
>
>
>
Changwang,
please see inline (##PP2):
On 12/04/2023 15:13, linchangwang wrote:
Hi Peter
Please see inline [changwang lin].
We've met the same problem when applying Flex Algo in SRv6 network.
what problem exactly, can you please describe it?
[changwang lin]
Advertisement size of per
Weiqiang,
please see inline (##PP):
On 12/04/2023 12:05, 程伟强 wrote:
Hi Louis and Les,
My two cents from operator perspective.
We've met the same problem when applying Flex Algo in SRv6 network.
what problem exactly, can you please describe it?
As the number of slices and the scale of
Hi Louis and Les,
My two cents from operator perspective.
We39ve met the same problem when applying Flex Algo in SRv6 network.
As the number of slices and the scale of the network increases, the convergence
issue which is caused by SIDs advertising and flooding becomes more and more
20 matches
Mail list logo
