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. Have you discussed this idea with any operators? 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. 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. 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. 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. 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. 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. Les > -----Original Message----- > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Acee Lindem > Sent: Friday, April 7, 2023 11:43 AM > To: Louis Chan <lou...@juniper.net> > Cc: lsr <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 > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
