Hi Bruno, > I think it’s self-evident that we would end up with a permanent routing loop.
Is that so ? Wouldn't it just result in unidirectional link for a given app ? Maybe intentional ? It seems that what you described may cause asymmetric routing but not a routing loop. After all packets belonging to an app are consistently using that app's topology in each node. Cheers, R. On Fri, Jun 4, 2021 at 11:03 AM <[email protected]> wrote: > 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 > > a) is not a normative keyword > > b) 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 > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
