[Teas] Status update of draft-busibel-teas-yang-path-computation-03

["Belotti, Sergio (Nokia - IT/Vimercate)" <[e-mail]>]

Hi Lou, all,

In the slides for draft-busibel-teas-yang-path-computation-03 we have indicated some open points, mainly discussed with te-tunnel model authors , open issue that are not specific to yang path computation RPC but are also related to tunnel model.

To enhance the solution of these issues, we'd like to propose in advance a summary of the issues, to solicit  feedback in advance.


  *   Issue #18 Service Layer usage/role : we had originally Service Layer indication to identify the layer (technology) at which the tunnel is requested. Now in te-tunnel there are encoding type and switching type in grouping tunnel-p2p-params_config.  So we deleted Service Layer in RPC, but we are not using this grouping since there are attributes that are not needed for RPC .


  *   Issue #31 is linked to the above asking for separation into two grouping of tunnel-p2p-params_config in order to avoid path computation API to have useless attributes. Here below an initial list based on our current understanding and analysis
Grouping tunnel-p2p-params_config:

name: only for TE Tunnel
type: to be discussed
identifier: only for TE Tunnel
description: only for TE Tunnel
encoding: needed also for Path Computation
switching-type: needed also for Path Computation
protection-type: needed also for Path Computation
provisioning-state: only for TE Tunnel
preference: not clear the meaning
reoptimize-timer: only for TE Tunnel
source: needed also for Path Computation
destination: needed also for Path Computation
src-tp-id: needed also for Path Computation
dst-tp-id: needed also for Path Computation

grouping common-constraints_config:

topology-id: needed also for Path Computation (pending open issue #27)
ignore-overload: needed also for Path Computation
bandwidth-generic: needed also for Path Computation
disjointness: needed also for Path Computation
setup-priority: needed also for Path Computation
hold-priority: needed also for Path Computation
signaling-type: to be discussed


  *   Issue#27 is related to the meaning of topology-id . Our understanding of topology-id  is that any topology entity e.g. source and dst node IDs,  are within a given topology namespace. Topology-id is used as an additional constraint to force the path to be computed in a specific topology but  It is not clear how the topology-id can be chosen. The doubt is whether allowing path computation to compute paths on multiple topologies could provide information to assist the choice.


  *   Issue #30 : Residual BW , as new metric is proposed to diminish the potential number of path computation request  . See also draft-lazzeri-pce-residual-bw.
  *
  *   Issue #19: Relaxable and not relaxable constraints :  in PCEP it is possible to specify if a constraint is mandatory, optional, if the path computation must fail if the constraint is not met or to relax the constraint.
  *
  *   Issue #25 Class Type : In draft-ietf-teas-yang-te-08 the class-type is now defined within the [e-mail]<mailto:[e-mail]> module
For path computation, it may need to be defined in some MPLS-TE augmentation of the path computation RPC. So question is in  which document would better to define this augmentation.


  *   Issue #24 Missing Local Protection: suggest to sue Local protection as indicated in RFC 5440 and RFC 3209 , as single flag in Session Attribute Object .

0x01  Local protection desired

           This flag permits transit routers to use a local repair
           mechanism which may result in violation of the explicit
           route object.  When a fault is detected on an adjacent
           downstream link or node, a transit router can reroute
           traffic for fast service restoration.

            Current te-tunnel model supports only  e2e path protection in line with PROTECTION Object defined in RFC 4872.

Further details can be found in github https://github.com/rvilalta/ietf-te-path-computation/issues?q=is%3Aopen+is%3Aissue