Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising OffsetforFlex-Algorithm

[Peter Psenak <[e-mail]>]

Weiqiang,

On 14/04/2023 15:52, 程伟强 wrote:
> Hi Peter，
> 
> Emails from Louis, Changwang, and Liyan shows that the requirements are 
> from multiple companies and their analysis also shows that for 
> large-scale network with more more algos, existing solution is not enough.
> 
> 
> There are solid requirements and optimized solutions, why not do it?

I appreciate the interest, but I have not seen any evidence that the 
existing encoding does not work for what is defined today - e.g. regular 
flex-algo.

If you are talking about the "virtaul FA", that is not something that is 
even defned properly.

thanks,
Peter

> 
> B.R.
> 
> Weiqiang Cheng
> 
> ----邮件原文----
> 发件人：Peter Psenak  <[e-mail]>
> 收件 
> 人：Weiqiang Cheng  <[e-mail]>,'Peter Psenak' <ppsenak=[e-mail]>,'Louis Chan' <[e-mail]>,'linchangwang' <[e-mail]>,"'Les Ginsberg (ginsbe'" <[e-mail]>,'Acee Lindem' <[e-mail]>
> 抄　 
> 送: 'lsr' <[e-mail]>,'Krzysztof Szarkowicz' <[e-mail]>
> 发送时间：2023-04-14 19:39:40
> 主题：Re: [Lsr] IETF- 
> 116 LSR - IGP extensions for Advertising OffsetforFlex-Algorithm
> 
> Weiqiang,
> 
> On 14/04/2023 13:36, Weiqiang Cheng wrote:
>  > Hi Peter,
>  > Your information about the deployment is good.
>  > It is clear there are two different application scenarios:
>  > 1. For the operators who only need few algos, the current solution is good enough for them, they just need keep it and don't need to worry about the updates.
>  > 2. For the operators who need more algos, they have no legacy deployment. The new solutions we talked about are good for them.
>  >
>  > Now, we need the new solution for the second scenario.
> 
> here we disagree. The existing encoding works just fine for both.
> The fact that it may be optimized, does not mean it is a good idea to do so.
> 
> thanks,
> Peter
> 
>  >
>  > B.R.
>  > Weiqiang Cheng
>  >
>  > -----邮件原件-----
>  > 发件人: Peter Psenak [mailto:[e-mail]]
>  > 发送时间: 2023年4月14日 19:03
>  > 收件 
> 人: Weiqiang Cheng; 'Peter Psenak'; 'Louis Chan'; 'linchangwang'; 'Les Ginsberg (ginsbe'; 'Acee Lindem'
>  > 抄送: 'lsr'; 'Krzysztof Szarkowicz'
>  > 主题: Re: [Lsr] IETF- 
> 116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm
>  >
>  > Weiqiang,
>  >
>  > On 14/04/2023 12:28, Weiqiang Cheng wrote:
>  >> Hi Peter,
>  >> As far as I know, Flex Algo is not really deployed by operators by now, mainly because of the scalability concerns.
>  >
>  > I know bunch that deployed it and are happy with it. They needed few
>  > algos, which is what I consider the right usage of it.
>  >
>  > thanks,
>  > Peter
>  >
>  >> In fact, the Luois team and our team did not know each other before. However, we proposed solutions for MPLS-SR and SRv6 respectively almost at the same time. So you can see it is a common problem for those operators who want to deploy FA at scale.
>  >>
>  >> As discussion in last few days, my observation is that we've agreed the problem is there.
>  >> I think it's a good time to address it now.I suggest that We can discuss more on the solutions further, instead of discussing the requirements.
>  >>
>  >> B.R.
>  >> Weiqiang Cheng
>  >>
>  >>
>  >> -----邮件原件-----
>  >> 发件人: Lsr [mailto:[e-mail]] 代表 Peter Psenak
>  >> 发送时间: 2023年4月14日 16:51
>  >> 收件人: Louis Chan; linchangwang; 程伟 
> 强; Les Ginsberg (ginsbe; Acee Lindem
>  >> 抄送: lsr; Krzysztof Szarkowicz
>  >> 主题: Re: [Lsr] IETF- 
> 116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm
>  >>
>  >> Louis,
>  >>
>  >> On 14/04/2023 10:25, Louis Chan wrote:
>  >>> Hi Peter,
>  >>>
>  >>> I do not think we should divert the focus. It is about efficiency in packing information.
>  >>
>  >> trying to change the way the protocol encodes existing data is something
>  >> that we should not do, unless there is a blocking issue that does not
>  >> allow protocol to work anymore with existing encoding. You have not
>  >> provided evidence of that. All the claims so far have been around the
>  >> lines of implementation efficiency and can be addressed by existing
>  >> protocol mechanism.
>  >>
>  >>>
>  >>> If some important info is required to pass as "necessary evil", then it should.
>  >>>
>  >>> Actually, I am looking forward to applying similar method for other metric or ASLA, proposed by someone, and not necessary by me. And I have seen some drafts are addressing this kind of issues. > e.g. For FA200 and FA201, most link metrics are sharing the same
>  >> values, but only 5% difference in order to achieve some desired
>  >> behavior. In this case, we should find a way to pack it efficiently.
>  >>
>  >> maybe you need a new version of the protocol to do what you propose.
>  >>
>  >> thanks,
>  >> Peter
>  >>
>  >>>
>  >>> Rgds
>  >>> Louis
>  >>>
>  >>> -----Original Message-----
>  >>> From: Peter Psenak <[e-mail]>
>  >>> Sent: Friday, April 14, 2023 3:32 PM
>  >>> To: Louis Chan <[e-mail]>; linchangwang <[e-mail]>; 程伟强 <[e-mail]>; Les Ginsberg (ginsbe <[e-mail]>; Acee Lindem <[e-mail]>
>  >>> Cc: lsr <[e-mail]>; Krzysztof Szarkowicz <[e-mail]>
>  >>> Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm
>  >>>
>  >>> [External Email. Be cautious of content]
>  >>>
>  >>>
>  >>> Louis,
>  >>>
>  >>> On 14/04/2023 07:38, Louis Chan wrote:
>  >>>> Hi Peter,
>  >>>>
>  >>>> For Adj-sid and additional TE requirement, I am not sure what you refer to.
>  >>>> TE requirement or metric requirement? If it is metric related, we have ASLA draft to address some TE related problem.
>  >>>> (To me, to reduce ASLA advertisement is required too.)
>  >>>>
>  >>>> What TE problem are you referring to? Could you give an example to illustrate you concern?
>  >>>
>  >>> there are many TE attributes flooded for TE purposes, e.g., reserved/unreserved bandwidth (per pool), SRLGs, affinities, ...
>  >>>
>  >>> You are picking Ajd-SID, but that is not the only thing that is advertised per link. You may have many SRLGs, many affinities, etc.
>  >>>
>  >>>
>  >>> Peter
>  >>>
>  >>>>
>  >>>> Rgds
>  >>>> Louis
>  >>>>
>  >>>> -----Original Message-----
>  >>>> From: Peter Psenak <[e-mail]>
>  >>>> Sent: Thursday, April 13, 2023 5:09 PM
>  >>>> To: Louis Chan <[e-mail]>; linchangwang
>  >>>> <[e-mail]>; 程伟 
> 强 <[e-mail]>; Les
>  >>>> Ginsberg (ginsbe <[e-mail]>; Acee Lindem
>  >>>> <[e-mail]>
>  >>>> Cc: lsr <[e-mail]>; Krzysztof Szarkowicz <[e-mail]>
>  >>>> Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising
>  >>>> Offset forFlex-Algorithm
>  >>>>
>  >>>> [External Email. Be cautious of content]
>  >>>>
>  >>>>
>  >>>> 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet
>  >>>> f-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!B1_2-Ht7ugsG_Wz7Ii0QGroMZyo9
>  >>>> HTCDcsgefE_pSNK-2bIfNoekducPbd5X3kQ5eMiRk98Jb_PYYg$
>  >>>>
>  >>>> 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie
>  >>>>> t
>  >>>>> f-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!B1_2-Ht7ugsG_Wz7Ii0QGroMZyo
>  >>>>> 9 HTCDcsgefE_pSNK-2bIfNoekducPbd5X3kQ5eMiRk98Jb_PYYg$
>  >>>>>>>>
>  >>>>>        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 <[e-mail]>
>  >>>>> Sent: Wednesday, April 12, 2023 11:26 PM
>  >>>>> To: linchangwang <[e-mail]>; 程伟强
>  >>>>> <[e-mail]>; Louis Chan <[e-mail]>; Les
>  >>>>> Ginsberg (ginsbe <[e-mail]>; Acee Lindem
>  >>>>> <[e-mail]>
>  >>>>> Cc: lsr <[e-mail]>; Krzysztof Szarkowicz
>  >>>>> <[e-mail]>
>  >>>>> 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:[e-mail]] 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!EX4RtSVg7I0jO4M9ZMrt
>  >>>>>>>> c j Gl2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1kmvLCcctw$
>  >>>>>>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draf
>  >>>>>>>> t
>  >>>>>>>> -
>  >>>>>>>> cheng-lsr-isis-srv6-sid-block/__;!!NEt6yMaO-gk!EX4RtSVg7I0jO4M9ZMr
>  >>>>>>>> t c jGl2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1kmvLCcctw$ >
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>> Thanks,
>  >>>>>>>>
>  >>>>>>>> Weiqiang Cheng
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>            ----邮件原文----
>  >>>>>>>>            *发件 
> 人：*Louis Chan  <louisc=[e-mail]>
>  >>>>>>>>            *收件
>  >>>>>>>>            人：*"Les Ginsberg (ginsberg)" <[e-mail]>,Acee Lindem <[e-mail]>
>  >>>>>>>>            *抄　送:
>  >>>>>>>>            *lsr  <[e-mail]>,Krzysztof Szarkowicz  <[e-mail]>,Weiqiang Cheng  <[e-mail]>
>  >>>>>>>>            *发送时间：*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) <[e-mail]>
>  >>>>>>>>            *Sent:* Tuesday, April 11, 2023 11:03 PM
>  >>>>>>>>            *To:* Louis Chan <[e-mail]>; Acee Lindem <[e-mail]>
>  >>>>>>>>            *Cc:* lsr <[e-mail]>; Krzysztof Szarkowicz
>  >>>>>>>>            <[e-mail]>; Weiqiang Cheng
>  >>>>>>>>            <[e-mail]>
>  >>>>>>>>            *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 <[e-mail]
>  >>>>>>>> <mailto:[e-mail]>>
>  >>>>>>>>
>  >>>>>>>>             > Sent: Monday, April 10, 2023 11:01 PM
>  >>>>>>>>
>  >>>>>>>>             > To: Les Ginsberg (ginsberg) <[e-mail]
>  >>>>>>>>            <mailto:[e-mail]>>; Acee Lindem
>  >>>>>>>>
>  >>>>>>>>             > <[e-mail] <mailto:[e-mail]>>
>  >>>>>>>>
>  >>>>>>>>             > Cc: lsr <[e-mail] <mailto:[e-mail]>>; Krzysztof
>  >>>>>>>>            Szarkowicz <[e-mail]
>  >>>>>>>> <mailto:[e-mail]>>;
>  >>>>>>>>
>  >>>>>>>>             > Weiqiang Cheng <[e-mail]
>  >>>>>>>>            <mailto:[e-mail]>>
>  >>>>>>>>
>  >>>>>>>>             > 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) <[e-mail]
>  >>>>>>>>            <mailto:[e-mail]>>
>  >>>>>>>>
>  >>>>>>>>             > Sent: Saturday, April 8, 2023 7:34 AM
>  >>>>>>>>
>  >>>>>>>>             > To: Acee Lindem <[e-mail]
>  >>>>>>>>            <mailto:[e-mail]>>; Louis Chan <[e-mail]
>  >>>>>>>>            <mailto:[e-mail]>>
>  >>>>>>>>
>  >>>>>>>>             > Cc: lsr <[e-mail] <mailto:[e-mail]>>
>  >>>>>>>>
>  >>>>>>>>             > 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/1
>  >>>>>>>> 1
>  >>>>>>>> 6
>  >>>>>>>> /materials/slides-116-lsr-03-ietf116-__;!!NEt6yMaO-gk!EX4RtSVg7I0j
>  >>>>>>>> O
>  >>>>>>>> 4
>  >>>>>>>> M9ZMrtcjGl2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1knGgpMXww$
>  >>>>>>>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/1
>  >>>>>>>> 1
>  >>>>>>>> 6
>  >>>>>>>> /materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMa
>  >>>>>>>> O
>  >>>>>>>> -
>  >>>>>>>> gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79ye
>  >>>>>>>> w
>  >>>>>>>> G
>  >>>>>>>> B-BleOfrYpSjfI$>
>  >>>>>>>>
>  >>>>>>>>            >  igp-adv-offset-01
>  >>>>>>>>
>  >>>>>>>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/1
>  >>>>>>>> 1
>  >>>>>>>> 6
>  >>>>>>>> /materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMa
>  >>>>>>>> O
>  >>>>>>>> -
>  >>>>>>>> gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79ye
>  >>>>>>>> w
>  >>>>>>>> G
>  >>>>>>>> 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!EX4RtSVg7I0jO4M9ZMrtc
>  >>>>>>>> j Gl2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1kl_1f1RjQ$
>  >>>>>>>>
>  >>>>>>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draf
>  >>>>>>>> t
>  >>>>>>>> -
>  >>>>>>>> ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!EX4RtSVg7I0jO4M9ZMrtc
>  >>>>>>>> j G 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 <[e-mail] <mailto:[e-mail]>>
>  >>>>>>>>            On Behalf Of Acee Lindem
>  >>>>>>>>
>  >>>>>>>>             > > Sent: Friday, April 7, 2023 11:43 AM
>  >>>>>>>>
>  >>>>>>>>             > > To: Louis Chan <[e-mail]
>  >>>>>>>> <mailto:[e-mail]>>
>  >>>>>>>>
>  >>>>>>>>             > > Cc: lsr <[e-mail] <mailto:[e-mail]>>
>  >>>>>>>>
>  >>>>>>>>             > > 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
>  >>>>>>>>
>  >>>>>>>>             > > [e-mail] <mailto:[e-mail]>
>  >>>>>>>>
>  >>>>>>>>             > >
>  >>>>>>>>
>  >>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
>  >>>>>>>> l
>  >>>>>>>> s
>  >>>>>>>> r_
>  >>>>>>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/
>  >>>>>>>> l
>  >>>>>>>> s
>  >>>>>>>> r_>
>  >>>>>>>>
>  >>>>>>>>             > > _;!!NEt6yMaO-gk!B9ufrV6k-
>  >>>>>>>>
>  >>>>>>>>             > c7mtP9JUiXbrF3NCkZ15_UMLBjV_fnJovfz18M5VkkI2F
>  >>>>>>>>
>  >>>>>>>>             > > EoixpkxsfMnbqwbR0bpHgoS9E$
>  >>>>>>>>
>  >>>>>>>>             >
>  >>>>>>>>
>  >>>>>>>>             > Juniper Business Use Only
>  >>>>>>>>
>  >>>>>>>>            Juniper Business Use Only
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>            Juniper Business Use Only
>  >>>>>>>>
>  >>>>>>>
>  >>>>>>> _______________________________________________
>  >>>>>>> Lsr mailing list
>  >>>>>>> [e-mail]
>  >>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l
>  >>>>>>> s
>  >>>>>>> r
>  >>>>>>> __;!!NEt6yMaO-gk!EX4RtSVg7I0jO4M9ZMrtcjGl2sqxcDIFHFZRnk4pocYHUxv9_p
>  >>>>>>> A
>  >>>>>>> b
>  >>>>>>> 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
>  >>>>>
>  >>>>
>  >>>>
>  >>>> Juniper Business Use Only
>  >>>>
>  >>>
>  >>>
>  >>> Juniper Business Use Only
>  >>>
>  >>
>  >>
>  >> _______________________________________________
>  >> Lsr mailing list
>  >> [e-mail]
>  >> https://www.ietf.org/mailman/listinfo/lsr
>  >>
>  >>
>  >>
>  >>
>  >> _______________________________________________
>  >> Lsr mailing list
>  >> [e-mail]
>  >> https://www.ietf.org/mailman/listinfo/lsr
>  >>
>  >
>  >
>  >
>  >
>  >
> 
> 
> Subject：Re: [Lsr] IETF- 
> 116 LSR - IGP extensions for Advertising OffsetforFlex-Algorithm
> 
> Weiqiang,
> 
> On 14/04/2023 13:36, Weiqiang Cheng wrote:
>  > Hi Peter,
>  > Your information about the deployment is good.
>  > It is clear there are two different application scenarios:
>  > 1. For the operators who only need few algos, the current solution is good enough for them, they just need keep it and don't need to worry about the updates.
>  > 2. For the operators who need more algos, they have no legacy deployment. The new solutions we talked about are good for them.
>  >
>  > Now, we need the new solution for the second scenario.
> 
> here we disagree. The existing encoding works just fine for both.
> The fact that it may be optimized, does not mean it is a good idea to do so.
> 
> thanks,
> Peter
> 
>  >
>  > B.R.
>  > Weiqiang Cheng
>  >
>  > -----邮件原件-----
>  > 发件人: Peter Psenak [mailto:[e-mail]]
>  > 发送时间: 2023年4月14日 19:03
>  > 收件 
> 人: Weiqiang Cheng; 'Peter Psenak'; 'Louis Chan'; 'linchangwang'; 'Les Ginsberg (ginsbe'; 'Acee Lindem'
>  > 抄送: 'lsr'; 'Krzysztof Szarkowicz'
>  > 主题: Re: [Lsr] IETF- 
> 116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm
>  >
>  > Weiqiang,
>  >
>  > On 14/04/2023 12:28, Weiqiang Cheng wrote:
>  >> Hi Peter,
>  >> As far as I know, Flex Algo is not really deployed by operators by now, mainly because of the scalability concerns.
>  >
>  > I know bunch that deployed it and are happy with it. They needed few
>  > algos, which is what I consider the right usage of it.
>  >
>  > thanks,
>  > Peter
>  >
>  >> In fact, the Luois team and our team did not know each other before. However, we proposed solutions for MPLS-SR and SRv6 respectively almost at the same time. So you can see it is a common problem for those operators who want to deploy FA at scale.
>  >>
>  >> As discussion in last few days, my observation is that we've agreed the problem is there.
>  >> I think it's a good time to address it now.I suggest that We can discuss more on the solutions further, instead of discussing the requirements.
>  >>
>  >> B.R.
>  >> Weiqiang Cheng
>  >>
>  >>
>  >> -----邮件原件-----
>  >> 发件人: Lsr [mailto:[e-mail]] 代表 Peter Psenak
>  >> 发送时间: 2023年4月14日 16:51
>  >> 收件人: Louis Chan; linchangwang; 程伟 
> 强; Les Ginsberg (ginsbe; Acee Lindem
>  >> 抄送: lsr; Krzysztof Szarkowicz
>  >> 主题: Re: [Lsr] IETF- 
> 116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm
>  >>
>  >> Louis,
>  >>
>  >> On 14/04/2023 10:25, Louis Chan wrote:
>  >>> Hi Peter,
>  >>>
>  >>> I do not think we should divert the focus. It is about efficiency in packing information.
>  >>
>  >> trying to change the way the protocol encodes existing data is something
>  >> that we should not do, unless there is a blocking issue that does not
>  >> allow protocol to work anymore with existing encoding. You have not
>  >> provided evidence of that. All the claims so far have been around the
>  >> lines of implementation efficiency and can be addressed by existing
>  >> protocol mechanism.
>  >>
>  >>>
>  >>> If some important info is required to pass as "necessary evil", then it should.
>  >>>
>  >>> Actually, I am looking forward to applying similar method for other metric or ASLA, proposed by someone, and not necessary by me. And I have seen some drafts are addressing this kind of issues. > e.g. For FA200 and FA201, most link metrics are sharing the same
>  >> values, but only 5% difference in order to achieve some desired
>  >> behavior. In this case, we should find a way to pack it efficiently.
>  >>
>  >> maybe you need a new version of the protocol to do what you propose.
>  >>
>  >> thanks,
>  >> Peter
>  >>
>  >>>
>  >>> Rgds
>  >>> Louis
>  >>>
>  >>> -----Original Message-----
>  >>> From: Peter Psenak <[e-mail]>
>  >>> Sent: Friday, April 14, 2023 3:32 PM
>  >>> To: Louis Chan <[e-mail]>; linchangwang <[e-mail]>; 程伟强 <[e-mail]>; Les Ginsberg (ginsbe <[e-mail]>; Acee Lindem <[e-mail]>
>  >>> Cc: lsr <[e-mail]>; Krzysztof Szarkowicz <[e-mail]>
>  >>> Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm
>  >>>
>  >>> [External Email. Be cautious of content]
>  >>>
>  >>>
>  >>> Louis,
>  >>>
>  >>> On 14/04/2023 07:38, Louis Chan wrote:
>  >>>> Hi Peter,
>  >>>>
>  >>>> For Adj-sid and additional TE requirement, I am not sure what you refer to.
>  >>>> TE requirement or metric requirement? If it is metric related, we have ASLA draft to address some TE related problem.
>  >>>> (To me, to reduce ASLA advertisement is required too.)
>  >>>>
>  >>>> What TE problem are you referring to? Could you give an example to illustrate you concern?
>  >>>
>  >>> there are many TE attributes flooded for TE purposes, e.g., reserved/unreserved bandwidth (per pool), SRLGs, affinities, ...
>  >>>
>  >>> You are picking Ajd-SID, but that is not the only thing that is advertised per link. You may have many SRLGs, many affinities, etc.
>  >>>
>  >>>
>  >>> Peter
>  >>>
>  >>>>
>  >>>> Rgds
>  >>>> Louis
>  >>>>
>  >>>> -----Original Message-----
>  >>>> From: Peter Psenak <[e-mail]>
>  >>>> Sent: Thursday, April 13, 2023 5:09 PM
>  >>>> To: Louis Chan <[e-mail]>; linchangwang
>  >>>> <[e-mail]>; 程伟 
> 强 <[e-mail]>; Les
>  >>>> Ginsberg (ginsbe <[e-mail]>; Acee Lindem
>  >>>> <[e-mail]>
>  >>>> Cc: lsr <[e-mail]>; Krzysztof Szarkowicz <[e-mail]>
>  >>>> Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising
>  >>>> Offset forFlex-Algorithm
>  >>>>
>  >>>> [External Email. Be cautious of content]
>  >>>>
>  >>>>
>  >>>> 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet
>  >>>> f-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!B1_2-Ht7ugsG_Wz7Ii0QGroMZyo9
>  >>>> HTCDcsgefE_pSNK-2bIfNoekducPbd5X3kQ5eMiRk98Jb_PYYg$
>  >>>>
>  >>>> 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie
>  >>>>> t
>  >>>>> f-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!B1_2-Ht7ugsG_Wz7Ii0QGroMZyo
>  >>>>> 9 HTCDcsgefE_pSNK-2bIfNoekducPbd5X3kQ5eMiRk98Jb_PYYg$
>  >>>>>>>>
>  >>>>>        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 <[e-mail]>
>  >>>>> Sent: Wednesday, April 12, 2023 11:26 PM
>  >>>>> To: linchangwang <[e-mail]>; 程伟强
>  >>>>> <[e-mail]>; Louis Chan <[e-mail]>; Les
>  >>>>> Ginsberg (ginsbe <[e-mail]>; Acee Lindem
>  >>>>> <[e-mail]>
>  >>>>> Cc: lsr <[e-mail]>; Krzysztof Szarkowicz
>  >>>>> <[e-mail]>
>  >>>>> 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:[e-mail]] 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!EX4RtSVg7I0jO4M9ZMrt
>  >>>>>>>> c j Gl2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1kmvLCcctw$
>  >>>>>>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draf
>  >>>>>>>> t
>  >>>>>>>> -
>  >>>>>>>> cheng-lsr-isis-srv6-sid-block/__;!!NEt6yMaO-gk!EX4RtSVg7I0jO4M9ZMr
>  >>>>>>>> t c jGl2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1kmvLCcctw$ >
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>> Thanks,
>  >>>>>>>>
>  >>>>>>>> Weiqiang Cheng
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>            ----邮件原文----
>  >>>>>>>>            *发件 
> 人：*Louis Chan  <louisc=[e-mail]>
>  >>>>>>>>            *收件
>  >>>>>>>>            人：*"Les Ginsberg (ginsberg)" <[e-mail]>,Acee Lindem <[e-mail]>
>  >>>>>>>>            *抄　送:
>  >>>>>>>>            *lsr  <[e-mail]>,Krzysztof Szarkowicz  <[e-mail]>,Weiqiang Cheng  <[e-mail]>
>  >>>>>>>>            *发送时间：*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) <[e-mail]>
>  >>>>>>>>            *Sent:* Tuesday, April 11, 2023 11:03 PM
>  >>>>>>>>            *To:* Louis Chan <[e-mail]>; Acee Lindem <[e-mail]>
>  >>>>>>>>            *Cc:* lsr <[e-mail]>; Krzysztof Szarkowicz
>  >>>>>>>>            <[e-mail]>; Weiqiang Cheng
>  >>>>>>>>            <[e-mail]>
>  >>>>>>>>            *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 <[e-mail]
>  >>>>>>>> <mailto:[e-mail]>>
>  >>>>>>>>
>  >>>>>>>>             > Sent: Monday, April 10, 2023 11:01 PM
>  >>>>>>>>
>  >>>>>>>>             > To: Les Ginsberg (ginsberg) <[e-mail]
>  >>>>>>>>            <mailto:[e-mail]>>; Acee Lindem
>  >>>>>>>>
>  >>>>>>>>             > <[e-mail] <mailto:[e-mail]>>
>  >>>>>>>>
>  >>>>>>>>             > Cc: lsr <[e-mail] <mailto:[e-mail]>>; Krzysztof
>  >>>>>>>>            Szarkowicz <[e-mail]
>  >>>>>>>> <mailto:[e-mail]>>;
>  >>>>>>>>
>  >>>>>>>>             > Weiqiang Cheng <[e-mail]
>  >>>>>>>>            <mailto:[e-mail]>>
>  >>>>>>>>
>  >>>>>>>>             > 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) <[e-mail]
>  >>>>>>>>            <mailto:[e-mail]>>
>  >>>>>>>>
>  >>>>>>>>             > Sent: Saturday, April 8, 2023 7:34 AM
>  >>>>>>>>
>  >>>>>>>>             > To: Acee Lindem <[e-mail]
>  >>>>>>>>            <mailto:[e-mail]>>; Louis Chan <[e-mail]
>  >>>>>>>>            <mailto:[e-mail]>>
>  >>>>>>>>
>  >>>>>>>>             > Cc: lsr <[e-mail] <mailto:[e-mail]>>
>  >>>>>>>>
>  >>>>>>>>             > 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/1
>  >>>>>>>> 1
>  >>>>>>>> 6
>  >>>>>>>> /materials/slides-116-lsr-03-ietf116-__;!!NEt6yMaO-gk!EX4RtSVg7I0j
>  >>>>>>>> O
>  >>>>>>>> 4
>  >>>>>>>> M9ZMrtcjGl2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1knGgpMXww$
>  >>>>>>>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/1
>  >>>>>>>> 1
>  >>>>>>>> 6
>  >>>>>>>> /materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMa
>  >>>>>>>> O
>  >>>>>>>> -
>  >>>>>>>> gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79ye
>  >>>>>>>> w
>  >>>>>>>> G
>  >>>>>>>> B-BleOfrYpSjfI$>
>  >>>>>>>>
>  >>>>>>>>            >  igp-adv-offset-01
>  >>>>>>>>
>  >>>>>>>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/1
>  >>>>>>>> 1
>  >>>>>>>> 6
>  >>>>>>>> /materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMa
>  >>>>>>>> O
>  >>>>>>>> -
>  >>>>>>>> gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79ye
>  >>>>>>>> w
>  >>>>>>>> G
>  >>>>>>>> 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!EX4RtSVg7I0jO4M9ZMrtc
>  >>>>>>>> j Gl2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1kl_1f1RjQ$
>  >>>>>>>>
>  >>>>>>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draf
>  >>>>>>>> t
>  >>>>>>>> -
>  >>>>>>>> ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!EX4RtSVg7I0jO4M9ZMrtc
>  >>>>>>>> j G 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 <[e-mail] <mailto:[e-mail]>>
>  >>>>>>>>            On Behalf Of Acee Lindem
>  >>>>>>>>
>  >>>>>>>>             > > Sent: Friday, April 7, 2023 11:43 AM
>  >>>>>>>>
>  >>>>>>>>             > > To: Louis Chan <[e-mail]
>  >>>>>>>> <mailto:[e-mail]>>
>  >>>>>>>>
>  >>>>>>>>             > > Cc: lsr <[e-mail] <mailto:[e-mail]>>
>  >>>>>>>>
>  >>>>>>>>             > > 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
>  >>>>>>>>
>  >>>>>>>>             > > [e-mail] <mailto:[e-mail]>
>  >>>>>>>>
>  >>>>>>>>             > >
>  >>>>>>>>
>  >>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
>  >>>>>>>> l
>  >>>>>>>> s
>  >>>>>>>> r_
>  >>>>>>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/
>  >>>>>>>> l
>  >>>>>>>> s
>  >>>>>>>> r_>
>  >>>>>>>>
>  >>>>>>>>             > > _;!!NEt6yMaO-gk!B9ufrV6k-
>  >>>>>>>>
>  >>>>>>>>             > c7mtP9JUiXbrF3NCkZ15_UMLBjV_fnJovfz18M5VkkI2F
>  >>>>>>>>
>  >>>>>>>>             > > EoixpkxsfMnbqwbR0bpHgoS9E$
>  >>>>>>>>
>  >>>>>>>>             >
>  >>>>>>>>
>  >>>>>>>>             > Juniper Business Use Only
>  >>>>>>>>
>  >>>>>>>>            Juniper Business Use Only
>  >>>>>>>>
>  >>>>>>>>
>  >>>>>>>>            Juniper Business Use Only
>  >>>>>>>>
>  >>>>>>>
>  >>>>>>> _______________________________________________
>  >>>>>>> Lsr mailing list
>  >>>>>>> [e-mail]
>  >>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l
>  >>>>>>> s
>  >>>>>>> r
>  >>>>>>> __;!!NEt6yMaO-gk!EX4RtSVg7I0jO4M9ZMrtcjGl2sqxcDIFHFZRnk4pocYHUxv9_p
>  >>>>>>> A
>  >>>>>>> b
>  >>>>>>> 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
>  >>>>>
>  >>>>
>  >>>>
>  >>>> Juniper Business Use Only
>  >>>>
>  >>>
>  >>>
>  >>> Juniper Business Use Only
>  >>>
>  >>
>  >>
>  >> _______________________________________________
>  >> Lsr mailing list
>  >> [e-mail]
>  >> https://www.ietf.org/mailman/listinfo/lsr
>  >>
>  >>
>  >>
>  >>
>  >> _______________________________________________
>  >> Lsr mailing list
>  >> [e-mail]
>  >> https://www.ietf.org/mailman/listinfo/lsr
>  >>
>  >
>  >
>  >
>  >
>  >
> 
>