Split the tunnel-p2p-params_config grouping in two groups

[italobusi]

Path Computation RPC needs some but not all the attributes in the tunnel-p2p-params_config grouping.

• [x] understand which attributes are needed and which are not needed
• [x] request TE Tunnel model to split the group into two groups accordingly (https://github.com/ietf-mpls-yang/te/pull/27)
• [x] review the YANG model based on TEAS WG disucsion at IETF 104: https://github.com/rvilalta/ietf-te-path-computation/issues/31#issuecomment-477249925

[italobusi]

Based on the discussion on open issue #23 , the following attributes are not needed:

• identifier
• description
• admin-status
• hierarchical-link-id

[italobusi]

Pending resolution of open issue #23 to determine whether hold-priority attribute is needed or not needed

[italobusi]

Note that the tunnel-params_config is not longer existing in the latest version of the TE Tunnel model:

https://tools.ietf.org/html/draft-ietf-teas-yang-te-06

The groupings tunnel-p2mp-params_config and tunnel-p2p-params_config seems providing the same information.

[italobusi]

I think also the following attributes are not needed for path computation:

• name
• type
• signaling-type
• bidir-assoc-properties

[italobusi]

The following attributes are not clear to me:

    leaf preference {
      type uint8 {
        range "1..255";
      }
      description
        "Specifies a preference for this tunnel.
        A lower number signifies a better preference";
    }
    leaf reoptimize-timer {
      type uint16;
      units seconds;
      description
       "frequency of reoptimization of
        a traffic engineered LSP";
    }

[efralaz]

The bidir-assoc-properties seems to include information useful for path computation. The useful information is the presence of the bidir itself, indicating that we want a path computation for a couple of controdirectional paths (different cases when both paths need to be computed, or one of them is already existing) and the leaf "type" which specifies whether the two paths should be co-routed or not. This is important; there is also provisioning-only information which could be not present (or ignored) in a stateless path computation.

[italobusi]

Carlo/Francesco/Italo/Sergio:

We need at least the following attributes:

• encoding
• switching-type
• ignore-overload
• te-types:common-constraints_config grouping

Pending discussion with TE Tunnel:

• preference

@sergiobelotti : ask clarification about the meaning of the preference attribute in the TE Tunnel model

Pending open issue #16:

• source
• destination
• src-tp-id
• dst-tp-id

@efralaz : check with TE Tunnel model whether the ignore-overload applies only to the node, the link or both the nodes and links

@italobusi: propose changes to the TE Tunnel model to allow reusing the subset of the attributes we need

[sergiobelotti]

The request for clarification about "preference" leaf to te-tunnel team is provided in: https://github.com/ietf-mpls-yang/te/issues/16

[italobusi]

Based on clarification from te-tunnel team, we need the following attribute:

• preference

See: ietf-mpls-yang/te#16

Based on discussion on open issue #16, we also need the following attributes:

• source
• destination
• src-tp-id
• dst-tp-id

[italobusi]

Conclusion

We need the following attributes:

• encoding
• switching-type
• ignore-overload
• preference
• source
• destination
• src-tp-id
• dst-tp-id
• te-types:common-constraints_config grouping

@efralaz : propose an updated YANG RPC

@italobusi: propose changes to the TE Tunnel model to allow reusing the subset of the attributes we need

[italobusi]

Pending discussion with TE Tunnel authors about a grouping we could re-use

@italobusi: raise a proposal for a grouping we could reuse after IETF 101 cut-off

[italobusi]

Pull request #45 created to close this open issue

[italobusi]

Thinking further, the pull request #45 provides a work-around that could be used while waiting for the TE tunnel updates

I would propose to merge pull request #45 before requesting YANG doctor review and to re-open this issue to track the need to update the YANG model after the merging of pull request ietf-mpls-yang/te#27

[italobusi]

Tarek has required us to provide the list of applicable attributes and the list of not-applicable attributes

This is the list of applicable attributes/groupings:

• encoding
• switching-type
• ignore-overload
• preference
• source
• destination
• src-tp-id
• dst-tp-id
• te-types:te-topology-identifier grouping
• te-types:tunnel-constraints_config grouping (See Note 1 below)

This is the list of the not-applicable attributes/groupings:

• name
• identifier
• description
• provisioning-state
• reoptimize-timer
• tunnel-p2p-associations_config
• protection-restoration-params_config (See Note 2 below)
• p2p-dependency-tunnels_config

Note 1 - The te-types:common-constraints_config grouping within the te-types:tunnel-constraints_config would duplicate with the same grouping used by the te-types:generic-path-constraints

Note 2 - The need to use the protection-restoration-params_config in the Path Computation RPC is still under discussion. If needed, a use statement for this grouping will be added

@sergiobelotti , @efralaz : could you please check the two lists before we send them to Tarek?

[efralaz]

The lists seem ok to me. Francesco

From: italobusi notifications@github.com Sent: 30 May, 2018 11:32 AM To: rvilalta/ietf-te-path-computation ietf-te-path-computation@noreply.github.com Cc: Francesco Lazzeri francesco.lazzeri@ericsson.com; Mention mention@noreply.github.com Subject: Re: [rvilalta/ietf-te-path-computation] Split the tunnel-p2p-params_config grouping in two groups (#31)

Tarek has required us to provide the list of applicable attributes and the list of not-applicable attributes

This is the list of applicable attributes/groupings:

• encoding
• switching-type
• ignore-overload
• preference
• source
• destination
• src-tp-id
• dst-tp-id
• te-types:te-topology-identifier grouping
• te-types:tunnel-constraints_config grouping (See Note 1 below)

This is the list of the not-applicable attributes/groupings:

• name
• identifier
• description
• provisioning-state
• reoptimize-timer
• tunnel-p2p-associations_config
• protection-restoration-params_config (See Note 2 below)
• p2p-dependency-tunnels_config

Note 1 - The te-types:common-constraints_config grouping within the te-types:tunnel-constraints_config would duplicate with the same grouping used by the te-types:generic-path-constraints

Note 2 - The need to use the protection-restoration-params_config in the Path Computation RPC is still under discussion. If needed, a use statement for this grouping will be added

@sergiobelottihttps://github.com/sergiobelotti , @efralazhttps://github.com/efralaz : could you please check the two lists before we send them to Tarek?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/rvilalta/ietf-te-path-computation/issues/31#issuecomment-393095454, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABcqd7RKF_Wnrp9oEViC9_pXw7BqDheqks5t3mcogaJpZM4NLx4k.

[sergiobelotti]

The list seems ok for me. I forgot the meaning of ignore-overload. Is anyone able to remind me what is the scope of this leaf?

[italobusi]

Actually ignore-overload has been removed in draft-ietf-teas-yang-te-13 so it could be removed from the list

In draft-ietf-teas-yang-te-12, it used to be defined as:

    leaf ignore-overload {
      type boolean;
      description
        "The tunnel path can traverse overloaded node.";
    }

[italobusi]

Need to addess the comments from June 1st call with TE Tunnel authors:

AI (Sergio/Francesco/Italo): discuss the applicability of POLICY to override any client constraints. The POLICY matches one or any of the tunnel attributes. eg. tunnel name tunnel ID etc.

[italobusi]

Let's wait for the resolution of open issue #52 and re-evaluate the need to re-open this discussion within TEAS WG

[italobusi]

TEAS WG discussion at IETF 104 indicated that we will proceed keeping in path computation RPC only the required attributes that affect path computation

It may be no more possible to update the te-types, so we can develop ad-hoc grouping in the path computation RPC

• [x] review the YANG model accordingly