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

["Tarek Saad (tsaad)" <[e-mail]>]

Hi Sergio,

Thanks for the comments. Inline for some responses...

From: Teas <[e-mail]> on behalf of "Belotti, Sergio (Nokia - IT/Vimercate)" <[e-mail]>
Date: Monday, July 17, 2017 at 12:53 PM
To: Lou Berger <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "Belotti, Sergio (Nokia - IT/Vimercate)" <[e-mail]>, Italo Busi <[e-mail]>
Subject: [Teas] Status update of draft-busibel-teas-yang-path-computation-03

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:
[TS]: Yes, we can regroup non-tunnel generic parameters in a separate grouping that can be reused by the path-computaiton module.

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.
 [TS]: yes, currently the assumption is the source and destination endpoints of the tunnel reside in the same "namespace" identified by topoloy-id.

-          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.
[TS]: will need to research if this is specific to PCE or generic TE?
-
-          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.
[TS]: agreed, this may be relavant to tunnel path computation too. We can discuss if we can bring this support to the TE tunnel model.

-          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.
[TS]: Yes, currently CT is defined for packet/MPLS bandwidths.. Do you see need for this for non-packet?

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

[TS]: when RSVP-TE is the choice of signalling protocol for the tunnel's MPLS LSP, we already have this as part of the SESSION_ATTRIBUTE object flags (see below) as defined in RFC3209. If your comment in in the context of LSPs for non-RSVP-TE signaling we need to discuss if that is covered by static LSP model (or need to define it).


       |     +--ro rsvp-te-mpls:state

       |     |  +--ro rsvp-te-mpls:local-protection-desired?       empty

       |     |  +--ro rsvp-te-mpls:bandwidth-protection-desired?   empty

       |     |  +--ro rsvp-te-mpls:node-protection-desired?        empty

       |     |  +--ro rsvp-te-mpls:non-php-desired?                empty

       |     |  +--ro rsvp-te-mpls:entropy-label-cap?              empty

       |     |  +--ro rsvp-te-mpls:oam-mep-entities-desired?       empty

       |     |  +--ro rsvp-te-mpls:oam-mip-entities-desired?       empty

       |     +--ro rsvp-te-mpls:backup-info

       |        +--ro rsvp-te-mpls:state

       |           +--ro rsvp-te-mpls:backup-tunnel-name?         string

       |           +--ro rsvp-te-mpls:backup-frr-on?              uint8

       |           +--ro rsvp-te-mpls:backup-protected-lsp-num?   uint32

Regards,
Tarek

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