Hello,

I perfectly understand your use-case. Unfortunately, I don't know how to address it.

Indeed, Path computation algorithm uses the graph topology to find suitable path according to requested parameters. The graph topology is itself automatically fulfill with what ODL learnt through BGP-LS. And here it is the problem. BGP-LS provide Link state TE parameters including the Unreserved Bandwidth on a per priority level basis with priority level from 0 to 7 representing the index in the table in this order. So, graph topology does no more than reproduce the same schema.

Unfortunately, RFC 7752 & co doesn't provide the possibility to convey DS-TE (DiffServ-Traffic Engineering) parameters you have configured on the Cisco router.

We could eventually envisage to enhance the Graph yang model in order to support DS-TE, but then, you need to manually fulfill them. It is like the Extended Performance Metric. There are supported by BGP-LS and the Graph model, but, right now, only Cisco is supporting delay metric. Thus, for a complete TE management, we need to fulfill manually the graph with Performance metrics.

Now, regarding the actual code, we assume that priority level is map one by one to the same value as Class Type. Which of course is only an hypothesis. Perhaps, to avoid any confusion, we need to rename ClassType as PriorityLevel in both the yang model and the code.

Regarding the example, I can't tell you if there are correct or not without the complete topology or graph topology. You could mail me directly if you would check the result.

Olivier

Hello Olivier,

Thanks for your response.

I think a misderstanding. I have no problem with priority level and DS-TE configuration. In the standard, DS-TE provide a mapping to reuse the 8 priority level (of ospf-te and bgp-ls) to convey the limited view of DS-TE priority and class type informations. Of course, we are limited to 8 unreserved bandwidth against 16 possibility for Cisco (2 class-type * 8 priority) and 64 for another router => I have no problem with it, it's the standard.  my DS-TE configuration is here to map TE-class (class-type + priority) with the 8 unreserved bandwidth of OSPF-TE and BGP-LS. Consider the Te-class as 1 unreserved bandwith with priority level (0 to 7).

also, Graph is good for me, I am finding all information with the right values.

no, the problem is the comparaison index number of unreservedBandwidth list as priority level number. it's wrong. In UnreservedBandwidth bean, there is a parameter for the class-type number (or priority level if you want). Why priority level is comparesd on index list against class-type parameter in unreservedBandwidth Bean ? In my case, the first index of the list (0) correspond to priority 7. if I request algo path computation with class-type 7, in reality the comparaison is done with unreservedbandwitdh containing class-type (priority level) = 0 : I expected comparaison with unreserved bandwidth with priority level =7

If it's not clear, i can send you an email directly tomorrow.

And Thanks you for this module graph and algo, very good jobs

Best Regards,

Jean-Marc

Hello Jean-Marc,

So, if I correctly understand what you mean, the comparison in Path Computation is based on index and not Class-Type. As mention in my previous post, we made the hypothesis that Class-Type == index. To be sure, we design the yang model in accordance:

       list unreserved-bandwidth { 
            description "Unreserved bandwidth for 0-7 class type"; 
            max-elements "8"; 
            ordered-by user; 
            key "class-type"; 
            leaf class-type { 
                type uint8 { 
                    range "0..7"; 
                } 
            } 
            leaf bandwidth { 
                description "Unreserved bandwidth for this class type"; 
                type decimal-bandwidth; 
            } 
        }

The ordered-by user statement is here to guarantee that. But, perhaps it is not working as expected and perhaps the graph fulfillment from BGP-LS is not respecting this assumption.

I will check that and made some test to verify.

But, I'm also looking to RFC 5455 (PCEP extension for DiffServ). In section 3.4 Determination of Traffic Engineering Class (TE-Class), it is mention:

   As specified in RFC 4124, a CT and a preemption priority map to a
   Traffic Engineering Class (TE-class), and there can be up to 8
   TE-classes.  The TE-class value is used to determine the unreserved
   bandwidth on the links during path computation.  In the case of a
   PCE, the CT value carried in the CLASSTYPE object and the setup
   priority in the LSP Attribute (LSPA) object are used to determine the
   TE-class corresponding to the path computation request.  If the LSPA
   object is absent, the setup priority is assumed to be 0.

If I could easily get Class-Type and Setup Priority, I'm unable to map them to the given TE-Class as I have no knowledge of the mapping table that has been setup on router. If Such mapping table is the same in all the network (which seems a reasonable hypothesis from an operator point of view), we could configure it (whatever the mechanism) as static mapping and use it. If is a different mapping per router, then, we need to update the graph topology to fulfill this mapping table.

Just let me know what you are expected ? Just a code modification to be sure that Unreserved Bandwidth is compared with the correct Class Type and not index (even if our hypothesis is right) or going to a more deeper modification to be compliant to RFC5455 ?

Don't hesitate to send me an e-mail if you would have more discussion on Traffic Engineering.

Regards

Olivier

the fix works with magnesium SR2 and SR3.

issue can be closed.

thanks

Jean-Marc