To me this "permitted" is only about applying ASLA to all apps (no bit mask) except specific apps IDs matching their ID if present in the bit mask. It is not about applying ASLA itself or not applying it at all.
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 so long as there is not another set of attributes advertised on that same link that is associated with a non-zero- length Application Identifier Bit Mask with a matching Application Identifier Bit set. Is there any shipping implementation which reads this the way you interpret it and chooses not to apply it at all ? Thx R. On Fri, Jun 4, 2021 at 4:12 PM <[email protected]> wrote: > > > > > *From:* Robert Raszuk [mailto:[email protected]] > *Sent:* Friday, June 4, 2021 3:35 PM > *To:* DECRAENE Bruno INNOV/NET <[email protected]> > *Cc:* [email protected]; [email protected] > *Subject:* Re: [Lsr] draft-ietf-lsr-flex-algo > > > > > > Ok you meant domain wide not locally ... but there is already strong > normative MUST in Flex Algo as the user of ASLA so no loop will happen. > > > > The "permitted" from ASLA RFC is just to indicate what applications may > use such attribute with zero-length > > Application Identifier Bit Masks as opposed to rest of the sentence > which you did not quote which reads: > > > > ...so long as there is not another set of attributes > > advertised on that same link that is associated with a non-zero- > > length Application Identifier Bit Mask with a matching Application > > Identifier Bit set. > > > > So context of "permitted" is not in the sense use or not use ASLA, but in the > sense when both use zero length or none zero length app id is present. > > > > Agreed that ASLA MUST be used. > > Now ASLA allows two ways to advertise attributes (so both ways _*are*_ ALSA): > > a) inside an ASLA with the X-flag set (attribute specifically for FlexAlgo) > > b) inside an ASLA with all flags cleared (attribute that every application > MAY use, so a priori including FlexAlgo) > > > > My point is that for case “b”, “MAY” does not seem strong enough to ensure > consistency along the SPT. I gave an example in my original email, you may > refer to it. > > A priori we need FlexAlgo to choose and specify whether the second signalling > (“b”) MUST or MUST NOT be used. We just need to write this down. If we all > agree on the choice, that’s easy. If we don’t, that’s harder but even more > necessary for interop. > > > > Alternatively, I’m wrong and that’s even better. > > > > --Bruno > > > > > > Thx > > > > > > On Fri, Jun 4, 2021 at 2:56 PM <[email protected]> wrote: > > Hi Robert, > > > > *From:* Robert Raszuk [mailto:[email protected]] > > > > 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. > > > > No, I’m only discussing a single link direction. > > Different upstream routers would have a different understanding of this > link direction. > > e.g. > > A-B-C > > +---+ > > > > All links have a metric of 10 except A-C with a metric of 100. > > > > > > B->C is the link that we are discussing. Some nodes e.g. “A” see a TE > –metric, some node (e.g. “B”) not see a TE-metric > > For traffic toward C: > > - A is sending to B (A’s path is A-B-C with a metric of 20) > > - B is sending to A (B’s path is B-A-C with a metric of 110) > > à looping between A and B > > > > Cheers, > > Bruno > > > > 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 > > _________________________________________________________________________________________________________________________ > > > > 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. > > _________________________________________________________________________________________________________________________ > > 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
