- 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 <[email protected]>
Sent: Monday, April 17, 2023 8:25 PM
To: Peter Psenak <[email protected]>
Cc: Liyan Gong <[email protected]>; Louis Chan <[email protected]>;
Ketan Talaulikar <[email protected]>; Krzysztof Szarkowicz
<[email protected]>; Robert Raszuk <[email protected]>; linchangwang
<[email protected]>; Acee Lindem <[email protected]>; 程伟强
<[email protected]>; Les Ginsberg(ginsbe <[email protected]>;
[email protected]
Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for
AdvertisingOffsetforFlex-Algorithm
[External Email. Be cautious of content]
Peter Psenak <[email protected]> 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 <[email protected]>
*收件人：*Ketan Talaulikar <[email protected]>
*抄 送:
*Krzysztof Szarkowicz <[email protected]>,Robert Raszuk
<[email protected]>,linchangwang <[email protected]>,Acee Lindem
<[email protected]>,Peter Psenak <[email protected]>,"
程伟强
" <[email protected]>,"Les Ginsberg(ginsbe" <[email protected]>,lsr
<[email protected]>
*发送时间：*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 <[email protected]>
*Sent:* Thursday, April 13, 2023 12:02 PM
*To:* Louis Chan <[email protected]>
*Cc:* Krzysztof Szarkowicz <[email protected]>; Robert Raszuk
<[email protected]>; linchangwang <[email protected]>; Acee
Lindem <[email protected]>; Peter Psenak <[email protected]>; 程伟
强 <[email protected]>; Les Ginsberg (ginsbe
<[email protected]>; lsr <[email protected]>
*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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>>
*Sent:* Thursday, April 13, 2023 12:06 AM
*To:* Krzysztof Szarkowicz <[email protected]
<mailto:[email protected]>>
*Cc:* Robert Raszuk <[email protected]
<mailto:[email protected]>>; linchangwang
<[email protected]
<mailto:[email protected]>>; Acee Lindem
<[email protected] <mailto:[email protected]>>; Peter
Psenak <[email protected] <mailto:[email protected]>>; 程伟强
<[email protected]
<mailto:[email protected]>>; Louis Chan
<[email protected] <mailto:[email protected]>>; Les Ginsberg
(ginsbe <[email protected] <mailto:[email protected]>>; lsr
<[email protected] <mailto:[email protected]>>
*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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>>
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
<[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>>
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
<[email protected]
<mailto:[email protected]>> 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:[email protected]
<mailto:[email protected]>]
*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
<[email protected]
<mailto:[email protected]>> 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:[email protected]
<mailto:[email protected]>] On Behalf Of
Peter Psenak
Sent: Wednesday, April 12, 2023 7:10 PM
To: 程伟强; Louis Chan; Les Ginsberg
(ginsbe; Acee Lindem
Cc: lsr; Krzysztof Szarkowicz
Subject: Re: [Lsr] IETF-116 LSR - IGP
extensions for Advertising Offset
forFlex-Algorithm
Weiqiang,
please see inline (##PP):
On 12/04/2023 12:05, 程伟强wrote:
Hi Louis and Les,
My two cents from operator perspective.
We've met the same problem when applying
Flex Algo in SRv6 network.
what problem exactly, can you please
describe it?
[changwang lin]
Advertisement size of per Flex-Algo Adj-SID
in the network
Related to F(# of node, # of FA, # of links)
For a node with 1,000 links and 20 Flex-Algo
n x 20 x 1000
MPLS-SR：If n = 10 bytes, it is 200K bytes
SRv6： If n = 24 bytes, it is 400K+ bytes
If 500 nodes:
MPLS-SR：it is 200K*500 = 100000k bytes
SRv6： it is 400K+ * 500 = 200000k bytes
If interface mtu=1500, lsp length = 1497
LSP num:
MPLS-SR：10000k bytes/1497 = 66800 lsps
SRv6： 20000k bytes/1497 = 160320 lsps
The number of LSPs is too large, and IS-IS
needs to periodically refresh LSPs,
resulting in a decrease in ISIS performance
and unstable network operation.
So we need to optimize on the control
surface to save LSP space.
Through the optimization notification
mechanism mentioned in these two documents,
we have greatly saved LSP space for IS-IS
and improved the performance of IS-IS flex
algo in large-scale networking.
At the same time, through the VFA mechanism,
in other non flex algo application scenarios,
such as network slicing scenarios, the LSP
space of IS-IS can also be saved
As the number of slices and the scale of the
network increases, the
convergence issue which is caused by SIDs
advertising and flooding
becomes more and more serious.
Due to the problem, it is impossible to
apply Flex-Algo in the large
network, such as the network with more than
1000 routers.
flex-algo has been successfully deployed in
a networks that have more
that 1k nodes.
Maybe you want deploy the flex-algo for
something that it was not
designed for.
I believe Louis'draft provides a good idea
to resolve this problem.
Similar solution for SRv6 SIDs is described
in another draft.
Again, what problem exactly?
From what I see the drafts tries to pack
algo SIDs to save space in
LSP. I don't see how it helps to to deploy
flex-algo in a large scale
network.
thanks,
Peter
About the SIDs assignment, I think it is
better to have a scheduled
assignment than a random assignment as Les
mentioned.
[1]
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-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
<[email protected]
<mailto:[email protected]>>
*收件
人：*"Les Ginsberg (ginsberg)"
<[email protected]
<mailto:[email protected]>>,Acee Lindem
<[email protected]
<mailto:[email protected]>>
*抄 送:
*lsr <[email protected]
<mailto:[email protected]>>,Krzysztof Szarkowicz
<[email protected]
<mailto:[email protected]>>,Weiqiang
Cheng <[email protected]
<mailto:[email protected]>>
*发送时间：*2023-04-12 10:45:56
*主题：*Re: [Lsr] IETF-
116 LSR - IGP extensions for
Advertising Offset forFlex-Algorithm
Hi Les,
Thanks for the prompt reply. Please see
inline for clarification [lc2].
/Louis
*From:* Les Ginsberg (ginsberg)
<[email protected] <mailto:[email protected]>>
*Sent:* Tuesday, April 11, 2023 11:03 PM
*To:* Louis Chan <[email protected]
<mailto:[email protected]>>; Acee Lindem
<[email protected]
<mailto:[email protected]>>
*Cc:* lsr <[email protected]
<mailto:[email protected]>>; Krzysztof Szarkowicz
<[email protected]
<mailto:[email protected]>>; Weiqiang
Cheng
<[email protected]
<mailto:[email protected]>>
*Subject:* RE: [Lsr] IETF-116 LSR - IGP
extensions for Advertising
Offset for Flex-Algorithm
*[External Email. Be cautious of content]*
Louis -
Please see inline.
> -----Original Message-----
> From: Louis Chan <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
> Sent: Monday, April 10, 2023 11:01 PM
> To: Les Ginsberg (ginsberg)
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>; Acee Lindem
> <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
> Cc: lsr <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>; Krzysztof
Szarkowicz <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>;
> Weiqiang Cheng
<[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
> Subject: RE: [Lsr] IETF-116 LSR -
IGP extensions for Advertising
Offset for
> Flex-Algorithm
>
> Hi Les,
>
> Thanks for your questions. Please
see inline [lc] below.
>
> /Louis
>
> -----Original Message-----
> From: Les Ginsberg (ginsberg)
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
> Sent: Saturday, April 8, 2023 7:34 AM
> To: Acee Lindem <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>; Louis Chan
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
> Cc: lsr <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
> Subject: RE: [Lsr] IETF-116 LSR -
IGP extensions for Advertising
Offset for
> Flex-Algorithm
>
> [External Email. Be cautious of content]
>
>
> OK - since Acee opened the door -
here are some comments from me -
> starting with the most important.
>
> (BTW - I still have limited
enthusiasm for this draft.)
>
> 1)The proposal places some
restrictions on how operators
provision their
> network in terms of assigning SIDs
and reserving space for future
> assignments.
> If operators do not use compatible
assignment schemes, then this
will never
> get deployed. It is therefore not
enough to come with a nice idea
- you must
> have some enthusiasm from the
operator community.
>
>
> [lc] If the operator only wants to
deploy flex-algo, there is no
change in their
> Node-sid numbering scheme. For the
Adj-sid, these are local
labels with local
> significant only, and there is no
need for any special planning
for Adj-sid,
> unless you are suggesting they want
to make fixed assignment of
Adj-sid
> label for each link. Even with
fixed, the proposed draft has
benefit on that. I
> will explain later.
>
[LES:] Let's discuss this in the
context of prefix-sids - the same
applies to adj-sids.
Today (i.e., in the absence of your
proposal) an operator is free to
assign any label within the SRGB for a
given prefix/algo pair so
long as it is not assigned to some
other prefix/algo context.
Your proposal places some new
restrictions. Now, for a given
flex-algo, whenever an operator assigns
a given label for a prefix
in Algo 0 (call it Label-A0), they must
guarantee that
"Label-A0+offset" for an advertised
flex-algo specific offset is
available to be assigned for the
prefix/flex-algo pair - and this
must be true for all prefixes
advertised in algo 0.
This is certainly possible to do, but
is not guaranteed to be the
case in current deployments.
For example - and this is only an
example...today an operator might
utilize a provisioning tool to assign
prefix-sids for all supported
algorithms on all nodes in the network.
To do this, the tool might maintain a
database of assigned labels.
When provisioning a new
node/prefix/algorithm, the logic in the tool
might simply take the next available
label in the database.
The result of this would not be
consistent with the requirements of
your draft.
Which is why I say in order to deploy
the extension you propose,
such an operator would have to modify
its provisioning tool.
[lc2] There might be some
misunderstanding of our proposal. Let me
give some examples.
Case 1: Flex-Algo only
Prefix offset advertisement: “no”
Adj-sid offset advertisement: yes
In slide 8’s example, FA129 is using
label “402001”, and the
advertisement of this label is using
existing methods.
e.g. SRGB = 400000-460000
FA129: index 2001 (preferred value), or
one can choose 111, 222
FA130 (new): index 3001 (preferred
value), or 333, 4444
This does not change how the operator
to assign label for prefix-sid
with their current method. Any
index/label could be used for FA
prefix within SRGB.
The only change is the Adj-sid label
allocation, but this “mostly”
is only “local” to one node. There is
no effect on global label
allocation.
This draft will be compatible to what
operators are doing today.
Case 2: VFA only
Prefix offset advertisement: yes
Adj-sid offset advertisement: yes
I agree, with VFA, there would be
impact to global allocation to
node-sid/prefix-sid. But VFA is a
totally new concept. No one has
deployed that yet.
There is no impact to operators which
stick to deploy only Flex-algo.
Other case: Flex-Algo w/o Adj-sid offset
Continue the example of
Case#1 above
Another FA131 is added,
but no Adj-sid offset is
advertised
The question would be
*
Either allow this configuration,
and FA131 will fallback using
Algo 0’s adj-sid
*
Or, disallow this configuration
I tend to “allow” such configuration
with mix of FA129, FA130 (with
adj-sid offset) and FA131 (w/o adj-sid
offset)
[/lc2]
Could this be done? Sure.
Do operators want to do this? I do not
know.
But since this would be necessary in
order to use your proposed
extension, it is necessary to gauge
operator enthusiasm for making
such changes in order to know whether
there is any point in
proceeding with your proposal.
> In slide 8 of the below presentation
>
https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/116/materials/slides-116-lsr-03-ietf116-__;!!NEt6yMaO-gk!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 <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
On Behalf Of Acee Lindem
> > Sent: Friday, April 7, 2023 11:43 AM
> > To: Louis Chan <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
> > Cc: lsr <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
> > Subject: Re: [Lsr] IETF-116 LSR -
IGP extensions for Advertising
> > Offset for Flex-Algorithm
> >
> > Hi Louis,
> >
> > In the interest of initiating
discussion, I would like to
propose the
> > term "Flex Algorithm Traffic Class
(FATC)" for the sub-division of
> > flex-algorithm traffic referred to
in the draft as “Virtual
Flex Algorithm”.
> >
> > Also, in your terminology, you
refer referred to TLVs and
fields with
> > simply “Algorithm” when RFC 9350
uses “Flex Algorithm”.
> >
> > Thanks,
> > Acee
> >
> >
> >
> >
_______________________________________________
> > Lsr mailing list
> > [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> >
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
[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
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
[email protected]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_Odwc0u-ahys$
Juniper Business Use Only
