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

[Italo Busi <[e-mail]>]

Tarek,

Thanks for your responses.

Please find some further comments marked as [Italo]

Thanks, Italo

From: Tarek Saad (tsaad) [mailto:[e-mail]]
Sent: lunedì 17 luglio 2017 20:59
To: Belotti, Sergio (Nokia - IT/Vimercate); Lou Berger; [e-mail]
Cc: Italo Busi
Subject: Re: [Teas] Status update of draft-busibel-teas-yang-path-computation-03

Hi Sergio,

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

From: Teas <[e-mail]<mailto:[e-mail]>> on behalf of "Belotti, Sergio (Nokia - IT/Vimercate)" <[e-mail]<mailto:[e-mail]>>
Date: Monday, July 17, 2017 at 12:53 PM
To: Lou Berger <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "Belotti, Sergio (Nokia - IT/Vimercate)" <[e-mail]<mailto:[e-mail]>>, Italo Busi <[e-mail]<mailto:[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.

[Italo] That would help, thanks.
I think we need to finalize the list of which attributes need to be reused by the path computation module.
Our current assumption/understanding and doubts are reported here:

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.

[Italo] Thanks for the clarification.
The follow-up question is how the topology-id is chosen (e.g., by the MDSC) especially when multiple topologies from the same layer are being exported (e.g., by the PNC).
In particular the doubt is whether Path Computation might help in taking this decision, e.g., whether the MDSC can decide to request TE Tunnel setup in topology 1 or in topology 2 after knowing from path computation RPC which paths would be computed in these two topologies and their characteristics.

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

[Italo] My understanding is that this topic is generic TE. The solution in draft-lazzeri-pce-residual-bw describes the solution for PCEP while the open issue here is to provide a solution for the TE Tunnel and Path Computation YANG model.
-
-          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?

[Italo] We agree with you: CT is not applicable to non-packet, but is needed for packet/MPLS.
Therefore, it is correct that this attribute does not appear neither in the Path Computation RPC nor in the TE Tunnel model, but in a packet/MPLS augmentation for the TE Tunnel model and for the path computation RPC.
For the TE Tunnel model we have noted this augmentation is defined in the same document as the TE Tunnel model but in a different YANG module (i.e. in the [e-mail]<mailto:[e-mail]> module).
The doubt we have is where (i.e., in which document) we need to develop the packet/MPLS augmentation for Path Computation RPC.

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

[Italo] As far as I have understood the comment we have received, the intention is to be able to request a controller (e.g., PNC) to setup a TE Tunnel or to perform Path Computation for a path supporting local protection without using the RSVP-TE model but using only the TE Tunnel model and Path Computation RPC.


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