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

["Zhangxian (Xian)" <[e-mail]>]

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

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;
  }

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

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

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

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

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

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