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.
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.
>
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
