Louis - Sorry, one more response from me.
Your responses below, especially regarding the use of algorithm specific adj-sids in TI-LFA, I could summarize as saying: "Yes - in a partial deployment scenario - you would not have full functionality e.g., legacy nodes would be unable to determine what the algorithm specific adj-sid is - but that is OK - we can live with partial functionality." What this says to me is that you are not just proposing an alternate encoding - you are also proposing a subset of the existing functionality. This is something which needs to be clearly detailed in the draft. Otherwise, casual readers will think that nothing is lost when the encoding efficiency is used. This isn’t a minor point in my view. Les > -----Original Message----- > From: Louis Chan <lou...@juniper.net> > Sent: Thursday, April 13, 2023 11:21 PM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Acee Lindem > <acee.i...@gmail.com> > Cc: lsr <lsr@ietf.org>; Krzysztof Szarkowicz <kszarkow...@juniper.net>; > Weiqiang Cheng <chengweiqi...@chinamobile.com> > Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for > Flex-Algorithm > > Hi Les, > > Thanks for the questions. Really appreciate that. > Questions are the good way to achieve mutual understanding, and it gives > me a chance to re-think what to do next. > > Please see inline [lc4] > > /louis > > -----Original Message----- > From: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Sent: Thursday, April 13, 2023 10:49 PM > To: Louis Chan <lou...@juniper.net>; Acee Lindem <acee.i...@gmail.com> > Cc: lsr <lsr@ietf.org>; Krzysztof Szarkowicz <kszarkow...@juniper.net>; > Weiqiang Cheng <chengweiqi...@chinamobile.com> > Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for > Flex-Algorithm > > [External Email. Be cautious of content] > > > Louis - > > I think our discussion is wrapping up - thanx for the thoughtful exchange. > I still have limited enthusiasm for the draft - but I understand it better > now. > > As others have mentioned in other emails, the big gap here is describing the > problem to be solved. The draft is too weighted on the protocol extensions > and too light on the need for the extensions. > Please consider this if you intend to put out new versions of the draft. > > A few more directed comments on the mechanics - which I am top posting. > > 1)In regards to adj-sid flags (particularly B and P), it is wrong to think > that only > one adj-sid/algo may be allocated for a given interface. > Implementations can (and do) allocate multiple. The use case is easier to > justify for protected/non-protected than persistent/non-persistent - but I > am aware of implementations that support all of the above in parallel. > I think this argues for the elimination of the flags field in the offset > sub-TLVs. > Just inherit whatever is advertised in algo 0. > > [lc4] Just inherit Algo 0 is default method. It might not entertain all the > combinations and people' wishes, but it is a trade-off. > > For "B" bits, I might consider adding a flag to disable per Flex-Algo, but > this > will apply to all links within that FA. > > I assume that could be other complications or odd cases to fix, but I believe, > as some of us do here, the overall direction is correct. > e.g. "L" bit > > Anyway, thanks for the reminder. > > [lc4] > > > > 2)It is still wrong to say that adj-sid advertisements only impact the node > which advertises them. > Other nodes in the network use the adj-sid advertisements - specifically in > setting up TI-LFAs. So you cannot deploy the new advertisements safely with > only partial deployment. > > [lc4] I have thought about TI-LFA problem since day one. (18 months ago) > > I/We tend to make "fallback" mechanism mandatory, and on by default. > In previous PE-LEFT/PE-RIGHT example, if PE-RIGHT is configured with > VFA600 (FA129 based) finds another node PE-LEFT (old) only support FA129, > - In PE-RIGHT, after calculation of TI-LFA with FA129, VFA600 shares the > result and it is also required to pass through PE-LEFT as hop > - PE-RIGHT will install TI-LFA based on PE-LEFT FA129's prefix-sid/adj-sid, > as > fallback. > > It is a backward compatibility mode which would avoid traffic blackhole. > > It is not perfect, but it solves 2 issues > - transition period before all nodes are upgraded > - misconfiguration which might cause traffic blackhole > > [lc4] > > 3)You seem to make the assumption that the entire range of MPLS labels > (1M) is available for allocation. That is not my experience. Platforms often > have limited support. > So the assumption that you can sparsely assign label ranges in anticipation of > future expansion of scale may not be safe. Maybe the nodes that will need > to support such scale will support the full label range - but I am not sure > that > is a safe assumption. > In any case it is a requirement that ought to be called out. > > [lc4] I understand that. I was asked a similar question due to multiple > vendors > co-existence in the same network. It requires us to agree on the same SRGB > range. > > But here we are handling industry standard. We should not address specific > vendor and specific chipset limitation, unless it is a well known problem > across industry. > > For 20 FA and 300 links, the size of Adj-sid block is only 6k. > Rather, I have more worries on the FIB capacity on chipsets, when the > network is huge. > > [/lc4] > > Thanx again for the useful discussion. > > [lc4] Same. Thanks for you input. [/lc4] > > Les > > > -----Original Message----- > > From: Louis Chan <lou...@juniper.net> > > Sent: Wednesday, April 12, 2023 8:45 PM > > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Acee Lindem > > <acee.i...@gmail.com> > > Cc: lsr <lsr@ietf.org>; Krzysztof Szarkowicz > > <kszarkow...@juniper.net>; Weiqiang Cheng > > <chengweiqi...@chinamobile.com> > > Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising > > Offset for Flex-Algorithm > > > > Hi Les, > > > > Thanks. Please see inline [lc3] > > > > /Louis > > > > From: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > > Sent: Wednesday, April 12, 2023 11:49 PM > > To: Louis Chan <lou...@juniper.net>; Acee Lindem <acee.i...@gmail.com> > > Cc: lsr <lsr@ietf.org>; Krzysztof Szarkowicz > > <kszarkow...@juniper.net>; Weiqiang Cheng > > <chengweiqi...@chinamobile.com> > > Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising > > Offset for Flex-Algorithm > > > > [External Email. Be cautious of content] > > > > Louis – > > > > I am having increasing difficulty in correlating what you say in this > > thread and what is actually written in the draft. > > > > Please see responses inline. Look for LES2: > > > > From: Louis Chan <mailto:lou...@juniper.net> > > Sent: Tuesday, April 11, 2023 7:46 PM > > To: Les Ginsberg (ginsberg) <mailto:ginsb...@cisco.com>; Acee Lindem > > <mailto:acee.i...@gmail.com> > > Cc: lsr <mailto:lsr@ietf.org>; Krzysztof Szarkowicz > > <mailto:kszarkow...@juniper.net>; Weiqiang Cheng > > <mailto:chengweiqi...@chinamobile.com> > > Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising > > Offset for Flex-Algorithm > > > > Hi Les, > > > > Thanks for the prompt reply. Please see inline for clarification [lc2]. > > > > /Louis > > > > From: Les Ginsberg (ginsberg) <mailto:ginsb...@cisco.com> > > Sent: Tuesday, April 11, 2023 11:03 PM > > To: Louis Chan <mailto:lou...@juniper.net>; Acee Lindem > > <mailto:acee.i...@gmail.com> > > Cc: lsr <mailto:lsr@ietf.org>; Krzysztof Szarkowicz > > <mailto:kszarkow...@juniper.net>; Weiqiang Cheng > > <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 <mailto:lou...@juniper.net> > > > Sent: Monday, April 10, 2023 11:01 PM > > > To: Les Ginsberg (ginsberg) <mailto:ginsb...@cisco.com>; Acee Lindem > > > <mailto:acee.i...@gmail.com> > > > Cc: lsr <mailto:lsr@ietf.org>; Krzysztof Szarkowicz > > <mailto:kszarkow...@juniper.net>; > > > Weiqiang Cheng <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) <mailto:ginsb...@cisco.com> > > > Sent: Saturday, April 8, 2023 7:34 AM > > > To: Acee Lindem <mailto:acee.i...@gmail.com>; Louis Chan > > <mailto:lou...@juniper.net> > > > Cc: lsr <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] > > [LES2:] Section 4 of the draft defines three new sub-TLVs for > > advertising offset. > > One for adj-sid. > > One for LAN adj-sid > > One for prefix sid. > > > > They all have the following fields/description: > > > > Algorithm: 1 octet > > Flex-Algo value is between 128 and 255 > > > > Virtual Flex-Algorithm 4 octets > > Value 0 means that it is not VFA > > Value >=256 means VFA identification number, > > and the base > > topology is denoted by Algorithm > > Value 128 to 255 are invalid > > > > Yet, you say here that the new prefix-SID sub-TLV is not meant to be > > used for flex-algo – only your new construct VFA. > > > > How would I draw that conclusion from the text in the draft??? > > > > [lc3] Sorry for the confusion. There was an application draft about > > how to use it but I did not file. > > At least, we should know we would not advertise both Adj-sid for p2p > > and lan at the same time. Same theory could be applied. > > > > I will add a matrix to highlight what is required and allowed for each > > combination in later draft. This is needed. Thanks for pointing this out. > > > > In my presentation (including previous IETF session), the example in > > slide 5 and slide 8, I did mention only Adj-sid offset is used in FA129. > > And I explicitly mentioned when I present slide 8. In slide 8, under > > FA129 that column, "Prefix-sid offset" is "n/a" in the table. > > > > I did cover that but it is not written down in the RFC draft. > > > > [/lc3] > > > > > > But, let’s look at adj-sid since the same issues arise – though they > > are a bit more complicated in the adj-sid case (which is why I started with > prefix-sid). > > > > Adj-sids have a number of attributes – one of which is “persistence” > > (the P- flag in https://urldefense.com/v3/__https://www.rfc- > > editor.org/rfc/rfc8667.html*section-2.2.1__;Iw!!NEt6yMaO- > > gk!GlFj6K0dHk5eY_w5w- > > _JUwkiBncXobmIxyLDFAj0uveWKGNU0KM0OHPHbs4amQ- > > H3jFg8oQZtFEW1GI$ – which you do not model in your draft). > > > > Persistent adj-sids are meant to have the same value across node > > reboots – and are therefore assigned in a manner similar to > > prefix-sids. Typically they would be allocated from the SRLB on the > advertising node. > > In which case the same set of issues I discussed in the context of > > prefix-sids applies. > > > > For non-persistent adj-sids, these could take on different values when > > a node is rebooted – or even when an interface flaps. > > Typically, they would be allocated from an unreserved pool of labels. > > With your proposal, for each interface, whenever an adj-sid is > > assigned, additional adj-sids have to be reserved for each supported flex- > algo. > > > > [lc3] I did look at the persistent flag. The reason why I did not > > include persistent flag because the per flex-algo Adj-sid will inherit > > the property from Algo 0. > > > > If P flag is set for a certain link in Algo 0, the Adj-sid offset will > > make the rest of per flex-algo adj-sid persistent too. E.g. > > If label 32 is persistent for link#1, 2032, 3032....will be persistent too. > > > > For other flags, I would like to remove it as much as possible from the > > draft. > > > > [/lc3] > > > > To use a simple example, consider that we support only one flex algo > > (128) and the offset for this algo is 1000. > > > > Interface 1: Base label: 1000 Flex label 2000 Interface 2: Base label: > > 1001 Flex label 2001 Etc. > > > > If I initially have 500 interfaces in use by IS-IS, I have now > > assigned/reserved labels 1000-1499 and 2000-2499. > > > > If I subsequently enable 100 additional interfaces for IS-IS, I would > > need to obtain additional pairs of labels, but as I am allocating > > these labels out of a space reserved for dynamic allocations, it isn’t > > guaranteed that Label N and Label N+1000 are both available. > > And since non-persistent adj-sids can be assigned/deassigned > > dynamically, over time the unreserved pool of labels may get > > increasingly fragmented, making it more difficult to obtain the necessary > pair of labels needed. > > > > Add to this the difficulties of introducing support for an additional > > flex-algo on the fly and the need to support both “protected” and > > “unprotected” adj- sids (the B-flag) and I think implementations would > > find it quite challenging to guarantee they can always obtain the set > > of labels required by offset advertisement. > > > > Also you require implementations to support atomic allocations of a > > group of labels – something which I would not assume is easily supported. > > > > > > [lc3] For every installation, one can estimate how many interfaces is > > planned in a box. The same is applied to SRGB planning, which an > > operator has a good guess on total number of boxes in the network. > > > > As I said in the live presentation, one can provision it with high end > > number, like 100FA x 1000 links scale. And that consumes only 100k > > label space in local > > - 10% of 1M. This is a simple solution. > > > > Or, due to mistake, it runs out of label from the adj-sid block. Just > > allocate a bigger consecutive block, and restart the process within > > this node. THIS OPERATION is local to one node. It would not affect > globally. > > In SRGB case, allocating a new block or changing the block size would > > be a big trouble, and it affects globally. > > > > (I hope someone would not say 100 FA or 1000 links now is not enough > > compared to too many as before.) > > > > [/lc3] > > > > Les > > > > > > 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/ma > > te > > rials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMaO- > > gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5- > > 80micuqnqk79yewGB-BleOfrYpSjfI$ > > https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/116/ma > > te > > rials/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!GlFj6K0dHk5eY_w5w- > > _JUwkiBncXobmIxyLDFAj0uveWKGNU0KM0OHPHbs4amQ- > > H3jFg8oQZJchZwEc$ (which you participated in) > > >>> > > As IS-IS is deployed in greater scale both in the number of nodes in > > an area and in the number of neighbors per node, the impact of the > > historic flooding rates becomes more significant. Consider the > > bringup or failure of a node with 1000 neighbors. This will result > > in a minimum of 1000 LSP updates. At typical LSP flooding rates used > > today (33 LSPs/second), it would take 30+ seconds simply to send the > > updated LSPs to a given neighbor. Depending on the diameter of the > > network, achieving a consistent LSDB on all nodes in the network > > could easily take a minute or more. > > <<< > > > > This proposed draft will certainly help. > > > > [/lc2] > > > > > > > > > > So, this is why I do not understand your question in full. > > > > > > If the operator plans to use VFA, that would be a different > > > discussion. VFA, today, does not exist in deployment. > > > > > [LES:] My comments here have nothing to do with VFA. > > > > > [/lc] > > > > > > Have you discussed this idea with any operators? > > > > > > [lc] I include Wei-qiang from China mobile in this thread. He has > > > shown his need on this kind of solution. Maybe, he could give his > perspective here. > > [/lc] > > > > > > If so, what has been their response? > > > If they are open to the idea, how might they migrate from their > > > existing assignment schemes to an assignment scheme compatible with > > > the proposal? > > > > > > These are questions that need to be answered before considering this > > idea. > > > > > > [lc] In slide 8, if you see these label numbers > > > > > > Prefix-sid: 400001, 402001, 406001, 407001 > > > Adj-sid: 32, 2032, 6032, 7032 > > > > > > From operator perspective or troubleshooting perspective, value > > > xxx001 represent the same node, and value x032 represent the same > > > link. This makes things more organized and easier to understand. > > > > > > If all are random labels, I do not see any benefit at all. > > > [/lc] > > > > [LES:] I am not commenting on whether the label assignment scheme you > > propose is better or worse than any other. > > I am only pointing out that you are imposing new restrictions on how > > labels are allocated. > > As you are not in charge of how operators provision their networks > > (nor am I), it is presumptuous of you to think that simply because you > > think this is a better way to do things that operators will be happy > > to modify their existing networks to conform to your proposed restrictions. > > This isn’t academia - you need to vet this with the operator community. > > > > [lc2] Please refer to the examples at the top. The picture should be > > clear by now. There is no restriction to what is deployed today. > > [/lc2] > > > > > > > > 2)Section 5 Compatibilty > > > > > > There is no "compatibility" with legacy nodes - because all nodes in > > > the network have to have a consistent understanding of what SID is > > > assigned to > > a > > > given context (for prefixes and adjacencies) since they might need > > > to install forwarding entries for that context. > > > I do not see any point in deploying this until all nodes support it. > > > If you did > > do > > > so, you would need to advertise old and new forms - which does the > > > opposite of what you are trying to achieve. Instead of reducing LSP > > > space used you would increase it. > > > > > > [lc] If the operator just plans to use only Flex-Algo, and no VFA, > > > it should be compatible with legacy implementation. If legacy nodes > > > do not understand adj-sid offset notation, these nodes could just > > > ignore it. The forwarding plane should work with co-existence of old > > > and new nodes. Per flex-algo > > adj- > > > sid is only local significant to one node. New nodes should detect > > > whether legacy nodes exist in the network via such new extension > advertisement. > > > And new nodes should use only algo 0 adj-sid from legacy nodes for > > > any TI- LFA. > > > > [LES:] Consider a network of 100 nodes. > > Let's say the "left-hand-side" of the network consist of legacy nodes > > who do not understand your new advertisements. > > The "right-hand-side" of the network consists of upgraded nodes who > > support the new advertisements. > > > > Consider nodes PE-LEFT and PE-RIGHT. > > > > PE-RIGHT advertises a prefix-SID of 1000 for 2.2.2.2/32, and an offset > > of 1000 for flex-algo 128. > > > > PE-LEFT supports flex-algo 128 and wants to install a forwarding entry > > for > > 2.2.2.2 for flex-algo 128. > > It looks in the LSPs originated by PE-RIGHT. It does not see any > > assigned SID for 2.2.2.2/32 flex-algo 128. > > It cannot create a forwarding entry. And neither can any other node in > > the left hand side of the network. > > > > When PE-RIGHT stops advertising the explicit prefix SID for 2.2.2.2/32 > > Algo 128, all legacy nodes are unable to create forwarding entries for > > the prefix/algo tuple. > > > > This isn’t backwards compatible. 😊 > > > > In general, you cannot advertise information legacy nodes require in a > > new container that legacy nodes do not understand and claim that you > > are backwards compatible. > > > > [lc2] Please refers to the examples for clarification. > > > > 1. For existing Flex-Algo deployment, it would be compatible. There is > > no change in the container format on how prefix-sid 2.2.2.2/32 in > > FA128 is advertised. > > > > 2. 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 <mailto:lsr-boun...@ietf.org> On Behalf Of Acee Lindem > > > > Sent: Friday, April 7, 2023 11:43 AM > > > > To: Louis Chan <mailto:lou...@juniper.net> > > > > Cc: lsr <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 > > > > mailto:Lsr@ietf.org > > > > https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/l > > > > sr_ > > > > _;!!NEt6yMaO-gk!B9ufrV6k- > > > c7mtP9JUiXbrF3NCkZ15_UMLBjV_fnJovfz18M5VkkI2F > > > > EoixpkxsfMnbqwbR0bpHgoS9E$ > > > > > > Juniper Business Use Only > > > > Juniper Business Use Only > > > > Juniper Business Use Only > > > > Juniper Business Use Only > > > > Juniper Business Use Only > > Juniper Business Use Only > > Juniper Business Use Only _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
