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]<mailto:[email protected]>> wrote:
Hi Robert,
From: Robert Raszuk [mailto:[email protected]<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]<mailto:[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]<mailto:[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
