Hi Peter ,
I don't agree that adj sid is not a major contributor.
Specifically, we can look at the following two scenarios:
1) flex-algo scenarios:
When deploying SR-TE or SRv6 TE, only ADJ-SID on this interface will increase
with the number of flex algos increased, so we need to optimize this advertise.
2) without flex-algo scenarios:
In scenarios where flex algo is not deployed, the space of LSP can also be
greatly reduced through the VFA mechanism.
I think one usage scenario for VFA is as follows:
DUT1------------------------------DUT2-------------------------------------------------DUT3
Interface 1 interface 1 interface 2
Vfa1-------------------vfa1------------vfa1------------------------------------vfa1
Vfa2-------------------vfa2------------
vfa2------------------------------------vfa2
Vfa3-------------------vfa3------------
vfa3------------------------------------vfa3
Vfa4----------------- -vfa4------------
vfa4------------------------------------vfa4
Vfa: maybe cpu-queue on interface, assign one ADJ-SID to one VFA1
Each label or srv6 end.x sid corresponds to a queue, and VFAR labels are
arranged in the sr policy to achieve SR-TE traffic scheduling
So , this draft with offset would reduce the refresh requirement.
Regards,
Changwang
-----Original Message-----
From: Peter Psenak [mailto:[email protected]]
Sent: Thursday, April 13, 2023 5:09 PM
To: Louis Chan; linchangwang (RD); 程伟强; Les Ginsberg (ginsbe; Acee Lindem
Cc: lsr; Krzysztof Szarkowicz
Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset
forFlex-Algorithm
Loius,
there are many reasons why we need to advertise additional data for
adjacency - TE being a major one. You are trying to optimize the Adj-SID
only, which is not the major contributor anyway. The problem is not
specific to Adj-SID.
In terms of convergence, if you are worried about the flooding speed,
there is a draft in progress:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/
thanks,
Peter
On 13/04/2023 10:52, Louis Chan wrote:
> Hi Peter/all,
>
> Here I do a simple analysis on this scaling issue.
>
> 1. Assume a network with these parameters
> - 20 x Flex-algo
> - 2 x core nodes with 1,000 links
> - network diameter with 5 hops
>
> 2. Just check out the additional advertisement size from core nodes following
> ChangWang example.
>
> For 1 core node,
> n x 20 x 1000
> MPLS-SR：If n = 10 bytes, it is 200K bytes per core node
>
> With 2 core nodes, it is 400KB in total
>
> LSP num: 400KB/1500 = 267 lsps, at least
>
> 3. About the delivery/flooding rate, from
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/
>>>>
> As IS-IS is deployed in greater scale both in the number of nodes in
> an area and in the number of neighbors per node, the impact of the
> historic flooding rates becomes more significant. Consider the
> bringup or failure of a node with 1000 neighbors. This will result
> <--- 1000 adj links
> in a minimum of 1000 LSP updates. At typical LSP flooding rates used
> <--- imply 1000 LSP updates
> today (33 LSPs/second), it would take 30+ seconds simply to send the
> <--- 33lsp/s
> updated LSPs to a given neighbor. Depending on the diameter of the
> network, achieving a consistent LSDB on all nodes in the network
> could easily take a minute or more.
> <--- at least double
> <<<
>
> 267/33 = 8.1 sec
>
>
> With a network diameter of 5, the additional time for delivering the
> consistent LSDB to all remote nodes =
> m x 8.1 sec, where 1 < m < 5 due to inefficiency or implementation issue
>
> It is likely 16+ sec, according to the above description in that draft.
>
> If using offset solution, it is around 0.008sec x 2 = 0.016sec in additional.
> This number is small.
>
> Additional of 16+ sec is significant in global convergence time.
>
> 4. This model/example does not include nodes from second layer, which also
> has 2 x 1,000 adj-sid in the reverse direction. The total number would be
> estimated bigger than 30+ sec.
>
> Should this be improved?
>
> 5. Flooding could be in all directions. Larger size of advertisement could
> delay some important update in busy period. i.e. smaller size in
> advertisement is better.
> And I assume this draft with offset would also reduce the refresh requirement.
>
> Rgds
> Louis
>
> -----Original Message-----
> From: Peter Psenak <[email protected]>
> Sent: Wednesday, April 12, 2023 11:26 PM
> To: linchangwang <[email protected]>; 程伟强
> <[email protected]>; Louis Chan <[email protected]>; Les
> Ginsberg (ginsbe <[email protected]>; Acee Lindem <[email protected]>
> Cc: lsr <[email protected]>; Krzysztof Szarkowicz <[email protected]>
> Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset
> forFlex-Algorithm
>
> [External Email. Be cautious of content]
>
>
> 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 when applying Flex Algo in SRv6 network.
>>>
>>> what problem exactly, can you please describe it?
>>>
>>> [changwang lin]
>>> Advertisement size of per Flex-Algo Adj-SID in the network Related to
>>> F(# of node, # of FA, # of links) For a node with 1,000 links and 20
>>> Flex-Algo
>>> n x 20 x 1000
>>> MPLS-SR：If n = 10 bytes, it is 200K bytes
>>> SRv6： If n = 24 bytes, it is 400K+ bytes
>>> If 500 nodes:
>>> MPLS-SR：it is 200K*500 = 100000k bytes
>>> SRv6： it is 400K+ * 500 = 200000k bytes
>>> If interface mtu=1500, lsp length = 1497
>>> LSPs num:
>>> MPLS-SR：10000k bytes/1497 = 66800 lsps
>>> SRv6： 20000k bytes/1497 = 160320 lsps
>>>
>>> The number of LSPs is too large, and IS-IS needs to periodically
>>> refresh LSPs, resulting in a decrease in ISIS performance and unstable
>>> network operation.
>>
>> ##PP2
>> above is hardly a realistic estimation.
>>
>> In a network with 1k nodes, not every node will have 1k links.
>>
>> Advertising large number of LSPs is not caused by Adj-SIDs.
>> With TE enabled the amount of data flooded per link is larger than
>> advertisement of the 20 Adj-SID. The problem you are highlighting is
>> not specific to Adj-SIDs, it's generic.
>>
>> LSP refresh time can be set to 18 hours and any reasonable
>> implementation does not refresh all LSPs at the same time.
>>
>> [changwang lin]
>> This problem exists in actual operator networking, it can be calculated
>> based on an actual network as follows:
>> One network with 200 nodes
>> One node with 20 interfaces
>> One interface with 32 flex algos
>> Each interface is assigned two types of end. x, one PSP and one non
>> PSP, with each end. x occupying 30 bytes An nbr tlv with basic
>> bandwidth, EAG, and interface address is approximately 140 bytes
>> 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.
>
> ##PP3
> I don't see any relationship between the convergence and the fact that you
> have to advertise 20 ADJ-SIDs per link. If there is one, it's an
> implementation problem.
>
>
>>
>>>
>>> So we need to optimize on the control surface to save LSP space.
>>
>> ##PP2
>> with all the respect, I don't agree. The problem as you described it
>> does not exist.
>> [changwang lin]
>> In the actual deployment of MPLS-SR and SRv6 networks, as the number
>> of flex algos and interfaces increases, the space occupied by adj-sids
>> becomes larger and larger.
>> This is the actual problem when deploying flex algos.
>
> ##PP3
> I don't see any protocol problem.
>
>
>>
>>> Through the optimization notification mechanism mentioned in these
>>> two documents, we have greatly saved LSP space for IS-IS and improved the
>>> performance of IS-IS flex algo in large-scale networking.
>>> At the same time, through the VFA mechanism, in other non flex algo
>>> application scenarios,
>>> such as network slicing scenarios, the LSP space of IS-IS can also
>>> be saved
>>
>> ##PP2
>> it seems to me you are trying to fix the implementation problem with
>> the protocol changes, which is never a good idea.
>>
>> [changwang lin]
>> In actual deployment, a flex algo corresponds to the SLA requirements
>> of a service, such as different bandwidth guarantees,
>> 128 flex algos can correspond to 128 service requirements.
>> When the flex algo specification increases, the corresponding number of LSPs
>> rapidly increases, making it impossible to deploy large flex algo
>> applications.
>> And the mechanism of this draft can greatly improve the space utilization of
>> LSP..
>
> ##PP3
> I appreciate your effort, but I don't believe the proposed compression is
> needed, nor that it addresses the problem you have.
>
> The amount of data being flooded per adjacency may potentially be large and
> Adj-SIDs only represent a fraction of it - even with 32 Adj-SIDs per link you
> are not hitting any protocol limitation.
>
> thanks,
> Peter
>
>
>>
>> thanks,
>> Changwang lin
>>
>>
>>
>>> thanks,
>>> Peter
>>
>>>
>>>
>>> thanks,
>>> Changwang lin
>>>
>>>
>>> -----Original Message-----
>>> From: Lsr [mailto:[email protected]] On Behalf Of Peter Psenak
>>> Sent: Wednesday, April 12, 2023 7:10 PM
>>> To: 程伟强; Louis Chan; Les Ginsberg (ginsbe; Acee Lindem
>>> Cc: lsr; Krzysztof Szarkowicz
>>> Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising
>>> Offset forFlex-Algorithm
>>>
>>> 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?
>>>
>>> [changwang lin]
>>> Advertisement size of per Flex-Algo Adj-SID in the network Related to
>>> F(# of node, # of FA, # of links) For a node with 1,000 links and 20
>>> Flex-Algo
>>> n x 20 x 1000
>>> MPLS-SR：If n = 10 bytes, it is 200K bytes
>>> SRv6： If n = 24 bytes, it is 400K+ bytes
>>> If 500 nodes:
>>> MPLS-SR：it is 200K*500 = 100000k bytes
>>> SRv6： it is 400K+ * 500 = 200000k bytes
>>> If interface mtu=1500, lsp length = 1497
>>> LSP num:
>>> MPLS-SR：10000k bytes/1497 = 66800 lsps
>>> SRv6： 20000k bytes/1497 = 160320 lsps
>>>
>>> The number of LSPs is too large, and IS-IS needs to periodically
>>> refresh LSPs, resulting in a decrease in ISIS performance and unstable
>>> network operation.
>>>
>>> So we need to optimize on the control surface to save LSP space.
>>> Through the optimization notification mechanism mentioned in these
>>> two documents, we have greatly saved LSP space for IS-IS and improved the
>>> performance of IS-IS flex algo in large-scale networking.
>>> At the same time, through the VFA mechanism, in other non flex algo
>>> application scenarios,
>>> such as network slicing scenarios, the LSP space of IS-IS can also
>>> be saved
>>>
>>>>
>>>>
>>>> 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 serious.
>>>>
>>>>
>>>> Due to the problem, it is impossible to apply Flex-Algo in the large
>>>> network, such as the network with more than 1000 routers.
>>>
>>> flex-algo has been successfully deployed in a networks that have more
>>> that 1k nodes.
>>>
>>> Maybe you want deploy the flex-algo for something that it was not
>>> designed for.
>>>
>>>>
>>>>
>>>> I believe Louis'draft provides a good idea to resolve this problem.
>>>> Similar solution for SRv6 SIDs is described in another draft.
>>>
>>> Again, what problem exactly?
>>>
>>> From what I see the drafts tries to pack algo SIDs to save space
>>> in LSP. I don't see how it helps to to deploy flex-algo in a large
>>> scale network.
>>>
>>> thanks,
>>> Peter
>>>
>>>>
>>>>
>>>> About the SIDs assignment, I think it is better to have a scheduled
>>>> assignment than a random assignment as Les mentioned.
>>>>
>>>>
>>>> [1]
>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-c
>>>> heng-lsr-isis-srv6-sid-block/__;!!NEt6yMaO-gk!EX4RtSVg7I0jO4M9ZMrtcj
>>>> Gl2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1kmvLCcctw$
>>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-
>>>> cheng-lsr-isis-srv6-sid-block/__;!!NEt6yMaO-gk!EX4RtSVg7I0jO4M9ZMrtc
>>>> jGl2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1kmvLCcctw$ >
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Weiqiang Cheng
>>>>
>>>>
>>>>
>>>> ----邮件原文----
>>>> *发件人：*Louis Chan <[email protected]>
>>>> *收件
>>>> 人：*"Les Ginsberg (ginsberg)" <[email protected]>,Acee Lindem
>>>> <[email protected]>
>>>> *抄 送:
>>>> *lsr <[email protected]>,Krzysztof Szarkowicz
>>>> <[email protected]>,Weiqiang Cheng <[email protected]>
>>>> *发送时间：*2023-04-12 10:45:56
>>>> *主题：*Re: [Lsr] IETF-
>>>> 116 LSR - IGP extensions for Advertising Offset
>>>> forFlex-Algorithm
>>>>
>>>> Hi Les,
>>>>
>>>> Thanks for the prompt reply. Please see inline for clarification
>>>> [lc2].
>>>>
>>>> /Louis
>>>>
>>>> *From:* Les Ginsberg (ginsberg) <[email protected]>
>>>> *Sent:* Tuesday, April 11, 2023 11:03 PM
>>>> *To:* Louis Chan <[email protected]>; Acee Lindem
>>>> <[email protected]>
>>>> *Cc:* lsr <[email protected]>; Krzysztof Szarkowicz
>>>> <[email protected]>; Weiqiang Cheng
>>>> <[email protected]>
>>>> *Subject:* RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising
>>>> Offset for Flex-Algorithm
>>>>
>>>> *[External Email. Be cautious of content]*
>>>>
>>>> Louis -
>>>>
>>>> Please see inline.
>>>>
>>>> > -----Original Message-----
>>>>
>>>> > From: Louis Chan <[email protected]
>>>> <mailto:[email protected]>>
>>>>
>>>> > Sent: Monday, April 10, 2023 11:01 PM
>>>>
>>>> > To: Les Ginsberg (ginsberg) <[email protected]
>>>> <mailto:[email protected]>>; Acee Lindem
>>>>
>>>> > <[email protected] <mailto:[email protected]>>
>>>>
>>>> > Cc: lsr <[email protected] <mailto:[email protected]>>; Krzysztof
>>>> Szarkowicz <[email protected]
>>>> <mailto:[email protected]>>;
>>>>
>>>> > Weiqiang Cheng <[email protected]
>>>> <mailto:[email protected]>>
>>>>
>>>> > Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising
>>>> Offset for
>>>>
>>>> > Flex-Algorithm
>>>>
>>>> >
>>>>
>>>> > Hi Les,
>>>>
>>>> >
>>>>
>>>> > Thanks for your questions. Please see inline [lc] below.
>>>>
>>>> >
>>>>
>>>> > /Louis
>>>>
>>>> >
>>>>
>>>> > -----Original Message-----
>>>>
>>>> > From: Les Ginsberg (ginsberg) <[email protected]
>>>> <mailto:[email protected]>>
>>>>
>>>> > Sent: Saturday, April 8, 2023 7:34 AM
>>>>
>>>> > To: Acee Lindem <[email protected]
>>>> <mailto:[email protected]>>; Louis Chan <[email protected]
>>>> <mailto:[email protected]>>
>>>>
>>>> > Cc: lsr <[email protected] <mailto:[email protected]>>
>>>>
>>>> > Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising
>>>> Offset for
>>>>
>>>> > Flex-Algorithm
>>>>
>>>> >
>>>>
>>>> > [External Email. Be cautious of content]
>>>>
>>>> >
>>>>
>>>> >
>>>>
>>>> > OK - since Acee opened the door - here are some comments
>>>> from me -
>>>>
>>>> > starting with the most important.
>>>>
>>>> >
>>>>
>>>> > (BTW - I still have limited enthusiasm for this draft.)
>>>>
>>>> >
>>>>
>>>> > 1)The proposal places some restrictions on how operators
>>>> provision their
>>>>
>>>> > network in terms of assigning SIDs and reserving space for
>>>> future
>>>>
>>>> > assignments.
>>>>
>>>> > If operators do not use compatible assignment schemes, then this
>>>> will never
>>>>
>>>> > get deployed. It is therefore not enough to come with a nice idea
>>>> - you must
>>>>
>>>> > have some enthusiasm from the operator community.
>>>>
>>>> >
>>>>
>>>> >
>>>>
>>>> > [lc] If the operator only wants to deploy flex-algo, there is no
>>>> change in their
>>>>
>>>> > Node-sid numbering scheme. For the Adj-sid, these are local
>>>> labels with local
>>>>
>>>> > significant only, and there is no need for any special planning
>>>> for Adj-sid,
>>>>
>>>> > unless you are suggesting they want to make fixed assignment of
>>>> Adj-sid
>>>>
>>>> > label for each link. Even with fixed, the proposed draft has
>>>> benefit on that. I
>>>>
>>>> > will explain later.
>>>>
>>>> >
>>>>
>>>> [LES:] Let's discuss this in the context of prefix-sids - the same
>>>> applies to adj-sids.
>>>>
>>>> Today (i.e., in the absence of your proposal) an operator is free to
>>>> assign any label within the SRGB for a given prefix/algo pair so
>>>> long as it is not assigned to some other prefix/algo context.
>>>>
>>>> Your proposal places some new restrictions. Now, for a given
>>>> flex-algo, whenever an operator assigns a given label for a prefix
>>>> in Algo 0 (call it Label-A0), they must guarantee that
>>>> "Label-A0+offset" for an advertised flex-algo specific offset is
>>>> available to be assigned for the prefix/flex-algo pair - and this
>>>> must be true for all prefixes advertised in algo 0.
>>>>
>>>> This is certainly possible to do, but is not guaranteed to be the
>>>> case in current deployments.
>>>>
>>>> For example - and this is only an example...today an operator might
>>>> utilize a provisioning tool to assign prefix-sids for all supported
>>>> algorithms on all nodes in the network.
>>>>
>>>> To do this, the tool might maintain a database of assigned labels.
>>>> When provisioning a new node/prefix/algorithm, the logic in the tool
>>>> might simply take the next available label in the database.
>>>>
>>>> The result of this would not be consistent with the requirements of
>>>> your draft.
>>>>
>>>> Which is why I say in order to deploy the extension you propose,
>>>> such an operator would have to modify its provisioning tool.
>>>>
>>>> [lc2] There might be some misunderstanding of our proposal. Let me
>>>> give some examples.
>>>>
>>>> Case 1: Flex-Algo only
>>>>
>>>> Prefix offset advertisement: “no”
>>>>
>>>> Adj-sid offset advertisement: yes
>>>>
>>>> In slide 8’s example, FA129 is using label “402001”, and the
>>>> advertisement of this label is using existing methods.
>>>>
>>>> e.g. SRGB = 400000-460000
>>>>
>>>> FA129: index 2001 (preferred value), or one can choose 111,
>>>> 222
>>>>
>>>> FA130 (new): index 3001 (preferred value), or 333, 4444
>>>>
>>>> This does not change how the operator to assign label for prefix-sid
>>>> with their current method. Any index/label could be used for FA
>>>> prefix within SRGB.
>>>>
>>>> The only change is the Adj-sid label allocation, but this “mostly”
>>>> is only “local” to one node. There is no effect on global label
>>>> allocation.
>>>>
>>>> This draft will be compatible to what operators are doing today.
>>>>
>>>> Case 2: VFA only
>>>>
>>>> Prefix offset advertisement: yes
>>>>
>>>> Adj-sid offset advertisement: yes
>>>>
>>>> I agree, with VFA, there would be impact to global allocation to
>>>> node-sid/prefix-sid. But VFA is a totally new concept. No one has
>>>> deployed that yet.
>>>>
>>>> There is no impact to operators which stick to deploy only
>>>> Flex-algo.
>>>>
>>>> Other case: Flex-Algo w/o Adj-sid offset
>>>>
>>>> Continue the example of Case#1 above
>>>>
>>>> Another FA131 is added, but no Adj-sid offset is
>>>> advertised
>>>>
>>>> The question would be
>>>>
>>>> *
>>>>
>>>> Either allow this configuration, and FA131 will fallback using
>>>> Algo 0’s adj-sid
>>>>
>>>> *
>>>>
>>>> Or, disallow this configuration
>>>>
>>>> I tend to “allow” such configuration with mix of FA129, FA130 (with
>>>> adj-sid offset) and FA131 (w/o adj-sid offset)
>>>>
>>>> [/lc2]
>>>>
>>>> Could this be done? Sure.
>>>>
>>>> Do operators want to do this? I do not know.
>>>>
>>>> But since this would be necessary in order to use your proposed
>>>> extension, it is necessary to gauge operator enthusiasm for making
>>>> such changes in order to know whether there is any point in
>>>> proceeding with your proposal.
>>>>
>>>> > In slide 8 of the below presentation
>>>>
>>>> >
>>>>
>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/116
>>>> /materials/slides-116-lsr-03-ietf116-__;!!NEt6yMaO-gk!EX4RtSVg7I0jO4
>>>> M9ZMrtcjGl2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1knGgpMXww$
>>>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/116
>>>> /materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMaO-
>>>> gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79yewG
>>>> B-BleOfrYpSjfI$>
>>>>
>>>> > igp-adv-offset-01
>>>>
>>>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/116
>>>> /materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMaO-
>>>> gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79yewG
>>>> B-BleOfrYpSjfI$>
>>>>
>>>> >
>>>>
>>>> > FA129 is a prefix-sid (400201) allocated by operator, and it can
>>>> be any label.
>>>>
>>>> > There is no connection to how Adj-sid is derived.
>>>>
>>>> > Per Flex-Algo adj-sid assignment is not affecting network
>>>> wide label
>>>>
>>>> > assignment from operation perspective. Each node could have
>>>> different local
>>>>
>>>> > block for such adj-sid assignment. One might need to estimate
>>>> total possible
>>>>
>>>> > number of link in one chassis for such allocation, or it could be
>>>> estimated by
>>>>
>>>> > OS software itself. I also mentioned in the session, if there is
>>>> 100 x FA with
>>>>
>>>> > 1000 links (high end), it is only 100k labels. Is it difficult to
>>>> allocate such.
>>>>
>>>> [LES:] Your proposal does not reduce the number of labels which need
>>>> to be "allocated" and installed in forwarding, it only reduces the
>>>> number of bytes used to advertise this information in LSPs/LSAs.
>>>>
>>>> [lc2] You are correct.
>>>>
>>>> I think, at the same time, it helps reducing time for global
>>>> convergence since the advertisement size is smaller, especially in
>>>> network with long diameter with multi-hops.
>>>>
>>>> Also, in
>>>>
>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!EX4RtSVg7I0jO4M9ZMrtcjGl2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1kl_1f1RjQ$
>>>>
>>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-
>>>> ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!EX4RtSVg7I0jO4M9ZMrtcjG
>>>> l2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1kl_1f1RjQ$ > (which
>>>> you participated in)
>>>>
>>>> >>>
>>>>
>>>> As IS-IS is deployed in greater scale both in the number of
>>>> nodes in
>>>>
>>>> an area and in the number of neighbors per node, the
>>>> impact of the
>>>>
>>>> historic flooding rates becomes more significant.
>>>> Consider the
>>>>
>>>> bringup or failure of a node with 1000 neighbors. This
>>>> will result
>>>>
>>>> in a minimum of 1000 LSP updates. At typical LSP flooding rates
>>>> used
>>>>
>>>> today (33 LSPs/second), it would take 30+ seconds simply
>>>> to send the
>>>>
>>>> updated LSPs to a given neighbor. Depending on the
>>>> diameter of the
>>>>
>>>> network, achieving a consistent LSDB on all nodes in the
>>>> network
>>>>
>>>> could easily take a minute or more.
>>>>
>>>> <<<
>>>>
>>>> This proposed draft will certainly help.
>>>>
>>>> [/lc2]
>>>>
>>>> >
>>>>
>>>> > So, this is why I do not understand your question in full.
>>>>
>>>> >
>>>>
>>>> > If the operator plans to use VFA, that would be a different
>>>> discussion. VFA,
>>>>
>>>> > today, does not exist in deployment.
>>>>
>>>> >
>>>>
>>>> [LES:] My comments here have nothing to do with VFA.
>>>>
>>>> > [/lc]
>>>>
>>>> >
>>>>
>>>> > Have you discussed this idea with any operators?
>>>>
>>>> >
>>>>
>>>> > [lc] I include Wei-qiang from China mobile in this thread. He has
>>>> shown his
>>>>
>>>> > need on this kind of solution. Maybe, he could give his
>>>> perspective here. [/lc]
>>>>
>>>> >
>>>>
>>>> > If so, what has been their response?
>>>>
>>>> > If they are open to the idea, how might they migrate from their
>>>> existing
>>>>
>>>> > assignment schemes to an assignment scheme compatible with
>>>> the
>>>>
>>>> > proposal?
>>>>
>>>> >
>>>>
>>>> > These are questions that need to be answered before considering
>>>> this idea.
>>>>
>>>> >
>>>>
>>>> > [lc] In slide 8, if you see these label numbers
>>>>
>>>> >
>>>>
>>>> > Prefix-sid: 400001, 402001, 406001, 407001
>>>>
>>>> > Adj-sid: 32, 2032, 6032, 7032
>>>>
>>>> >
>>>>
>>>> > From operator perspective or troubleshooting perspective, value
>>>> xxx001
>>>>
>>>> > represent the same node, and value x032 represent the same
>>>> link. This
>>>>
>>>> > makes things more organized and easier to understand.
>>>>
>>>> >
>>>>
>>>> > If all are random labels, I do not see any benefit at all.
>>>>
>>>> > [/lc]
>>>>
>>>> [LES:] I am not commenting on whether the label assignment scheme
>>>> you propose is better or worse than any other.
>>>>
>>>> I am only pointing out that you are imposing new restrictions on how
>>>> labels are allocated.
>>>>
>>>> As you are not in charge of how operators provision their networks
>>>> (nor am I), it is presumptuous of you to think that simply because
>>>> you think this is a better way to do things that operators will be
>>>> happy to modify their existing networks to conform to your proposed
>>>> restrictions.
>>>>
>>>> This isn’t academia - you need to vet this with the operator
>>>> community.
>>>>
>>>> [lc2] Please refer to the examples at the top. The picture should be
>>>> clear by now. There is no restriction to what is deployed
>>>> today. [/lc2]
>>>>
>>>> >
>>>>
>>>> > 2)Section 5 Compatibilty
>>>>
>>>> >
>>>>
>>>> > There is no "compatibility" with legacy nodes - because all nodes
>>>> in the
>>>>
>>>> > network have to have a consistent understanding of what SID is
>>>> assigned to a
>>>>
>>>> > given context (for prefixes and adjacencies) since they might
>>>> need to install
>>>>
>>>> > forwarding entries for that context.
>>>>
>>>> > I do not see any point in deploying this until all nodes support
>>>> it. If you did do
>>>>
>>>> > so, you would need to advertise old and new forms - which
>>>> does the
>>>>
>>>> > opposite of what you are trying to achieve. Instead of reducing
>>>> LSP space
>>>>
>>>> > used you would increase it.
>>>>
>>>> >
>>>>
>>>> > [lc] If the operator just plans to use only Flex-Algo, and no
>>>> VFA, it should be
>>>>
>>>> > compatible with legacy implementation. If legacy nodes do not
>>>> understand
>>>>
>>>> > adj-sid offset notation, these nodes could just ignore it. The
>>>> forwarding
>>>>
>>>> > plane should work with co-existence of old and new nodes. Per
>>>> flex-algo adj-
>>>>
>>>> > sid is only local significant to one node. New nodes should
>>>> detect whether
>>>>
>>>> > legacy nodes exist in the network via such new extension
>>>> advertisement.
>>>>
>>>> > And new nodes should use only algo 0 adj-sid from legacy nodes
>>>> for any TI-
>>>>
>>>> > LFA.
>>>>
>>>> [LES:] Consider a network of 100 nodes.
>>>>
>>>> Let's say the "left-hand-side" of the network consist of legacy
>>>> nodes who do not understand your new advertisements.
>>>>
>>>> The "right-hand-side" of the network consists of upgraded nodes who
>>>> support the new advertisements.
>>>>
>>>> Consider nodes PE-LEFT and PE-RIGHT.
>>>>
>>>> PE-RIGHT advertises a prefix-SID of 1000 for 2.2.2.2/32, and an
>>>> offset of 1000 for flex-algo 128.
>>>>
>>>> PE-LEFT supports flex-algo 128 and wants to install a forwarding
>>>> entry for 2.2.2.2 for flex-algo 128.
>>>>
>>>> It looks in the LSPs originated by PE-RIGHT. It does not see any
>>>> assigned SID for 2.2.2.2/32 flex-algo 128.
>>>>
>>>> It cannot create a forwarding entry. And neither can any other node
>>>> in the left hand side of the network.
>>>>
>>>> When PE-RIGHT stops advertising the explicit prefix SID for
>>>> 2.2.2.2/32 Algo 128, all legacy nodes are unable to create
>>>> forwarding entries for the prefix/algo tuple.
>>>>
>>>> This isn’t backwards compatible.
>>>>
>>>> In general, you cannot advertise information legacy nodes require in
>>>> a new container that legacy nodes do not understand and claim that
>>>> you are backwards compatible.
>>>>
>>>> [lc2] Please refers to the examples for clarification.
>>>>
>>>> 1.
>>>>
>>>> For existing Flex-Algo deployment, it would be compatible. There
>>>> is no change in the container format on how prefix-sid
>>>> 2.2.2.2/32 in FA128 is advertised.
>>>>
>>>> 1.
>>>>
>>>> For new VFA, it would not be compatible. But….it does not mean
>>>> that we could not have VFA running in the same network.
>>>>
>>>> There could be procedures to enhance such. With your example, one
>>>> workaround could be:
>>>>
>>>> For VFA 600, PE-RIGHT detects that PE-LEFT does not participate in
>>>> VFA600 (due to no offset advertisement seen),
>>>>
>>>> *
>>>>
>>>> Either, it spawns new CSPF for VFA600 instead of sharing FA129’s
>>>> result. Bypass PE-LEFT as a result.
>>>>
>>>> *
>>>>
>>>> Or, it uses legacy node FA129 prefix-sid and adj-sid as
>>>> replacement (note: this method needs more comment)
>>>>
>>>> In either ways, VFA600 could work without issue even with legacy
>>>> nodes co-existence.
>>>>
>>>> After PE-LEFT upgraded, VFA600 would be using FA129 CSPF result
>>>> instead, and save CPU resources in each node.
>>>>
>>>> Another question: do we need FAD for VFA600? Currently, no. Not
>>>> mandatory.
>>>>
>>>> But it could be considered if “good to have” parameters are passed
>>>> along with FAD.
>>>>
>>>> [/lc2]
>>>>
>>>> >
>>>>
>>>> > I do not see a major problem. Please give me an example to
>>>> illustrate your
>>>>
>>>> > concern if possible.
>>>>
>>>> >
>>>>
>>>> > Of course, we need to do double check on the claim and
>>>> possibly lab
>>>>
>>>> > verification to see if the backward compatibility could be
>>>> achieved. It could
>>>>
>>>> > be vendor specific.
>>>>
>>>> >
>>>>
>>>> > [/lc]
>>>>
>>>> >
>>>>
>>>> >
>>>>
>>>> > What does deserve discussion is a "hitless migration strategy".
>>>> When full
>>>>
>>>> > support is available, if you were to switch to the new scheme,
>>>> you would
>>>>
>>>> > want to do so without changing any existing SIDs as this
>>>> would avoid
>>>>
>>>> > forwarding disruption. Which means operators would have to modify
>>>> their
>>>>
>>>> > SID assignment scheme in advance of deploying the new scheme.
>>>>
>>>> >
>>>>
>>>> > [lc] For VFA, there would be issue for legacy nodes. I agree. In
>>>> this case,
>>>>
>>>> > solution could be
>>>>
>>>> > - either have a fallback plan for newer nodes if
>>>> detection of legacy nodes
>>>>
>>>> > exist in the network. E.g. spawn new CSPF
>>>>
>>>> > - or, totally not to deploy VFA unless all nodes are
>>>> upgraded.
>>>>
>>>> >
>>>>
>>>> > Section 5 is not updated with VFA inclusion.
>>>>
>>>> [LES:] My comments have nothing to do with VFA.
>>>>
>>>> Please reconsider them after you have understood the backwards
>>>> compatibility issues.
>>>>
>>>> >
>>>>
>>>> > [/lc]
>>>>
>>>> >
>>>>
>>>> > 3)Virtual Flex Algorithm
>>>>
>>>> >
>>>>
>>>> > You have introduced a new concept with very little explanation of
>>>> what it is
>>>>
>>>> > nor how it can be supported.
>>>>
>>>> > For example, how would we determine which nodes support a given
>>>> VFA?
>>>>
>>>> > Since the algorithm value must be greater than 255, it cannot be
>>>> advertised in
>>>>
>>>> > the existing SR Algorithm sub-TLV.
>>>>
>>>> >
>>>>
>>>> > If you are serious about this idea, please provide a more
>>>> complete
>>>>
>>>> > discussion.
>>>>
>>>> >
>>>>
>>>> > [lc] We could illustrate application examples in next
>>>> presentation. For
>>>>
>>>> > ethernet, we have port, and then we have VLAN and stacked vlan.
>>>> History
>>>>
>>>> > has some hints on this.
>>>>
>>>> >
>>>>
>>>> [LES:] You are writing a normative specification. Hoping that all
>>>> readers/implementors have the same "intuition" isn’t sufficient.
>>>>
>>>> Les
>>>>
>>>> > [/lc]
>>>>
>>>> >
>>>>
>>>> > 4)Section 4.3
>>>>
>>>> >
>>>>
>>>> > "R" and "N" flags are now defined in prefix attributes sub-TLV
>>>> (RFC7794)
>>>>
>>>> > They were originally defined in the SR sub-TLV because RFC 7794
>>>> did not exist
>>>>
>>>> > at the time.
>>>>
>>>> > The only reason they continue to exist in RFC 8667 is for
>>>> backwards
>>>>
>>>> > compatibility with early implementation of SR-MPLS based on early
>>>> drafts of
>>>>
>>>> > what became RFC 8667.
>>>>
>>>> > Please do not introduce them in new sub-TLVs - there is no need.
>>>>
>>>> >
>>>>
>>>> > [lc] noted with thanks [/lc]
>>>>
>>>> >
>>>>
>>>> > 5)ADJ-SIDs are NOT allocated from the SRGB as they are local in
>>>> scope.
>>>>
>>>> > They MAY be allocated from the SRLB - or outside either GB range.
>>>>
>>>> > Please correct the document in this regard.
>>>>
>>>> >
>>>>
>>>> > [lc] noted [/lc]
>>>>
>>>> >
>>>>
>>>> > Les
>>>>
>>>> >
>>>>
>>>> > > -----Original Message-----
>>>>
>>>> > > From: Lsr <[email protected] <mailto:[email protected]>>
>>>> On Behalf Of Acee Lindem
>>>>
>>>> > > Sent: Friday, April 7, 2023 11:43 AM
>>>>
>>>> > > To: Louis Chan <[email protected]
>>>> <mailto:[email protected]>>
>>>>
>>>> > > Cc: lsr <[email protected] <mailto:[email protected]>>
>>>>
>>>> > > Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for
>>>> Advertising
>>>>
>>>> > > Offset for Flex-Algorithm
>>>>
>>>> > >
>>>>
>>>> > > Hi Louis,
>>>>
>>>> > >
>>>>
>>>> > > In the interest of initiating discussion, I would like to
>>>> propose the
>>>>
>>>> > > term "Flex Algorithm Traffic Class (FATC)" for the
>>>> sub-division of
>>>>
>>>> > > flex-algorithm traffic referred to in the draft as “Virtual
>>>> Flex Algorithm”.
>>>>
>>>> > >
>>>>
>>>> > > Also, in your terminology, you refer referred to TLVs and
>>>> fields with
>>>>
>>>> > > simply “Algorithm” when RFC 9350 uses “Flex Algorithm”.
>>>>
>>>> > >
>>>>
>>>> > > Thanks,
>>>>
>>>> > > Acee
>>>>
>>>> > >
>>>>
>>>> > >
>>>>
>>>> > >
>>>>
>>>> > > _______________________________________________
>>>>
>>>> > > Lsr mailing list
>>>>
>>>> > > [email protected] <mailto:[email protected]>
>>>>
>>>> > >
>>>>
>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ls
>>>> r_
>>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ls
>>>> r_>
>>>>
>>>> > > _;!!NEt6yMaO-gk!B9ufrV6k-
>>>>
>>>> > c7mtP9JUiXbrF3NCkZ15_UMLBjV_fnJovfz18M5VkkI2F
>>>>
>>>> > > EoixpkxsfMnbqwbR0bpHgoS9E$
>>>>
>>>> >
>>>>
>>>> > Juniper Business Use Only
>>>>
>>>> Juniper Business Use Only
>>>>
>>>>
>>>> Juniper Business Use Only
>>>>
>>>
>>> _______________________________________________
>>> Lsr mailing list
>>> [email protected]
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
>>> __;!!NEt6yMaO-gk!EX4RtSVg7I0jO4M9ZMrtcjGl2sqxcDIFHFZRnk4pocYHUxv9_pAb
>>> 8cfeVdGYX_3gOEDi1kljo7ufGA$
>>> ---------------------------------------------------------------------
>>> ----------------------------------------------------------------
>>> 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
>>> 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
>>> 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
>>> 邮件！
>>> This e-mail and its attachments contain confidential information from
>>> New H3C, which is intended only for the person or entity whose
>>> address is listed above. Any use of the information contained herein
>>> in any way (including, but not limited to, total or partial
>>> disclosure, reproduction, or dissemination) by persons other than the
>>> intended
>>> recipient(s) is prohibited. If you receive this e-mail in error,
>>> please notify the sender by phone or email immediately and delete it!
>>>
>>
>>
>
>
> Juniper Business Use Only
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
