Bruno - The intent of the RFC 8919 language is to say:
1)If there are ASLA advertisements w non-zero SABM/UABM matching the application, these MUST be used 2)If there are no matching ASLA advertisements as per #1, then ASLA advertisements w zero length SABM/UABM (if present) MUST be used There is no intent of making these rules "optional". Peter and I are working on revised language that will make this more explicit (as well as resolving the unintentional discrepancies between the IS-IS/OSPF RFCs that you pointed out in an earlier thread). Once language is agreed upon, these will be filed as Errata. But it is important to note that this is a clarification - not a change in intended behavior. Hope this is sufficient to address your concern. Thanx for helping us to improve the quality of the RFCs. Les From: Lsr <lsr-boun...@ietf.org> On Behalf Of bruno.decra...@orange.com Sent: Friday, June 4, 2021 2:03 AM To: draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org Subject: [Lsr] draft-ietf-lsr-flex-algo Hi all, I think that I may have an issue with the way FlexAlgo [2] uses ASLA [1] FlexAlgo is distributed routing computation so it's required that all routers use exactly the same data to compute the routes/SPF. FlexAlgo is clear that ASLA MUST be used: "Link attribute advertisements that are to be used during Flex- Algorithm calculation MUST use the Application-Specific Link Attribute (ASLA) advertisements defined in [RFC8919<https://datatracker.ietf.org/doc/html/rfc8919>] or [RFC8920<https://datatracker.ietf.org/doc/html/rfc8920>]," However ASLA provides multiple ways to advertise IGP attributes and does not seem precise enough in its specification. "If link attributes are advertised associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications, then any standard application and/or any user-defined application is permitted to use that set of link attributes" My issue is the use of the term "permitted" which 1. is not a normative keyword 2. IMHO translates to MAY hence also MAY NOT. While we need a MUST to ensure a consistent SPF. One example of issue is when FlexAlgo uses a metric different from the IGP (e.g. TE-metric) , and one node advertises this TE-metric in an ASLA with zero-length Bit Mask. - If one node uses this TE-metric (since it is permitted to) it includes that link in its SPF - If another node does not use this TE-metric (since it is not required to) it prunes that link from its SPF I think it's self-evident that we would end up with a permanent routing loop. Ideally, I would probably have preferred ALSA to be specific about the behaviour but ASLA is already published as RFC so it's a bit late So at this point, I think that the burden is on FlexAlgo to specify the precise behaviour as a MUST in section 12. [2] The smallest change from FlexAlgo draft standpoint may be to _require_ the use of the ASLA _with the X-Flag set_ . But I'm fine with whatever interoperable behaviour (well for me, ideally I'd prefer the behaviour already implemented by the implementations that I've deployed ;-) but that would be a selfish requirement). Note that there are existing implementations and this would impact them. That been said, we do need the interop behaviour so if there are already inconsistent behaviours, some implementations will need to be changed (and hence become non interoperable with themselves) Thanks, Regards, --Bruno [1] https://www.rfc-editor.org/rfc/rfc8919.html [2] https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16#section-12 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
