Subject: [Lsr] draft-ietf-lsr-flex-algo

From: <[email-masked]>
Date: Fri, 4 Jun 2021 09:02:48 +0000

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.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 4 Jun 2021 14:44:36 +0200

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-masked]> wrote:

> FlexAlgo is distributed routing computation so it’s required that all
> routers use exactly the same data to compute the routes/SPF.
>
>
>
> “Link attribute advertisements that are to be used during Flex-
>
>    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
>
> 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.
>
> 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
>
>
>
>
>
> [2]
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-16#section-12
>
>
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: <[email-masked]>
Date: Fri, 4 Jun 2021 12:56:19 +0000

Hi Robert,

From: Robert Raszuk [mailto:[email-masked]]

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-masked]<mailto:[email-masked]>> wrote:
Hi all,

FlexAlgo is distributed routing computation so it’s required that all routers use exactly the same data to compute the routes/SPF.

   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”

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).

Thanks,
Regards,
--Bruno

Thank you.
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 4 Jun 2021 15:34:48 +0200

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-masked]> wrote:

> Hi Robert,
>
>
>
> *From:* Robert Raszuk [mailto:[email-masked]]
>
>
>
> Hi Bruno,
>
>
>
> 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:
>

---

From: <[email-masked]>
Date: Fri, 4 Jun 2021 14:12:16 +0000

From: Robert Raszuk [mailto:[email-masked]]
Sent: Friday, June 4, 2021 3:35 PM
To: DECRAENE Bruno INNOV/NET <[email-masked]>
Cc: [email-masked]; [email-masked]
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:

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

From: Robert Raszuk [mailto:[email-masked]<mailto:[email-masked]>]

Hi Bruno,

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.

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 4 Jun 2021 16:50:15 +0200

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-masked]> wrote:

> *Sent:* Friday, June 4, 2021 3:35 PM
> *To:* DECRAENE Bruno INNOV/NET <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [Lsr] draft-ietf-lsr-flex-algo
>
>
>
>
>
> Now ASLA allows two ways to advertise attributes (so both ways _*are*_ ALSA):
>

---

From: <[email-masked]>
Date: Fri, 4 Jun 2021 16:57:35 +0000

Sent: Friday, June 4, 2021 4:50 PM

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.

[BD] I think that I agree but I don’t see how this relates to my comment.
Let’s come back to my example:
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.
The question is: does FlexAlgo use this TE-metric (and hence the link)? Or not.
Is this already specified as a MUST or does extra text needs to be written?

   Identifier Bit set.

Is there any shipping implementation which reads this the way you interpret it and chooses not to apply it at all ?

[BD] I’ll refrain from speaking about implementations.

I’m not sure how much implementations have to do with a comment/question on the specification. The reference is the specification. Again, if this is so obvious that everyone agree on the behaviour, let’s write down the result in the spec or point me to an existing text in the spec.

Thanks,

Bruno

Thx

R.

On Fri, Jun 4, 2021 at 4:12 PM <[email-masked]<mailto:[email-masked]>> wrote:

From: Robert Raszuk [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, June 4, 2021 3:35 PM
To: DECRAENE Bruno INNOV/NET <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo

   Identifier Bit set.

--Bruno

Thx

Hi Bruno,

Cheers,
Bruno

Cheers,
R.

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 4 Jun 2021 17:15:49 +0000

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 <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, June 4, 2021 2:03 AM
To: [email-masked]; [email-masked]
Subject: [Lsr] draft-ietf-lsr-flex-algo

Hi all,

  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.

Thanks,
Regards,
--Bruno

Thank you.

---

From: <[email-masked]>
Date: Mon, 7 Jun 2021 08:07:00 +0000

Les, Peter,

Thanks for the clarification. This is crystal clear.
This address my concern. My goal is specification clarity to avoid interop issues at the earliest stage, because the latter the misalignment is found the bigger the delay and the cost, both for vendors and network operators.

Thank you for working on a revised language and for the errata.

--Bruno
From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, June 4, 2021 7:16 PM
To: DECRAENE Bruno INNOV/NET <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: draft-ietf-lsr-flex-algo

Bruno -

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, June 4, 2021 2:03 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Lsr] draft-ietf-lsr-flex-algo

Hi all,

Thanks,
Regards,
--Bruno

Thank you.

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 15 Jun 2021 14:44:59 +0000

Thanks for this interesting discussion. May I show a simple example to clarify a confusion, and I hope this helps to clarify implementation behavior:

Example: 2 ASLA TLV's are received for 1 link:

  *   ASLA TLV for all applications (SABML AND UDBML = 0) containing TE-Metric 5 and Admin Group 7
  *   ASLA TLV with Flex-Algo bit set containing TE-Metric 10

What would the implementation have to follow?
Option 1: TE-Metric 10 used for Flex-algo, while Admin-Group 7 is not used. I.e. the overruling is done on ASLA TLV basis.
Option 2: TE-Metric 10, Admin-Group 7 have to be used for Flex-Algo. I.e. the overruling is done on a per attribute basis.

if you read the related ISIS and OSPF RFC's, they seem to contradict (as pointer out by Bruno Decraene):

  *   ISIS seems to expect Option 1
  *   OSPF seems to expect Option 2

Now, if we look all the way back to a year ago (12 June 2020):
https://mailarchive.ietf.org/arch/msg/lsr/TsjdMZmegf1SDO5B-X7y04mkgCM/
Then that conclusion of the DISCUSS seems to indicate Option 2.

****snip****
    An application specific advertisement (Application Identifier Bit
    Mask with a matching Application Identifier Bit set) for an attribute
    MUST always be preferred over the advertisement of the same attribute
    with the zero length Application Identifier Bit Masks for both
    standard applications and user defined applications on the same link.
****End Snip****

This reads as option 2 seems to be the implementation of choice and overruling is done on a per attribute basis.

A fine question is what Les specifically means with "matching ASLA advertisements" ?
That can easily be read as the expected result is Option 1.

Long story short, what is the expected implementation behavior?
The DISCUSS indicate behavior as Option 2 (the overruling is done on a per attribute basis.)

G/

From: Lsr <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, June 4, 2021 11:03 AM
To: [email-masked]; [email-masked]
Subject: [Lsr] draft-ietf-lsr-flex-algo

Hi all,

Thanks,
Regards,
--Bruno

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 15 Jun 2021 15:28:25 +0000

Gunter -

Thanx for digging into the origins of some of the ambiguity.

I have just sent proposed Errata for RFC 8919/8920 which addresses the issues raised and better aligns the text in the two RFCs.
Please review and comment on that new thread.

For the record, Option #1 is what is specified - and this is always what was intended.

   Les

From: Lsr <[email-masked]> On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp)
Sent: Tuesday, June 15, 2021 7:45 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo

****snip****

G/

Hi all,

Thanks,
Regards,
--Bruno

Thank you.