Re: [Teas] one more question when reading the example of session12.6///答复: A suspected issue was found in the TE tunnel draft and a small comment about path computation policy

[Italo Busi <[e-mail]>]

Hi TEAS WG,

The participants to the TE weekly call last Friday (including authors/contributors to the TE tunnel model), discussed the following comment from Chaode (see also the mail below):

But why there is a “-always” suffix in its parent container “explicit-route-objects-always”?

The preference of the people in the call was to rename the container “explicit-route-objects-always” as container “explicit-route-objects”

This container is defined within a grouping already defined in RFC8776 and therefore this change will be an NBC change for RFC8776-bis according to section 11 of RFC7950

However, considering that this grouping is not used by any published RFC but it is used by few I-Ds, the participants to the call preferred to just change the name of the container in RFC8776-bis rather than defining a new grouping and update all the other I-Ds using this existing grouping

Is there any concern from the TEAS WG with this proposed change?

Thanks, Italo (on behalf of the participants to the call)

From: yuchaode <[e-mail]>
Sent: venerdì 8 dicembre 2023 09:06
To: '[e-mail]' <[e-mail]>; 'TEAS WG Chairs' <[e-mail]>
Subject: [Teas] one more question when reading the example of session12.6///答复: A suspected issue was found in the TE tunnel draft and a small comment about path computation policy


I found in the example of session 12.6, there are a lot of “route-object-include-exclude” structures. There are only index and hop information provided in these structures, but how can we know these hops are specified to be included or excluded?

And then, I checked the TE types model and found it had defined an “explicit-route-usage” attribute which can be used to specify the usage. And the default value is "te-types:route-include-object". Well, it is clear for me all the hops are indicated to be included. But I would like to suggest that it is better to specify the “explicit-route-usage” in the example. At least there should be some different usages for a part of hops.  Otherwise some other people would meet with the same problem of mine. If there is not a default value for the “explicit-route-usage” and it is mandatory to indicate the usage, I think it would be better.

Please the authors check.

One more question about the design of “explicit-route-objects-always” structure.
As it describes in the document, the “explicit-route-objects-always” is a YANG container that contains two route objects lists: “route-object-exclude-always” and “route-object-include-exclude”. The “route-object-exclude-always” is a list of route entries to always exclude from the path computation while the “route-object-include-exclude” is a list of route entries to include or exclude in the path computation.

It seems like that these two structures have some overlaps.
Is “route-object-include-exclude” not needed to be always considered in the path computation? But why there is a “-always” suffix in its parent container “explicit-route-objects-always”?
Is “route-object-include-exclude” only used to indicate route entries to include in the path computation? But why there is a “explicit-route-usage” attribute in it?
Or maybe is the “route-object-exclude-always” a redundant structure?
Please the authors confirm. Thanks!


发件人: yuchaode
发送时间: 2023年12月8日 15:19
收件人: [e-mail]<mailto:[e-mail]>; TEAS WG Chairs <[e-mail]<mailto:[e-mail]>>
主题: A suspected issue was found in the TE tunnel draft and a small comment about path computation policy

Hi TEAS Working Group,

I found a suspected issue in the latest version of TE Tunnel draft by accident. Please the authors have a look.
It seems like that the previous “p2p-primary-paths” container was renamed into “primary-paths”.
But in the example of session 12.5(https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-te-34#section-12.5-2), the URL still points to “p2p-primary-paths” structure while the response is using “primary-path” structure. Just like the screenshot shows:
[cid:[e-mail]15C390]
I think the authors probably missed to change the URL. Please the authors check!

This issue was found when I was doing some research on the path computation policy. I am using an old version, and I was trying to find the “p2p-primary-paths” and then found there was only one case matched.
And I noticed that this “p2p-primary-path” structure was renamed by some previous versions. This is an accidental discovery and does not intentionally delay the release of TE tunnels.

BTW, I found that all the primary & secondary paths and their reverse paths can support to specify different path computation policy. This capability is great.
But what I met is people only wanted to specify a unified path computation policy for all the paths. So is it possible to specify the path computation policy only in the primary-path, and the other paths use this policy by default if there is no specific policy specified on their paths.
If the authors agree with this proposal, can some more description be added in the draft or in the model to make it clear? Thanks!

B.R.
Chaode