Re: [Teas] MPLS and TE tunnels YANG data model meeting

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

Thank you Xian and Sergio for your review and comments. Pasting your notes below and responding to them inline. Let me know if you have further comments on them.

Comments
** 1)There is nothing related to latency/delay in the metric.
[TS]: There are provisions for what metric to optimize (TE or IGP). Traditionally, the TE metric is used for latency. Is that not enough in your opinion?
      |  |  +--rw named-constraints* [name] {te-types:named-path-constraints}?
      |  |  |  +--rw name                               string
      |  |  |  +--rw path-constraints
      |  |  |  |  +--rw topology-id?       te-types:te-topology-id
      |  |  |  |  +--rw cost-limit?        uint32
      |  |  |  |  +--rw hop-limit?         uint8
      |  |  |  |  +--rw metric-type?       identityref
      |  |  |  |  +--rw tiebreaker-type?   identityref
      |  |  |  |  +--rw ignore-overload?   boolean

** 2) it seems to me there is some mix of metric and objective function. For Objective function why do not refer to what described in RFC 5541 sec. 4 ?
[TS]: Yes, RFC5541 contains more elaborate OFs and metric-types that we can extend to cover. Let’s discuss in next meeting if this needs to be in TE base (I doubt many vendors support all the OFs).
BTW, the objective function (MCP) and which metric to optimize for can be selected on per path using path-metric constraint:

      |  |  |  |  |  +--ro path-constraints
      |  |  |  |  |  |  +--ro topology-id?       te-types:te-topology-id
      |  |  |  |  |  |  +--ro cost-limit?        uint32
      |  |  |  |  |  |  +--ro hop-limit?         uint8
      |  |  |  |  |  |  +--ro metric-type?       identityref
      |  |  |  |  |  |  +--ro tiebreaker-type?   identityref
      |  |  |  |  |  |  +--ro ignore-overload?   boolean
      |  |  |  |  |  |  +--ro path-affinities {named-path-affinities}?
      |  |  |  |  |  |  |  +--ro (style)?
      |  |  |  |  |  |  |     +--:(values)
      |  |  |  |  |  |  |     |  +--ro value?         uint32
      |  |  |  |  |  |  |     |  +--ro mask?          uint32
      |  |  |  |  |  |  |     +--:(named)
      |  |  |  |  |  |  |        +--ro constraints* [usage]
      |  |  |  |  |  |  |           +--ro usage         identityref
      |  |  |  |  |  |  |           +--ro constraint
      |  |  |  |  |  |  |              +--ro affinity-names* [name]
      |  |  |  |  |  |  |                 +--ro name    string


