Hi Les, Thanks for your questions. Please see inline [lc] below.
/Louis -----Original Message----- From: Les Ginsberg (ginsberg) <[email protected]> Sent: Saturday, April 8, 2023 7:34 AM To: Acee Lindem <[email protected]>; Louis Chan <[email protected]> Cc: lsr <[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. In slide 8 of the below presentation 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. 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. [/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] 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. 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. [/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. [/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]> On Behalf Of Acee Lindem > Sent: Friday, April 7, 2023 11:43 AM > To: Louis Chan <[email protected]> > Cc: lsr <[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] > 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
