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

[Tarek Saad <[e-mail]>]

 Hi yuchaode,

Thank you for your review and comments. Please note, we have uploaded rev 35<https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-te-35> of the draft which may address some of the concerns you raise. Please see inline indexed by [TS].

From: Teas <[e-mail]> on behalf of yuchaode <yuchaode=[e-mail]>
Date: Friday, December 8, 2023 at 3:06 AM
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.

[TS]: Yes, the constraint type can be specified with each route entry in “explicit-route-usage” leaf. The default is to include – hence, the example did not set it explicitly. We’ve explicitly set it now for clarity.



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!
[TS]: The two lists serve a different purpose.
The 'route-object-exclude-always' list holds route entries that are always excluded from the path computation.  The exclusion or route entries during path computation is not order sensitive and is honored in the computation of the full path.
The 'route-object-include-exclude' list holds include or exclude route entry constraints for path computation. The path computation considers those route entry constraints in the order they appear in this list. Once a route entry constraint is consumed from this list, it is no longer considered any further computation of subsequent sub path.

Regards,
Tarek (for the co-authors)

发件人: yuchaode
发送时间: 2023年12月8日 15:19
收件人: [e-mail]; TEAS WG Chairs <[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:image001.png@01DA29EB.23243600]
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