** 3) Why nothing about exclusion , topology-exclusion, path-exclusion , for path computation constraints?
[TS]: Topology inclusion is there  using the topo-id (see above) – inclusion and exclusion can be on per ERO or affinities/SRLG using below:

      list explicit-route-objects {
        key "index";
        description
          "List of explicit route objects";
        leaf index {
          type uint8 {
            range "0..255";
          }
          description
            "Index of this explicit route object";
        }
        leaf explicit-route-usage {
          type identityref {
            base te-types:route-usage-type;
          }
          description "An explicit-route hop action.";
        }

affinities:
       case named {
          list constraints {
            key "usage";
            leaf usage {
              type identityref {
                base resource-affinities-type;
              }

SRLGs:
        case named {
          list constraints {
            key "usage";
            leaf usage {
              type identityref {
                base route-exclude-srlg;
              }
              description "SRLG usage";
            }

exclusion/inclusions is there on per ERO.

** 4) I do not see requested bw info..
[TS]: It is in ietf-rsvp-te-mpls.yang. Let us discuss if you’d like to see it present in another model..

  grouping lsp-bandwidth_config {
    description
      "LSP bandwidth grouping";
    leaf static-bandwidth {
      type uint32;
      description
        "Static bandwidth, e.g., using
         offline calculation";
    }
    uses lsp-auto-bandwidth_config;
  }

** How to specify the following constraint?
1: I want a least hop path between A and B?
[TS]: The default IGP cost is to be equal cost on all links – so, optimizing for IGP would yield the min-hop path.. However, if explicitly needed, I’ll expand metric-type to include “hop”

2: I want a path with delay smaller than X ms or a path with minimum delay?
      |  |  |  |  |  +--ro path-constraints
      |  |  |  |  |  |  +--ro topology-id?       te-types:te-topology-id
      |  |  |  |  |  |  +--ro cost-limit?        uint32
      |  |  |  |  |  |  +--ro hop-limit?         uint8
      |  |  |  |  |  |  +--ro metric-type?       identityref

Minimum delay, you’ll select the metric-type TE to optimize when computing path.
Smaller than X msec, then you need to set cost-limit to X.

te-optimization-criterion defined in te-types.yang, but not used in ietf.te.yang
[TS]: Yes, this seems to be redundant with path-metric-type.. I’ll sync-up with Xufeng to see if we can unify into 1.
  identity path-metric-type {
    description
      "Base identity for path metric type";
  }

  identity path-metric-te {
    base path-metric-type;
    description
      "TE path metric";
  }

  identity path-metric-igp {
    base path-metric-type;
    description
      "IGP path metric";
  }

Capability current missing.
Propose to add the following constraint:
1: min-hop empty
[T]: this is not a constraint but a metric to optimize for. I’ll append the path-metric-type above to include identity path-metric-hop;

(as in state, the ability to show the actual hop)
2：delay uint32
3: min-delay empty
[TS]: the provision to select path-metric-te is already there. And setting the limit is there..


**  Current draft only mentioned NETCONF, but for controller consumption of this ietf-te.yang model, we use RESTCONF protocol. Given that RESTCONF is already in WG LC stage, could we mention this somewhere in the draft? Suggestions would be either in the Introduction section, or Section 2.2 where the controller is mentioned.
[TS]: sure. We’ll reference RESTCONF in the draft.

** 1: A flag missing to show whether it is a Loose or Strict hop? See RFC3209.
[TS]: it is already there. Please see below:
      |  |  |  |  |  |  +--:(explicit)
      |  |  |  |  |  |     +--rw explicit-path-name?       string
      |  |  |  |  |  |     +--rw explicit-route-objects* [index]
      |  |  |  |  |  |        +--rw index                   uint8
      |  |  |  |  |  |        +--rw explicit-route-usage?   identityref
      |  |  |  |  |  |        +--rw (type)?
      |  |  |  |  |  |           +--:(ipv4-address)
      |  |  |  |  |  |           |  +--rw v4-address?             inet:ipv4-address
      |  |  |  |  |  |           |  +--rw v4-prefix-length?       uint8
      |  |  |  |  |  |           |  +--rw v4-loose?               boolean


** 2: In optical network, directionality of a termination point is also needed.  For example, a loose hop as NE1/TP1 (ingress), is very different from a loose hop as NE1/TP1 (egress). Is this requirement common to both packet and optical?
[TS]: the process of processing incoming PATH ERO and modifying the outgoing ERO is defined in rfc3209#section-4.3.4.1 and rfc3209#section-4.3.4.2.. Does that not cover the optical use case you have above? If not can you clarify?

** How can the following two functions supported?
** 1: For a transport tunnel, we need to specify whether a tunnel is revertive or not. Reversion means that the original path will not be torn down and the service can roll back to this path if necessary.  Is it something common?
** SB> agree on the comment
[TS]: we need to discuss if this is a base functionality that we’ll support or specific to optical. In either case, yes, this mode will still need to be defined.

** 2: We need to the model be able to allow the client to specify if the controller can do a reversion or not, by specifying a reversion-lock attribute. Is it something common?
** SB> Agree is like a policy for reversion normally used in transport .
[TS]: There’s a “delegation information” that can be defined for PCE-controlled tunnel.. However, I agree it has to be generic enough to cover (non-PCE) centrally controlled tunnels. We can discuss this in next meeting.

** 3: Another function we need is to manual switch from one path to another for a tunnel.  For example, in 1:1 case, even though there is no failure, a client can ask the controller to switch the traffic from the working to protection path, so that some maintenance work can be ** done on the working path.  Can it be supported by the existing te model?
** SB> Agree .need to have it if common.
[TS]: There are 2 ways I expect this can be done: 1) Voluntarily by the TE device (periodically or based on update of topology event), the device would evaluate tunnel is placed on the more preferred path (based on preference), 2) Triggered immediately by the operator. The latter I expect an RPC (yet to be defined) to trigger this. I’ll try to have something for next week to discuss.

** How is preference used?
** Can it used to support the requirement to specify the priority of restoration? Say if tunnel x, y and z fail, the one with higher priority will be rerouted first.
** SB> good point to raise
[TS]: tunnel/LSP priority is separate from path preference.. Path preference is taken into consideration when evaluating which path to pick from multiple configured for same tunnel.

** When this model is consumed by a controller to talk with a northbound client (say: a multi-domain orchestrator), the client DOES NOT care where and how controller get this information. So the origin-type and the constraint written in the code is not needed.
** Suggestion: removing the origin-type and the when conditional statement.
** SB: agree on the comment and suggestion
[TS]: we discussed that controller will usually contains ingress LSP information only (as is the case, e.g. in PCE world). Let’s discuss the usecase you have in mind.

** Oper-status vs. lsp-operational-status: these two are a bit too close, how about re-naming the second to carry-normal-traffic?
[TS]: Looking into this.

The impact of schema mount:
Does schema mount allow to augment the new leafs to the existing subtree within the ietf-te.yang? For example: there are more objective functions I would like to add in the path-constraints. How to do that?
SB> good point to address for clarification
[TS]: Yes, I expect schema mount will continue to allow augmentation of the mounted model.. As long as the target path to be augmented can be relatively defined..

Regards,
Tarek


From: "Zhangxian (Xian)" <[e-mail]>
Date: Friday, October 21, 2016 at 5:00 AM
To: Tarek Saad <[e-mail]>, "Chenxia (D)" <[e-mail]>, Himanshu Shah <[e-mail]>, "Wen, Bin" <[e-mail]>, Vishnu Pavan Beeram <[e-mail]>, Raqib Jones <[e-mail]>, "Rakesh Gandhi (rgandhi)" <[e-mail]>, "Kamran Raza (skraza)" <[e-mail]>, "[e-mail]" <[e-mail]>, Igor Bryskin <[e-mail]>, Paweł Brzozowski <[e-mail]>
Cc: Xufeng Liu <[e-mail]>, Paweł Kaczmarek <[e-mail]>, "Belotti, Sergio (Nokia - IT)" <[e-mail]>, Anurag Sharma <[e-mail]>
Subject: Re: MPLS and TE tunnels YANG data model meeting

Hi, Tarek, All,

We do have some questions that we think should be discussed before a new version is posted. Please see the attached document for the questions that we have.

If you could consider how to address them directly in the YANG code update, that would be great. But if you see more discussions are needed, could we please discuss over emails? It would be much appreciated if they can be addressed in this update.


Regards,
Xian