Gunter - Thanx for digging into the origins of some of the ambiguity.
I have just sent proposed Errata for RFC 8919/8920 which addresses the issues raised and better aligns the text in the two RFCs. Please review and comment on that new thread. For the record, Option #1 is what is specified - and this is always what was intended. Les From: Lsr <lsr-boun...@ietf.org> On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp) Sent: Tuesday, June 15, 2021 7:45 AM To: bruno.decra...@orange.com; draft-ietf-lsr-flex-a...@ietf.org; lsr@ietf.org Subject: Re: [Lsr] draft-ietf-lsr-flex-algo Thanks for this interesting discussion. May I show a simple example to clarify a confusion, and I hope this helps to clarify implementation behavior: Example: 2 ASLA TLV's are received for 1 link: * ASLA TLV for all applications (SABML AND UDBML = 0) containing TE-Metric 5 and Admin Group 7 * ASLA TLV with Flex-Algo bit set containing TE-Metric 10 What would the implementation have to follow? Option 1: TE-Metric 10 used for Flex-algo, while Admin-Group 7 is not used. I.e. the overruling is done on ASLA TLV basis. Option 2: TE-Metric 10, Admin-Group 7 have to be used for Flex-Algo. I.e. the overruling is done on a per attribute basis. if you read the related ISIS and OSPF RFC's, they seem to contradict (as pointer out by Bruno Decraene): * ISIS seems to expect Option 1 * OSPF seems to expect Option 2 Now, if we look all the way back to a year ago (12 June 2020): https://mailarchive.ietf.org/arch/msg/lsr/TsjdMZmegf1SDO5B-X7y04mkgCM/ Then that conclusion of the DISCUSS seems to indicate Option 2. ****snip**** An application specific advertisement (Application Identifier Bit Mask with a matching Application Identifier Bit set) for an attribute MUST always be preferred over the advertisement of the same attribute with the zero length Application Identifier Bit Masks for both standard applications and user defined applications on the same link. ****End Snip**** This reads as option 2 seems to be the implementation of choice and overruling is done on a per attribute basis. A fine question is what Les specifically means with "matching ASLA advertisements" ? That can easily be read as the expected result is Option 1. Long story short, what is the expected implementation behavior? The DISCUSS indicate behavior as Option 2 (the overruling is done on a per attribute basis.) G/ From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> Sent: Friday, June 4, 2021 11:03 AM To: draft-ietf-lsr-flex-a...@ietf.org<mailto:draft-ietf-lsr-flex-a...@ietf.org>; lsr@ietf.org<mailto: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
