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

[Christian Hopps <[e-mail]>]

Louis Chan <[e-mail]> writes:

> Hi Christian,
>
> Three comments on flooding enhancement
>
> - It is discussed in IS-IS domain. How about OSPF?
>         - The proposed offset solution works for both.

If OSPF needs improvement here then that is what we should be working to fix.

> - I believe that the convergence and stability is limited by the weakness node
> in the network, especially in transit node position. The flooding might help the
> high-end node with better control plane, but it might not help the weakest node
> with limited control plane resource.

Operators with 1000s of routers and routers with 1000s of interfaces don't create flooding choke-points, and especially don't then drop crappy routers in said choke-points. We should not modify our routing protocols to support such poor network design.

Thanks,
Chris.

> - The proposed method is not changing the concept on protocol, e.g. using SRGB (especially in different range) plus index is indeed, by nature, similar to offset approach.
>
> Rgds
> louis
>
> -----Original Message-----
> From: Christian Hopps <[e-mail]>
> Sent: Monday, April 17, 2023 8:25 PM
> To: Peter Psenak <ppsenak=[e-mail]>
> Cc: Liyan Gong <[e-mail]>; Louis Chan <[e-mail]>;
> Ketan Talaulikar <[e-mail]>; Krzysztof Szarkowicz
> <[e-mail]>; Robert Raszuk <[e-mail]>; linchangwang
> <[e-mail]>; Acee Lindem <[e-mail]>; 程伟强
> <[e-mail]>; Les Ginsberg(ginsbe <[e-mail]>;
> [e-mail]
> Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for AdvertisingOffsetforFlex-Algorithm
>
> [External Email. Be cautious of content]
>
>
> Peter Psenak <ppsenak=[e-mail]> writes:
>
>> Liyan,
>>
>> On 13/04/2023 06:50, Liyan Gong wrote:
>>> Hi All，
>>> Thanks for your discussion, here are some informations to help understanding
>>> better.
>>> 1. About the application scenario, please refer to the following draft.
>>>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-gong-teas-hierarchical-slice-solution/__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_OdwcvhIqyg8$
>>>
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-gong-teas-hierarchical-slice-solution/__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_OdwcvhIqyg8$
>>
>>> Flex-Algo can be associated with the level-1 network slice which provides
>>> dynamic programming topology.
>>> The number of Flex-Algos is the same as the number of the level-1 network
>>> slices. Maybe it can reach dozens.
>>> 2. About the performance impact, Maybe we can think of it as advertising
>>> massive routes through multi-pair neighbors in IGP domain.
>>> Since the advertising and flooding process occupy a lot of router resources,
>>> Network changes can not be converged in time.
>>> This will result in wrong traffic forwarding. That is why there is limitation
>>> on the number of routes in IGP domain.
>>> According to the anaysis by Changwang in the following email, SIDs take up a
>>> big part.
>>> We think it is better if Flex-Algo can be scaled up by optimizing the SIDs
>>> format without changing the IGP basic mechanism.
>>
>> I find the above claim incorrect and misleading. Network convergence is not the
>> function of the a amount of data advertised per adjacency.
>
> Well if we restrict ourselves to the claim that more data adds to convergence
> time, then that isn't incorrect. It takes longer to flood more data, and the
> data must be flooded for convergence, so transitive property here.. more data
> implies longer convergence time -- unless some other part of convergence is
> decoupled from flooding and takes even longer than flooding takes, but I don't
> think that's the case.
>
> We've been working on improving flooding speed/efficiency for just this reason.
>
> However, the misleading part is maybe true; put differently there's something
> being left out here. The only reason we are flooding large amounts of data is if
> large amounts of data changed, this is not really going to happen very often
> (e.g., when you have a partition repair event, or a new router comes online and
> just happens to have a ton of data to flood for itself).
>
> One could argue that these somewhat uncommon events can (and should) be handled
> just fine by the flooding improvements we are working on. Why invent application
> specific protocol changes when we can address the problem with a generic
> solution that works for all applications?
>
> Thanks,
> Chris.
>
>>
>> thanks,
>> Peter
>>
>>
>>
>>> Best Regards,
>>> Liyan
>>>     ----邮件原文----
>>>     *发件人：*Louis Chan  <louisc=[e-mail]>
>>>     *收件人：*Ketan Talaulikar  <[e-mail]>
>>>     *抄　送:
>>>
>> *Krzysztof Szarkowicz <[e-mail]>,Robert Raszuk
> <[e-mail]>,linchangwang <[e-mail]>,Acee Lindem
> <[e-mail]>,Peter Psenak <[e-mail]>,"
>> 程伟强
>> " <[e-mail]>,"Les Ginsberg(ginsbe" <[e-mail]>,lsr  <[e-mail]>
>>>     *发送时间：*2023-04-13 12:31:12
>>>     *主题：*Re: [Lsr] IETF-
>>>     116 LSR - IGP extensions for Advertising OffsetforFlex-Algorithm
>>>     Hi Ketan,
>>>     Just a short response.
>>>     If you remember ATM days, there are VP shaping/policing and VC
>>>     shaping/policing. It can solve quite complicated QOS problem.
>>>     Here we are not doing the costly ATM again.
>>>     With kind of hierarchical QOS readily available in ASIC today, it
>>>     potentially solves some complex multipoint to multipoint QOS problem.
>>>     But first, it requires labeling the packet, like VCI and VPI.
>>>     I am going to stop here because it would be too much to discuss.
>>>     Rgds
>>>     Louis
>>>     *From:* Ketan Talaulikar <[e-mail]>
>>>     *Sent:* Thursday, April 13, 2023 12:02 PM
>>>     *To:* Louis Chan <[e-mail]>
>>>     *Cc:* Krzysztof Szarkowicz <[e-mail]>; Robert Raszuk
>>>     <[e-mail]>; linchangwang <[e-mail]>; Acee
>>>     Lindem <[e-mail]>; Peter Psenak <[e-mail]>; 程伟
>>>     强 <[e-mail]>; Les Ginsberg (ginsbe
>>>     <[e-mail]>; lsr <[e-mail]>
>>>     *Subject:* Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising
>>>     Offset forFlex-Algorithm
>>>     *[External Email. Be cautious of content]*
>>>     Hi Louis,
>>>     First we need to ascertain if it is necessary before we get things
>>>     flooded into IGPs. Then we can get to the evaluation of whether or
>>>     how "evil" it is.
>>>     The VLAN analogy seems incorrect to me and a debate on that may be
>>>     orthogonal to this topic. I'll wait for the "necessity" to be first
>>>     described before taking a bite at this PIZZA ;-)
>>>     Once again, thanks for your work on this document.
>>>     Thanks,
>>>     Ketan
>>>     On Thu, Apr 13, 2023 at 9:15AM Louis Chan <[e-mail]
>>>     <mailto:[e-mail]>> wrote:
>>>         Hi Ketan,
>>>         First, I like “PIZZA” more than “VFA”, and at least it is closer
>>>         to “real” and tasty instead of “virtual” and boring. :)
>>>         For VFA, it is just a further identification method. History has
>>>         VLAN first introduced in ethernet. People might think it was
>>>         already enough in that period. But later, market asked  for
>>>         stacked vlan, and find its application.
>>>         Having VFA/PIZZA might give more possibilities for future usage.
>>>         It is only ~30B advertisement per VFA per node, and it would not
>>>         be a big harm. And there is no further header overhead  (or cell
>>>         tax) in forwarding plane, and make it easy of vendor interop.
>>>         This is more important.
>>>         I have no intention to swamp IGP with control plane kind of
>>>         info, like QOS profile.  My view is to leave IGP as slim as
>>>         possible for quick reaction to network changes.
>>>         If it is a necessary evil, it should be minimum. My take would
>>>         be getting minimum but useful enough info into FAD. In this
>>>         case, the advertisement size is small, with ease of management.
>>>  That is what I refer to “good to have” info in previous email.
>>>         Rgds
>>>         Louis
>>>         *From:* Ketan Talaulikar <[e-mail]
>>>         <mailto:[e-mail]>>
>>>         *Sent:* Thursday, April 13, 2023 12:06 AM
>>>         *To:* Krzysztof Szarkowicz <[e-mail]
>>>         <mailto:[e-mail]>>
>>>         *Cc:* Robert Raszuk <[e-mail]
>>>         <mailto:[e-mail]>>; linchangwang
>>>         <[e-mail]
>>>         <mailto:[e-mail]>>; Acee Lindem
>>>         <[e-mail] <mailto:[e-mail]>>;  Peter
>>>         Psenak <[e-mail] <mailto:[e-mail]>>; 程伟强
>>>         <[e-mail]
>>>         <mailto:[e-mail]>>; Louis Chan
>>>         <[e-mail] <mailto:[e-mail]>>;  Les Ginsberg
>>>         (ginsbe <[e-mail] <mailto:[e-mail]>>; lsr
>>>         <[e-mail] <mailto:[e-mail]>>
>>>         *Subject:* Re: [Lsr] IETF-116 LSR - IGP extensions for
>>>         Advertising Offset forFlex-Algorithm
>>>         *[External Email. Be cautious of content]*
>>>         Hi Krzysztof,
>>>         I got the impression that the use-case/need for these VFA SIDs
>>>         in the first place was to carry some indication in the packet
>>>         for local treatment at each hop (e.g,, bandwidth profile  or QoS
>>>         treatment?) in the data path since the forwarding is based on
>>>         FlexAlgo.
>>>         If not, then I am not sure that I follow the use-case or
>>>         motivation for VFA (or pizza ;-) as Louis calls it) in the first
>>>         place.
>>>         Thanks,
>>>         Ketan
>>>         On Wed, Apr 12, 2023 at 9:28PM Krzysztof Szarkowicz
>>>         <[e-mail] <mailto:[e-mail]>> wrote:
>>>             Hi Ketan,
>>>             I agree with you. The draft doesn’t propose to carry
>>>             ’service bandwidth profile’ parameters in the IGP.
>>>             The draft is dealing only with label/SID
>>>             assignment/generation and distribution.
>>>             Thanks,
>>>             Krzysztof
>>>                 On 2023 -Apr-12, at 17:49, Ketan Talaulikar
>>>                 <[e-mail] <mailto:[e-mail]>>
>>>                 wrote:
>>>                 *[External Email. Be cautious of content]*
>>>                 Hi Krzysztof,
>>>                 A further question is if it is necessary to carry this
>>>                 "service bandwidth profile" information in the IGPs in
>>>                 the first place. Why not indicate this just in the
>>>                 packet? Wouldn't  that be a better way to help scale
>>>                 IGPs by not introducing this into IGPs in the first
>>>                 place? ;-)
>>>                 One such simple solution is proposed by
>>>
>>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-decraene-mpls-slid-encoded-entropy-label-id/__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_Odwc53EY1fY$
>>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-decraene-mpls-slid-encoded-entropy-label-id/__;!!NEt6yMaO-gk!DxCsNxydz3b_s_iNl0j_6pyHLD1_vLYmeqwZbd_OBYdhfs3BBaQ8bIXbBsB-4Yigax-NkpPUA1EmCDwYmDNrSqU0Lg$>
>>>                 Thanks,
>>>                 Ketan
>>>                 On Wed, Apr 12, 2023 at 9:13PM Krzysztof Szarkowicz
>>>                 <kszarkowicz=[e-mail]
>>>                 <mailto:[e-mail]>> wrote:
>>>                     Hi,
>>>                     It is the question, if we could for example have
>>>                     more than 20 (e.g. 200), for 200 different service
>>>                     bandwidth guarantees (but having only one - or
>>>                     handful - SPF calculation domains,  where one SPF
>>>                     calculation domain is one ‘legacy’ flex-algo ). The
>>>                     challenge is with SPP calculations, once the number
>>>                     of flex-algos goes high.
>>>                     Thanks,
>>>                     Krzysztof
>>>                         On 2023 -Apr-12, at 17:13, Robert Raszuk
>>>                         <[e-mail] <mailto:[e-mail]>>
>>>                         wrote:
>>>                         *[External Email. Be cautious of content]*
>>>                         Ok you can use 20 flex algos today with no
>>>                         extension. Is going to another level of nesting
>>>                         really necessary ?
>>>                         On Wed, Apr 12, 2023 at 4:52PM linchangwang
>>>                         <[e-mail]
>>>                         <mailto:[e-mail]>> wrote:
>>>                             Hi Acee
>>>                             An operator's backbone network is divided
>>>                             into different flex algorithms planes
>>>                             according to different SLA requirements of
>>>                             users.
>>>                             A flex algo represents a service
>>>                             requirement, such as bandwidth requirements.
>>>                             20 flex algorithms represent 20 different
>>>                             service bandwidth guarantees, corresponding
>>>                             to different resource requirements.
>>>                             Thanks,
>>>                             Changwang lin
>>>                             *From:*Acee Lindem
>>>                             [mailto:[e-mail]
>>>                             <mailto:[e-mail]>]
>>>                             *Sent:* Wednesday, April 12, 2023 10:12 PM
>>>                             *To:* Peter Psenak
>>>                             *Cc:* linchangwang (RD); 程伟强; Louis Chan;
>>>                             Les Ginsberg (ginsbe; lsr; Krzysztof Szarkowicz
>>>                             *Subject:* Re: [Lsr] IETF-116 LSR - IGP
>>>                             extensions for Advertising Offset
>>>                             forFlex-Algorithm
>>>                             Hi Weiqiang,
>>>                             I’m also curious as to how you are using 20
>>>                             different flex algorithms. Is this just a
>>>                             hypothetical scenario
>>>                             to illustrate the mathematics or do you have
>>>                             an actual use case?
>>>                             On Apr 12, 2023, at 09:31, Peter Psenak
>>>                             <[e-mail]
>>>                             <mailto:[e-mail]>> wrote:
>>>                             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.
>>>                             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.
>>>                             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.
>>>                             thanks,
>>>                             Peter
>>>                             thanks,
>>>                             Changwang lin
>>>                             -----Original Message-----
>>>                             From: Lsr [mailto:[e-mail]
>>>                             <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-cheng-lsr-isis-srv6-sid-block/__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_OdwcBb9rYg8$
>>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUND7v7my7$>
>>>
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_OdwcBb9rYg8$
>>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUND7v7my7$>>
>>>                             Thanks,
>>>                             Weiqiang Cheng
>>>                                  ----邮件原文----
>>>                                  *发件人：*Louis Chan
>>>                               <louisc=[e-mail]
>>>                             <mailto:[e-mail]>>
>>>                                  *收件
>>>                             人：*"Les Ginsberg (ginsberg)"
>>>                             <[e-mail]
>>>                             <mailto:[e-mail]>>,Acee  Lindem
>>>                             <[e-mail]
>>>                             <mailto:[e-mail]>>
>>>                                  *抄　送:
>>>                                  *lsr  <[e-mail]
>>>                             <mailto:[e-mail]>>,Krzysztof Szarkowicz
>>>                               <[e-mail]
>>>                             <mailto:[e-mail]>>,Weiqiang
>>>                             Cheng  <[e-mail]
>>>                             <mailto:[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] <mailto:[e-mail]>>
>>>                                  *Sent:* Tuesday, April 11, 2023 11:03 PM
>>>                                  *To:* Louis Chan <[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
>>>                                  *[External Email. Be cautious of content]*
>>>                                  Louis -
>>>                                  Please see inline.
>>>                                   > -----Original Message-----
>>>                                   > From: Louis Chan <[e-mail]
>>>                             <mailto:[e-mail]>
>>>                             <mailto:[e-mail]
>>>                             <mailto:[e-mail]>>>
>>>                                   > Sent: Monday, April 10, 2023 11:01 PM
>>>                                   > To: Les Ginsberg (ginsberg)
>>>                             <[e-mail] <mailto:[e-mail]>
>>>                                  <mailto:[e-mail]
>>>                             <mailto:[e-mail]>>>; Acee Lindem
>>>                                   > <[e-mail]
>>>                             <mailto:[e-mail]>
>>>                             <mailto:[e-mail]
>>>                             <mailto:[e-mail]>>>
>>>                                   > Cc: lsr <[e-mail]
>>>                             <mailto:[e-mail]> <mailto:[e-mail]
>>>                             <mailto:[e-mail]>>>; Krzysztof
>>>                                  Szarkowicz <[e-mail]
>>>                             <mailto:[e-mail]>
>>>                             <mailto:[e-mail]
>>>                             <mailto:[e-mail]>>>;
>>>                                   > Weiqiang Cheng
>>>                             <[e-mail]
>>>                             <mailto:[e-mail]>
>>>                                  <mailto:[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]>
>>>                                  <mailto:[e-mail]
>>>                             <mailto:[e-mail]>>>
>>>                                   > Sent: Saturday, April 8, 2023 7:34 AM
>>>                                   > To: Acee Lindem <[e-mail]
>>>                             <mailto:[e-mail]>
>>>                                  <mailto:[e-mail]
>>>                             <mailto:[e-mail]>>>; Louis Chan
>>>                             <[e-mail] <mailto:[e-mail]>
>>>                                  <mailto:[e-mail]
>>>                             <mailto:[e-mail]>>>
>>>                                   > Cc: lsr <[e-mail]
>>>                             <mailto:[e-mail]> <mailto:[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/116/materials/slides-116-lsr-03-ietf116-__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_OdwcUTBr9g0$
>>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/116/materials/slides-116-lsr-03-ietf116-__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNBlx2nlh$>
>>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/116/materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMaO-gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79yewGB-BleOfrYpSjfI$
>>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/116/materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMaO-gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79yewGB-BleOfrYpSjfI$>>
>>>                                  >  igp-adv-offset-01
>>>
>>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/116/materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMaO-gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79yewGB-BleOfrYpSjfI$
>>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/116/materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMaO-gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79yewGB-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!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_OdwcSuumcqQ$
>>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNHGf6W4I$>
>>>
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_OdwcSuumcqQ$
>>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNHGf6W4I$>>
>>   (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
>>>                             <https://urldefense.com/v3/__http:/2.2.2.2/32__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNEj8LL78$>, 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
>>>
>> <https://urldefense.com/v3/__http:/2.2.2.2/32__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNEj8LL78$>
>> 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
>>>
>> <https://urldefense.com/v3/__http:/2.2.2.2/32__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNEj8LL78$>
>> 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
>>>
>> <https://urldefense.com/v3/__http:/2.2.2.2/32__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNEj8LL78$>
>> 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]>
>>>                             <mailto:[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]>
>>>                             <mailto:[e-mail]
>>>                             <mailto:[e-mail]>>>
>>>                                   > > Cc: lsr <[e-mail]
>>>                             <mailto:[e-mail]> <mailto:[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]>
>>>                             <mailto:[e-mail] <mailto:[e-mail]>>
>>>                                   > >
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr_>
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr_
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr_>>
>>>                                   > > _;!!NEt6yMaO-gk!B9ufrV6k-
>>>                                   >
>>>                             c7mtP9JUiXbrF3NCkZ15_UMLBjV_fnJovfz18M5VkkI2F
>>>                                   > > EoixpkxsfMnbqwbR0bpHgoS9E$
>>>                                   >
>>>                                   > Juniper Business Use Only
>>>                                  Juniper Business Use Only
>>>                                  Juniper Business Use Only
>>>                             _______________________________________________
>>>                             Lsr mailing list
>>>                             [e-mail] <mailto:[e-mail]>
>>>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_Odwc0u-ahys$
>>>
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNLUwWHuZ$>
>>>                             -------------------------------------------------------------------------------------------------------------------------------------
>>>                             本邮件及其附件含有新华三集团的保密信息，仅限
>>>                             于发送给上面地址中列出
>>>                             的个人或群组。禁止任何其他人以任何形式使用
>>>                             （包括但不限于全部或部分地泄露、复制、
>>>                             或散发）本邮件中的信息。如果您错收了本邮件，
>>>                             请您立即电话或邮件通知发件人并删除本
>>>                             邮件！
>>>                             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!
>>>                             _______________________________________________
>>>                             Lsr mailing list
>>>                             [e-mail] <mailto:[e-mail]>
>>>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_Odwc0u-ahys$
>>>
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNLUwWHuZ$>
>>>                     _______________________________________________
>>>                     Lsr mailing list
>>>                     [e-mail] <mailto:[e-mail]>
>>>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_Odwc0u-ahys$
>>>
>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!DxCsNxydz3b_s_iNl0j_6pyHLD1_vLYmeqwZbd_OBYdhfs3BBaQ8bIXbBsB-4Yigax-NkpPUA1EmCDwYmDMh734fjw$>
>>>         Juniper Business Use Only
>>>     Juniper Business Use Only
>>>
>>
>> _______________________________________________
>> Lsr mailing list
>> [e-mail]
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_Odwc0u-ahys$
>
>
> Juniper Business Use Only