On 2023 -Apr-12, at 17:13, Robert Raszuk <rob...@raszuk.net
<mailto:rob...@raszuk.net>> 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:52 PM linchangwang
<linchangwang.04...@h3c.com <mailto:linchangwang.04...@h3c.com>> 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:acee.i...@gmail.com
<mailto:acee.i...@gmail.com>]
*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 <ppse...@cisco.com
<mailto:ppse...@cisco.com>> 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:lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>] 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://datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/
<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUND7v7my7$>
<https://datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/
<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=40juniper....@dmarc.ietf.org
<mailto:40juniper....@dmarc.ietf.org>>
*收件
人：*"Les Ginsberg (ginsberg)" <ginsb...@cisco.com
<mailto:ginsb...@cisco.com>>,Acee Lindem <acee.i...@gmail.com
<mailto:acee.i...@gmail.com>>
*抄 送:
*lsr <lsr@ietf.org <mailto:lsr@ietf.org>>,Krzysztof
Szarkowicz <kszarkow...@juniper.net
<mailto:kszarkow...@juniper.net>>,Weiqiang Cheng
<chengweiqi...@chinamobile.com
<mailto:chengweiqi...@chinamobile.com>>
*发送时间：*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) <ginsb...@cisco.com
<mailto:ginsb...@cisco.com>>
*Sent:* Tuesday, April 11, 2023 11:03 PM
*To:* Louis Chan <lou...@juniper.net
<mailto:lou...@juniper.net>>; Acee Lindem <acee.i...@gmail.com
<mailto:acee.i...@gmail.com>>
*Cc:* lsr <lsr@ietf.org <mailto:lsr@ietf.org>>; Krzysztof
Szarkowicz
<kszarkow...@juniper.net <mailto:kszarkow...@juniper.net>>;
Weiqiang Cheng
<chengweiqi...@chinamobile.com
<mailto:chengweiqi...@chinamobile.com>>
*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 <lou...@juniper.net
<mailto:lou...@juniper.net> <mailto:lou...@juniper.net
<mailto:lou...@juniper.net>>>
> Sent: Monday, April 10, 2023 11:01 PM
> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com
<mailto:ginsb...@cisco.com>
<mailto:ginsb...@cisco.com <mailto:ginsb...@cisco.com>>>; Acee
Lindem
> <acee.i...@gmail.com <mailto:acee.i...@gmail.com>
<mailto:acee.i...@gmail.com <mailto:acee.i...@gmail.com>>>
> Cc: lsr <lsr@ietf.org <mailto:lsr@ietf.org>
<mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>; Krzysztof
Szarkowicz <kszarkow...@juniper.net
<mailto:kszarkow...@juniper.net> <mailto:kszarkow...@juniper.net
<mailto:kszarkow...@juniper.net>>>;
> Weiqiang Cheng <chengweiqi...@chinamobile.com
<mailto:chengweiqi...@chinamobile.com>
<mailto:chengweiqi...@chinamobile.com
<mailto:chengweiqi...@chinamobile.com>>>
> 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) <ginsb...@cisco.com
<mailto:ginsb...@cisco.com>
<mailto:ginsb...@cisco.com <mailto:ginsb...@cisco.com>>>
> Sent: Saturday, April 8, 2023 7:34 AM
> To: Acee Lindem <acee.i...@gmail.com
<mailto:acee.i...@gmail.com>
<mailto:acee.i...@gmail.com <mailto:acee.i...@gmail.com>>>;
Louis Chan <lou...@juniper.net <mailto:lou...@juniper.net>
<mailto:lou...@juniper.net <mailto:lou...@juniper.net>>>
> Cc: lsr <lsr@ietf.org <mailto:lsr@ietf.org>
<mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>
> 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://datatracker.ietf.org/meeting/116/materials/slides-116-lsr-03-ietf116-
<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://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/
<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNHGf6W4I$>
<https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/
<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 <lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org> <mailto:lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>>>
On Behalf Of Acee Lindem
> > Sent: Friday, April 7, 2023 11:43 AM
> > To: Louis Chan <lou...@juniper.net
<mailto:lou...@juniper.net> <mailto:lou...@juniper.net
<mailto:lou...@juniper.net>>>
> > Cc: lsr <lsr@ietf.org <mailto:lsr@ietf.org>
<mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>
> > 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
> > Lsr@ietf.org <mailto:Lsr@ietf.org> <mailto:Lsr@ietf.org
<mailto:Lsr@ietf.org>>
> >
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
Lsr@ietf.org <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
<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
Lsr@ietf.org <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNLUwWHuZ$>
