Bruno -

The intent of the RFC 8919 language is to say:

1)If there are ASLA advertisements w non-zero SABM/UABM matching the 
application,  these MUST be used
2)If there are no matching ASLA advertisements as per #1, then ASLA 
advertisements w zero length SABM/UABM (if present) MUST be used

There is no intent of making these rules "optional".

Peter and I are working on revised language that will make this more explicit 
(as well as resolving the unintentional discrepancies between the IS-IS/OSPF 
RFCs that you pointed out in an earlier thread).
Once language is agreed upon, these will be filed as Errata.
But it is important to note that this is a clarification - not a change in 
intended behavior.

Hope this is sufficient to address your concern.
Thanx for helping us to improve the quality of the RFCs.

   Les

From: Lsr <lsr-boun...@ietf.org> On Behalf Of bruno.decra...@orange.com
Sent: Friday, June 4, 2021 2:03 AM
To: draft-ietf-lsr-flex-a...@ietf.org; 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

Reply via email to