Louis -
Please see inline. > -----Original Message----- > From: Louis Chan <lou...@juniper.net> > Sent: Monday, April 10, 2023 11:01 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 your questions. Please see inline [lc] below. > > /Louis > > -----Original Message----- > From: Les Ginsberg (ginsberg) <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>>; Louis Chan > <lou...@juniper.net<mailto:lou...@juniper.net>> > Cc: lsr <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. 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://datatracker.ietf.org/meeting/116/materials/slides-116-lsr-03-ietf116-igp-adv-offset-01> > igp-adv-offset-01<https://datatracker.ietf.org/meeting/116/materials/slides-116-lsr-03-ietf116-igp-adv-offset-01> > > 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. > > 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. > > 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. > > 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>> On Behalf Of > > Acee Lindem > > Sent: Friday, April 7, 2023 11:43 AM > > To: Louis Chan <lou...@juniper.net<mailto:lou...@juniper.net>> > > Cc: lsr <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> > > 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
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
