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

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Sun, 23 Oct 2016 18:46:26 +0000

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)" <[email-masked]>
Date: Friday, October 21, 2016 at 5:00 AM
To: Tarek Saad <[email-masked]>, "Chenxia (D)" <[email-masked]>, Himanshu Shah <[email-masked]>, "Wen, Bin" <[email-masked]>, Vishnu Pavan Beeram <[email-masked]>, Raqib Jones <[email-masked]>, "Rakesh Gandhi (rgandhi)" <[email-masked]>, "Kamran Raza (skraza)" <[email-masked]>, "[email-masked]" <[email-masked]>, Igor Bryskin <[email-masked]>, Paweł Brzozowski <[email-masked]>
Cc: Xufeng Liu <[email-masked]>, Paweł Kaczmarek <[email-masked]>, "Belotti, Sergio (Nokia - IT)" <[email-masked]>, Anurag Sharma <[email-masked]>
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

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Thu, 27 Oct 2016 07:18:11 +0000

Hi, Tarek, All,

   Please see my response inline, marked with <Xian2>, for some points that I think should be discussed further:

发件人: Tarek Saad (tsaad) [mailto:[email-masked]]
发送时间: 2016年10月24日 2:46
收件人: Zhangxian (Xian); Chenxia (D); Himanshu Shah; Wen, Bin; Vishnu Pavan Beeram; Raqib Jones; Rakesh Gandhi (rgandhi); Kamran Raza (skraza); [email-masked]; Igor Bryskin; Paweł Brzozowski; Belotti, Sergio (Nokia - IT)
抄送: Xufeng Liu; Paweł Kaczmarek; Belotti, Sergio (Nokia - IT); Anurag Sharma; [email-masked]
主题: Re: MPLS and TE tunnels YANG data model meeting

Comments

affinities:
       case named {
          list constraints {
            key "usage";
            leaf usage {
              type identityref {

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

<Xian2>:   This attribute is not tied up with RSVP-TE, why not move it into the base model? For controller, we also need to do use this information.

** 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”
<Xian2>: IGP cost is barely used in transport networks. I prefer to add a more explicit type in the metric-type.

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.
<Xian2>: Ok. Good to know this. Thank you. One last point related to this, is there an attribute in the state to show the actual cost (say, hop-num)?

<snip>

** 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?
<Xian2>: RRC3209 only describes the IPv4 and IPv6 nodes, it does not describe the case I mentioned.  RFC3477 defines the unnumbered link sub-object of ERO,  but it does not talk about directionality issue.  Let me try to explain with an example,  we can discuss further to see how this can be addressed:

In TE-topology, we defined the notion of link Termination Point (TP) and it is usually bidirectional.

Assume a node A has three TPs, (TP1, TP2 and TP3), the two cases will result in very different path selection.
Loose ERO 1: Src -  nodeA/TP2(ingress) – Dest.
Result path example: SRC – nodeA/TP2(ingress) – NodeA/TP3 – Dest.
Loose ERO 2: Src – nodeA/TP2(egress)- Dest.
Result path example: SRC – nodeA/TP1 – NodeA/TP2(egress) – Dest.

How can we address this?

<Xian2>:  This is a very important function/feature in transport networks. If not generic, we probably should consider writing a model augmentation.

** 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.
<Xian2>: Ok. This is actually linked with the previous question. So, we should consider them together.

** 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.
<Xian2>:  I will prefer option 2 since the device will not necessarily know when to trigger the switching.  Anyway, let’s discuss to see how to address this.

<Xian2>: Ok. So I understand the the function we are asking for is not yet supported by the te model, right? I think we should add a priority level to the tunnel itself, not to a specific path.

<Xian2>:  not sure what you meant by ingress LSP. A controller will have the complete RRO information, in terms of how it gets this, it should not be reflected in the model since the northbound client does not care. What is more, the controller can either get from the head-end node OR, it can get from a stateful PCE. So, I still think the origin-type and the when condition is not something meaningful for controller consumption.

However,  I think for device consumption, it needs to add this when condition, right?

<skip>

<Xian2>: Could you give us a point or an example how this can be done? I cannot it find in the NETMOD WG. Thank you.

Regards,
Xian

Regards,
Tarek

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

Hi, Tarek, All,

Regards,
Xian