[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-busibel-ccamp-path-computation-api) 00 01 02 03 draft-ietf-teas-yang-path-computation

TEAS Working Group                                           Italo Busi
Internet Draft                                                   Huawei
Intended status: Informational                           Sergio Belotti
Expires: May 2017                                                 Nokia
                                                           Victor Lopez
                                                 Oscar Gonzalez de Dios
                                                             Telefonica
                                                          Anurag Sharma
                                                               Infinera
                                                                Yan Shi
                                                           China Unicom
                                                         Ricard Vilalta
                                                                   CTTC
                                                     Karthik Sethuraman
                                                                    NEC

                                                      November 15, 2016





                Yang model for requesting Path Computation
              draft-busibel-teas-yang-path-computation-01.txt




Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt




Busi, Belotti, al.       Expires May 15, 2017                  [Page 1]


Internet-DraftYang model for requesting Path Computation  November 2016


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on May 15, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Abstract

   There are scenarios, typically in a hierarchical SDN context, in
   which an orchestrator may not have detailed information to be able
   to perform an end-to-end path computation and would need to request
   lower layer/domain controllers to calculate some (partial) feasible
   paths.

   Multiple protocol solutions can be used for communication between
   different controller hierarchical levels. This document assumes that
   the controllers are communicating using YANG-based protocols (e.g.,
   NETCONF or RESTCONF).

   This document describes some use cases for a YANG model to request
   path computation.

Table of Contents


   1. Introduction...................................................3
   2. Use Cases......................................................4
      2.1. IP-Optical integration....................................4
         2.1.1. Inter-layer path computation.........................6
         2.1.2. Route Diverse IP Services............................8
      2.2. Multi-domain TE Networks..................................8


Busi, Belotti, et al.    Expires May 15, 2017                  [Page 2]


Internet-DraftYang model for requesting Path Computation  November 2016


      2.3. Data center interconnections..............................9
   3. Interactions with TE Topology.................................11
      3.1. TE Topology Aggregation using the "virtual link model"...11
      3.2. TE Topology Abstraction..................................14
      3.3. Complementary use of TE topology and path computation....15
   4. Motivation for a YANG Model...................................17
      4.1. Benefits of common data models...........................17
      4.2. Benefits of a single interface...........................18
      4.3. Extensibility............................................19
   5. Path Optimization Request.....................................19
   6. YANG Model for requesting Path Computation....................19
      6.1. YANG model for stateless TE path computation.............20
         6.1.1. YANG Tree...........................................20
         6.1.2. YANG Module.........................................33
   7. Security Considerations.......................................42
   8. IANA Considerations...........................................42
   9. References....................................................42
      9.1. Normative References.....................................42
      9.2. Informative References...................................42
   10. Acknowledgments..............................................43

1. Introduction

   There are scenarios, typically in a hierarchical SDN context, in
   which an orchestrator may not have detailed information to be able
   to perform an end-to-end path computation and would need to request
   lower layer/domain controllers to calculate some (partial) feasible
   paths.

   When we are thinking to this type of scenarios we have in mind
   specific level of interfaces on which this request can be applied.

   We can reference ABNO Control Interface [RFC7491] in which an
   Application Service Coordinator can request ABNO controller to take
   in charge path calculation (see Figure 1 in the RFC) and/or ACTN
   [ACTN-frame],where controller hierarchy is defined, the need for
   path computation arises on both interfaces CMI (interface between
   Customer Network Controller(CNC) and Multi Domain Service
   Coordinator (MDSC)) and/or MPI (interface between MSDC-PNC).[ACTN-
   Info] describes an information model for the Path Computation
   request.

   Multiple protocol solutions can be used for communication between
   different controller hierarchical levels. This document assumes that



Busi, Belotti, et al.    Expires May 15, 2017                  [Page 3]


Internet-DraftYang model for requesting Path Computation  November 2016


   the controllers are communicating using YANG-based protocols (e.g.,
   NETCONF or RESTCONF).

   Path Computation Elements, Controllers and Orchestrators perform
   their operations based on Traffic Engineering Databases (TED). Such
   TEDs can be described, in a technology agnostic way, with the YANG
   Data Model for TE Topologies [TE-TOPO]. Furthermore, the technology
   specific details of the TED are modeled in the augmented TE topology
   models (e.g. [L1-TOPO] for Layer-1 ODU technologies).

   The availability of such topology models allows providing the TED
   using YANG-based protocols (e.g., NETCONF or RESTCONF). Furthermore,
   it enables a PCE/Controller performing the necessary abstractions or
   modifications and offering this customized topology to another
   PCE/Controller or high level orchestrator.

   The tunnels that can be provided over the networks described with
   the topology models can be also set-up, deleted and modified via
   YANG-based protocols (e.g., NETCONF or RESTCONF)using the TE-Tunnel
   Yang model [TE-TUNNEL].

   This document describes some use cases where a path computation
   request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can
   be needed.

2. Use Cases

   This section presents different use cases, where an orchestrator
   needs to request underlying SDN controllers for path computation.

   The presented uses cases have been grouped, depending on the
   different underlying topologies: a) IP-Optical integration; b)
   Multi-domain Traffic Engineered (TE) Networks; and c) Data center
   interconnections.

2.1. IP-Optical integration

   In these use cases, an Optical domain is used to provide
   connectivity between IP routers which are connected with the Optical
   domains using access links (see Figure 1).







Busi, Belotti, et al.    Expires May 15, 2017                  [Page 4]


Internet-DraftYang model for requesting Path Computation  November 2016



      --------------------------------------------------------------------
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                      IP+Optical Use Cases                        I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                     (only in PDF version)                        I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      --------------------------------------------------------------------

                    Figure 1 - IP+Optical Use Cases

   It is assumed that the Optical domain controller provides to the
   orchestrator an abstracted view of the Optical network. A possible
   abstraction shall be representing the optical domain as one "virtual
   node" with "virtual ports" connected to the access links.

   The path computation request helps the orchestrator to know which
   are the real connections that can be provided at the optical domain.


















Busi, Belotti, et al.    Expires May 15, 2017                  [Page 5]


Internet-DraftYang model for requesting Path Computation  November 2016






      --------------------------------------------------------------------
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I               IP+Optical Topology Abstraction                    I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                     (only in PDF version)                        I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      --------------------------------------------------------------------



               Figure 2 - IP+Optical Topology Abstraction

2.1.1. Inter-layer path computation

   In this use case, the orchestrator needs to setup an optimal path
   between two IP routers R1 and R2.

   As depicted in Figure 2, the Orchestrator has only an "abstracted
   view" of the physical network, and it does not know the feasibility
   or the cost of the possible optical paths (e.g., VP1-VP4 and VP2-
   VP5), which depend from the current status of the physical resources
   within the optical network and on vendor-specific optical
   attributes.

   The orchestrator can request the underlying Optical domain
   controller to compute a set of potential optimal paths, taking into
   account optical constraints. Then, based on its own constraints,
   policy and knowledge (e.g. cost of the access links), it can choose



Busi, Belotti, et al.    Expires May 15, 2017                  [Page 6]


Internet-DraftYang model for requesting Path Computation  November 2016


   which one of these potential paths to use to setup the optimal e2e
   path crossing optical network.


      --------------------------------------------------------------------
      I                                                                  I
      I              IP+Optical Path Computation Example                 I
      I                                                                  I
      I                                                                  I
      I                     (only in PDF version)                        I
      I                                                                  I
      --------------------------------------------------------------------


             Figure 3 - IP+Optical Path Computation Example

   For example, in Figure 3, the Orchestrator can request the Optical
   domain controller to compute the paths between VP1-VP4 and VP2-VP5
   and then decide to setup the optimal end-to-end path using the VP2-
   VP5 Optical path even this is not the optimal path from the Optical
   domain perspective.

   Considering the dynamicity of the connectivity constraints of an
   Optical domain, it is possible that a path computed by the Optical
   domain controller when requested by the Orchestrator is no longer
   valid when the Orchestrator requests it to be setup up.

   It is worth noting that with the approach proposed in this document,
   the likelihood for this issue to happen can be quite small since the
   time window between the path computation request and the path setup
   request should be quite short (especially if compared with the time
   that would be needed to update the information of a very detailed
   abstract connectivity matrix).

   If this risk is still not acceptable, the Orchestrator may also
   optionally request the Optical domain controller not only to compute
   the path but also to keep track of its resources (e.g., these
   resources can be reserved to avoid being used by any other
   connection). In this case, some mechanism (e.g., a timeout) needs to
   be defined to avoid having stranded resources within the Optical
   domain.

   These issues and solutions can be fine-tuned during the design of
   the YANG model for requesting Path Computation.



Busi, Belotti, et al.    Expires May 15, 2017                  [Page 7]


Internet-DraftYang model for requesting Path Computation  November 2016


2.1.2. Route Diverse IP Services

   This is for further study.

2.2. Multi-domain TE Networks

   In this use case there are two TE domains which are interconnected
   together by multiple inter-domains links.

   A possible example could be a multi-domain optical network.


      --------------------------------------------------------------------
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I              Multi-domain multi-link interconnection             I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                     (only in PDF version)                        I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      --------------------------------------------------------------------


           Figure 4 - Multi-domain multi-link interconnection

   In order to setup an end-to-end multi-domain TEpath (e.g., between
   nodes A and H), the orchestrator needs to know the feasibility or
   the cost of the possible TE paths within the two TE domains, which
   depend from the current status of the physical resources within each
   TE network. This is more challenging in case of optical networks
   because the optimal paths depend also on vendor-specific optical
   attributes (which may be different in the two domains if they are
   provided by different vendors).



Busi, Belotti, et al.    Expires May 15, 2017                  [Page 8]


Internet-DraftYang model for requesting Path Computation  November 2016


   In order to setup a multi-domain TE path (e.g., between nodes A and
   H), Orchestrator can request the TE domain controllers to compute a
   set of intra-domain optimal paths and take decisions based on the
   information received. For example:

   o  The Orchestrator asks TE domain controllers to provide set of
      paths between A-C, A-D, E-H and F-H

   o  TE domain controllers return a set of feasible paths with the
      associated costs: the path A-C is not part of this set(in optical
      networks, it is typical to have some paths not being feasible due
      to optical constraints that are known only by the optical domain
      controller)

   o  The Orchestrator will select the path A- D-F- H since it is the
      only feasible multi-domain path and then request the TE domain
      controllers to setup the A-D and F-H intra-domain paths

   o  If there are multiple feasible paths, the Orchestrator can select
      the optimal path knowing the cost of the intra-domain paths
      (provided by the TE domain controllers) and the cost of the
      inter-domain links (known by the Orchestrator)

  This approach may  have some scalability issues when the number of TE
  domains is quite big (e.g. 20).

  In this case, it would be worthwhile using the abstract TE topology
  information provided by the domain controllers to limit the number of
  potential optimal end-to-end paths and then request path computation
  to fewer domain controllers in order to decide what the optimal path
  within this limited set is.

  For more details, see section 3.3.

2.3. Data center interconnections

   In these use case, there is an TE domain which is used to provide
   connectivity between data centers which are connected with the TE
   domain using access links.








Busi, Belotti, et al.    Expires May 15, 2017                  [Page 9]


Internet-DraftYang model for requesting Path Computation  November 2016



      --------------------------------------------------------------------
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                Data Center Interconnection Use Case              I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                     (only in PDF version)                        I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      --------------------------------------------------------------------


            Figure 5 - Data Center Interconnection Use Case

   In this use case, a virtual machine within Data Center 1 (DC1) needs
   to transfer data to another virtual machine that can reside either
   in DC2 or in DC3.

   The optimal decision depends both on the cost of the TE path (DC1-
   DC2 or DC1-DC3) and of the computing power (data center resources)
   within DC2 or DC3.

   The Cloud Orchestrator may not be able to make this decision because
   it has only an abstract view of the TE network (as in use case in
   2.1).

   The cloud orchestrator can request to the TE domain controller to
   compute the cost of the possible TE paths (e.g., DC1-DC2 and DC1-
   DC3) and to the DC controller to compute the cost of the computing
   power (DC resources) within DC2 and DC3 and then it can take the
   decision about the optimal solution based on this information and
   its policy.





Busi, Belotti, et al.    Expires May 15, 2017                 [Page 10]


Internet-DraftYang model for requesting Path Computation  November 2016


3. Interactions with TE Topology

   The use cases described in section 2 have been described assuming
   that the topology view exported by each underlying SDN controller to
   the orchestrator is aggregated using the "virtual node model",
   defined in [RFC7926].

   TE Topology information, e.g., as provided by [TE-TOPO], could in
   theory be used by an underlying SDN controllers to provide TE
   information to the orchestrator thus allowing the Path Computation
   Element (PCE) within the Orchestrator to perform multi-domain path
   computation by its own, without requesting path computations to the
   underlying SDN controllers.

   This section analyzes the need for an orchestrator to request
   underlying SDN controllers for path computation even in these
   scenarios as well as how the TE Topology information and the path
   computation can be complementary.

   In nutshell, there is a scalability trade-off between providing all
   the TE information needed by the Orchestrator's PCE to take optimal
   path computation decisions by its own versus requesting the
   Orchestrator to ask to too many underlying SDN Domain Controllers a
   set of feasible optimal intra-domain TE paths.

3.1. TE Topology Aggregation using the "virtual link model"

   Using the TE Topology model, as defined in [TE-TOPO], the underlying
   SDN controller can export the whole TE domain as a single abstract
   TE node with a "detailed connectivity matrix", which extends the
   "connectivity matrix", defined in [RFC7446], with specific TE
   attributes (e.g., delay, SRLGs and summary TE metrics).

   The information provided by the "detailed abstract connectivity
   matrix" would be equivalent to the information that should be
   provided by "virtual link model" as defined in [RFC 7926].

   For example, in the IP-Optical integration use case, described in
   section 2.1, the Optical domain controller can make the information
   shown in Figure 3 available to the Orchestrator as part of the TE
   Topology information and the Orchestrator could use this information
   to calculate by its own the optimal path between routers R1 and R2,
   without requesting any additional information to the Optical Domain
   Controller.



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 11]


Internet-DraftYang model for requesting Path Computation  November 2016


   However, there is a tradeoff between the accuracy (i.e., providing
   "all" the information that might be needed by the Orchestrator's
   PCE) and scalability to be considered when designing the amount of
   information to provide within the "detailed abstract connectivity
   matrix".

   Figure 6 below shows another example, similar to Figure 3, where
   there are two possible Optical paths between VP1 and VP4 with
   different properties (e.g., available bandwidth and cost).


      --------------------------------------------------------------------
      I                                                                  I
      I             IP+Optical Path Computation Example                  I
      I                    with multiple choices                         I
      I                                                                  I
      I                                                                  I
      I                     (only in PDF version)                        I
      I                                                                  I
      --------------------------------------------------------------------


  Figure 6 - IP+Optical Path Computation Example with multiple choices

   Reporting all the information, as in Figure 6, using the "detailed
   abstract connectivity matrix", is quite challenging from a
   scalability perspective. The amount of this information is not just
   based on number of end points (which would scale as N-square), but
   also on many other parameters, including client rate, user
   constraints / policies for the service, e.g. max latency < N ms, max
   cost, etc., exclusion policies to route around busy links, min OSNR
   margin, max preFEC BER etc. All these constraints could be different
   based on connectivity requirements.

   It is also worth noting that the "connectivity matrix" has been
   originally defined in WSON, [RFC7446] to report the connectivity
   constrains of a physical node within the WDM network: the
   information it contains is pretty "static" and therefore, once taken
   and stored in the TE data base, it can be always being considered
   valid and up-to-date in path computation request.

   Using the "connectivity matrix" with an abstract node to abstract
   the information regarding the connectivity constraints of an Optical
   domain, would make this information more "dynamic" since the



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 12]


Internet-DraftYang model for requesting Path Computation  November 2016


   connectivity constraints of an Optical domain can change over time
   because some optical paths that are feasible at a given time may
   become unfeasible at a later time when e.g., another optical path is
   established. The information in the "detailed abstract connectivity
   matrix" is even more dynamic since the establishment of another
   optical path may change some of the parameters (e.g., delay or
   available bandwidth) in the "detailed abstract connectivity matrix"
   while not changing the feasibility of the path.

   "Connectivity matrix" is sometimes confused with optical reach table
   that contain multiple (e.g. k-shortest) regen-free reachable paths
   for every A-Z node combination in the network. Optical reach tables
   can be calculated offline, utilizing vendor optical design and
   planning tools,and periodically uploaded to the Controller: these
   optical path reach tables are fairly static. However, to get the
   connectivity matrix, between any two sites, either a regen free path
   can be used, if one is available, or multiple regen free paths are
   concatenated to get from src to dest, which can be a very large
   combination. Additionally, when the optical path within optical
   domain needs to be computed, it can result in different paths based
   on input objective, constraints, and network conditions. In summary,
   even though "optical reachability table" is fairly static, which
   regen free paths to build the connectivity matrix between any source
   and destination  is very dynamic, and is done using very
   sophisticated routing algorithms.

   There is therefore the need to keep the information in the
   "connectivity matrix" updated which means that there another
   tradeoff between the accuracy (i.e., providing "all" the information
   that might be needed by the Orchestrator's PCE) and having up-to-
   date information. The more the information is provided and the
   longer it takes to keep it up-to-date which increases the likelihood
   that the Orchestrator's PCE computes paths using not updated
   information.

   It seems therefore quite challenging to have a "detailed abstract
   connectivity matrix" that provides accurate, scalable and updated
   information to allow the Orchestrator's PCE to take optimal
   decisions by its own.

   If the information in the "detailed abstract connectivity matrix" is
   not complete/accurate, we can have the following drawbacks
   considering for example the case in Figure 6:




Busi, Belotti, et al.    Expires May 15, 2017                 [Page 13]


Internet-DraftYang model for requesting Path Computation  November 2016


   o  If only the VP1-VP4 path with available bandwidth of 2 Gb/s and
      cost 50 is reported, the Orchestrator's PCE will fail to compute
      a 5 Gb/s path between routers R1 and R2, although this would be
      feasible;

   o  If only the VP1-VP4 path with available bandwidth of 10 Gb/s and
      cost 60 is reported, the Orchestrator's PCE will compute, as
      optimal, the 1 Gb/s path between R1 and R2 going through the VP2-
      VP5 path within the Optical domain while the optimal path would
      actually be the one going thought the VP1-VP4 sub-path (with cost
      50) within the Optical domain.

   Instead, using the approach proposed in this document, the
   Orchestrator, when it needs to setup an end-to-end path, it can
   request the Optical domain controller to compute a set of optimal
   paths (e.g., for VP1-VP4 and VP2-VP5) and take decisions based on
   the information received:

   o  When setting up a 5 Gb/s path between routers R1 and R2, the
      Optical domain controller may report only the VP1-VP4 path as the
      only feasible path: the Orchestrator can successfully setup the
      end-to-end path passing though this Optical path;

   o  When setting up a 1 Gb/s path between routers R1 and R2, the
      Optical domain controller (knowing that the path requires only 1
      Gb/s) can report both the VP1-VP4 path, with cost 50, and the
      VP2-VP5 path, with cost 65. The Orchestrator can then compute the
      optimal path which is passing thought the VP1-VP4 sub-path (with
      cost 50) within the Optical domain.

3.2. TE Topology Abstraction

   Using the TE Topology model, as defined in [TE-TOPO], the underlying
   SDN controller can export an abstract TE Topology, composed by a set
   of TE nodes and TE links, which are abstracting the topology
   controlled by each domain controller.

   Considering the example in Figure 4, the TE domain controller 1 can
   export a TE Topology encompassing the TE nodes A, B, C and D and the
   TE Link interconnecting them. In a similar way, TE domain controller
   2 can export a TE Topology encompassing the TE nodes E, F, G and H
   and the TE Link interconnecting them.

   In this example, for simplicity reasons, each abstract TE node maps
   with each physical node, but this is not necessary.


Busi, Belotti, et al.    Expires May 15, 2017                 [Page 14]


Internet-DraftYang model for requesting Path Computation  November 2016


   In order to setup a multi-domain TE path (e.g., between nodes A and
   H), the Orchestrator can compute by its own an optimal end-to-end
   path based on the abstract TE topology information provided by the
   domain controllers. For example:

   o  Orchestrator's PCE, based on its own information, can compute the
      optimal multi-domain path being A-B-C-E-G-H, and then request the
      TE domain controllers to setup the A-B-C and E-G-H intra-domain
      paths

   o  But, during path setup, the domain controller may find out that
      A-B-C intra-domain path is not feasible (as discussed in section
      2.2, in optical networks it is typical to have some paths not
      being feasible due to optical constraints that are known only by
      the optical domain controller), while only the path A-B-D is
      feasible

   o  So what the hierarchical controller computed is not good and need
      to re-start the path computation from scratch

  As discussed in section 3.1, providing more extensive abstract
  information from the TE domain controllers to the multi-domain
  Orchestator may lead to scalability problems.

  In a sense this is similar to the problem of routing and wavelength
  assignment within an Optical domain. It is possible to do first
  routing (step 1) and then wavelength assignment (step 2), but the
  chances of ending up with a good path is low. Alternatively, it is
  possible to do combined routing and wavelength assignment, which is
  known to be a more optimal and effective way for Optical path setup.
  Similarly, it is possible to first compute an abstract end-to-end
  path within the multi-domain Orchestrator (step 1) and then compute
  an intra-domain path within each Optical domain (step 2), but there
  are more chances not to find a path or to get a suboptimal path that
  performing per-domain path computation and then stitch them.

3.3. Complementary use of TE topology and path computation

   As discussed in section 2.2, there are some scalability issues with
   path computation requests in a multi-domain TE network with many TE
   domains, in terms of the number of requests to send to the TE domain
   controllers. It would therefore be worthwhile using the TE topology
   information provided by the domain controllers to limit the number
   of requests.



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 15]


Internet-DraftYang model for requesting Path Computation  November 2016


   An example can be described considering the multi-domain abstract
   topology shown in Figure 7. In this example, an end-to-end TE path
   between domains A and F needs to be setup. The transit domain should
   be selected between domains B, C, D and E.


      --------------------------------------------------------------------
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                Multi-domain with many domains                    I
      I                      (Topology information)                      I
      I                                                                  I
      I                                                                  I
      I                     (only in PDF version)                        I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      --------------------------------------------------------------------


     Figure 7 - Multi-domain with many domains (Topology information)

   The actual cost of each intra-domain path is not known a priori from
   the abstract topology information. The Orchestrator only knows, from
   the TE topology provided by the underlying domain controllers, the
   feasibility of some intra-domain paths and some upper-bound and/or
   lower-bound cost information. With this information, together with
   the cost of inter-domain links, the Orchestrator can understand by
   its own that:

   o  Domain B cannot be selected as the path connecting domains A and
      E is not feasible;

   o  Domain E cannot be selected as a transit domain since it is know
      from the abstract topology information provided by domain
      controllers that the cost of the multi-domain path A-E-F (which
      is 100, in the best case) will be always be higher than the cost
      of the multi-domain paths A-D-F (which is 90, in the worst case)
      and A-E-F (which is 80, in the worst case)

   Therefore, the Orchestrator can understand by its own that the
   optimal multi-domain path could be either A-D-F or A-E-F but it




Busi, Belotti, et al.    Expires May 15, 2017                 [Page 16]


Internet-DraftYang model for requesting Path Computation  November 2016


   cannot known which one of the two possible option actually provides
   the optimal end-to-end path.

   The Orchestrator can therefore request path computation only to the
   TE domain controllers A, D, E and F (and not to all the possible TE
   domain controllers).


      --------------------------------------------------------------------
      I                                                                  I
      I                                                                  I
      I                                                                  I
      I                Multi-domain with many domains                    I
      I                (Path Computation information)                    I
      I                                                                  I
      I                                                                  I
      I                     (only in PDF version)                        I
      I                                                                  I
      I                                                                  I
      I                                                                  I
      --------------------------------------------------------------------


      Figure 8 - Multi-domain with many domains (Path Computation
                              information)

   Based on these requests, the Orchestrator can know the actual cost
   of each intra-domain paths which belongs to potential optimal end-
   to-end paths, as shown in Figure 8, and then compute the optimal
   end-to-end path (e.g., A-D-F, having total cost of 50, instead of A-
   C-F having a total cost of 70).

4. Motivation for a YANG Model

4.1. Benefits of common data models

   Path computation requests should be closely aligned with the YANG
   data models that provide (abstract) TE topology information, i.e.,
   [TE-TOPO] as well as that are used to configure and manage TE
   Tunnels, i.e., [TE-TUNNEL]. Otherwise, an error-prone mapping or
   correlation of information would be required. For instance, there is
   benefit in using the same endpoint identifiers in path computation
   requests and in the topology modeling. Also, the attributes used in
   path computation constraints could use the same or similar data



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 17]


Internet-DraftYang model for requesting Path Computation  November 2016


   models. As a result, there are many benefits in aligning path
   computation requests with YANG models for TE topology information
   and TE Tunnels configuration and management.

4.2. Benefits of a single interface

   A typical use case for path computation requests is the interface
   between an orchestrator and a domain controller. The system
   integration effort is typically lower if a single, consistent
   interface is used between such systems, i.e., one data modeling
   language (i.e., YANG) and a common protocol (e.g., NETCONF or
   RESTCONF).

   Practical benefits of using a single, consistent interface include:

     1. Simple authentication and authorization: The interface between
        different components has to be secured. If different protocols
        have different security mechanisms, ensuring a common access
        control model may result in overhead. For instance, there may
        be a need to deal with different security mechanisms, e.g.,
        different credentials or keys. This can result in increased
        integration effort.
     2. Consistency: Keeping data consistent over multiple different
        interfaces or protocols is not trivial. For instance, the
        sequence of actions can matter in certain use cases, or
        transaction semantics could be desired. While ensuring
        consistency within one protocol can already be challenging, it
        is typically cumbersome to achieve that across different
        protocols.
     3. Testing: System integration requires comprehensive testing,
        including corner cases. The more different technologies are
        involved, the more difficult it is to run comprehensive test
        cases and ensure proper integration.
     4. Middle-box friendliness: Provider and consumer of path
        computation requests may be located in different networks, and
        middle-boxes such as firewalls, NATs, or load balancers may be
        deployed. In such environments it is simpler to deploy a single
        protocol. Also, it may be easier to debug connectivity
        problems.
     5. Tooling reuse: Implementers may want to implement path
        computation requests with tools and libraries that already
        exist in controllers and/or orchestrators, e.g., leveraging the
        rapidly growing eco-system for YANG tooling.




Busi, Belotti, et al.    Expires May 15, 2017                 [Page 18]


Internet-DraftYang model for requesting Path Computation  November 2016


4.3. Extensibility

   Path computation is only a subset of the typical functionality of a
   controller. In many use cases, issuing path computation requests
   comes along with the need to access other functionality on the same
   system. In addition to obtaining TE topology, for instance also
   configuration of services (setup/modification/deletion) may be
   required, as well as:

     1. Receiving notifications for topology changes as well as
        integration with fault management
     2. Performance management such as retrieving monitoring and
        telemetry data
     3. Service assurance, e.g., by triggering OAM functionality
     4. Other fulfilment and provisioning actions beyond tunnels and
        services, such as changing QoS configurations

   YANG is a very extensible and flexible data modeling language that
   can be used for all these use cases.

   Adding support for path computation requests to YANG models would
   seamlessly complement with [TE-TOPO] and [TE-TUNNEL] in the use
   cases where YANG-based protocols (e.g., NETCONF or RESTCONF) are
   used.

5. Path Optimization Request

   This is for further study

6. YANG Model for requesting Path Computation

   Work on extending the TE Tunnel YANG model to support the need to
   request path computation has recently started also in the context of
   the [TE-TUNNEL] draft.

   It is possible to request path computation by configuring a
   "compute-only" TE tunnel and retrieving the computed path(s) in the
   LSP(s) Record-Route Object (RRO) list as described in [TE-TUNNEL].

   This is a stateful solution since the state of each created
   "compute-only" TE tunnel needs to be maintained and updated, when
   underlying network conditions change.





Busi, Belotti, et al.    Expires May 15, 2017                 [Page 19]


Internet-DraftYang model for requesting Path Computation  November 2016


   The need also for a stateless solution, based on an RPC, has been
   recognized: section 6.1 describes an initial proposal for a
   stateless RPC to request path computation.

   This is intended as an input for further evaluation and discussion
   with the authors of [TE-TUNNEL] Internet-Draft and TEAS WG
   participants, about the technical solution as well as whether this
   RPC should be merged with the YANG model defined in [TE-TUNNEL].

6.1. YANG model for stateless TE path computation

6.1.1. YANG Tree

   Figure 9 below shows the tree diagram of the YANG model defined in
   module ietf-te-path-computation.yang.

   module: ietf-te-path-computation
       +--ro path* [path-id]
       |  +--ro _telink* [link-ref]
       |  |  +--ro link-ref       -> /nd:networks/network[nd:network-
   id=current()/../network-ref]/lnk:link/link-id
       |  |  +--ro network-ref?   -> /nd:networks/network/network-id
       |  +--ro _routingConstraint
       |  |  +--ro requestedCapacity?   decimal64
       |  |  +--ro pathConstraints
       |  |  |  +--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


Busi, Belotti, et al.    Expires May 15, 2017                 [Page 20]


Internet-DraftYang model for requesting Path Computation  November 2016


       |  |  |     |              +--ro affinity-names* [name]
       |  |  |     |                 +--ro name    string
       |  |  |     +--ro path-srlgs
       |  |  |        +--ro (style)?
       |  |  |           +--:(values)
       |  |  |           |  +--ro usage?         identityref
       |  |  |           |  +--ro values*        te-types:srlg
       |  |  |           +--:(named)
       |  |  |              +--ro constraints* [usage]
       |  |  |                 +--ro usage         identityref
       |  |  |                 +--ro constraint
       |  |  |                    +--ro srlg-names* [name]
       |  |  |                       +--ro name    string
       |  |  +--ro _avoidTopology
       |  |     +--ro provider-ref?      ->
   /nw:networks/network[nw:network-id = current()/../network-
   ref]/tet:provider-id
       |  |     +--ro client-ref?        ->
   /nw:networks/network[nw:network-id = current()/../network-
   ref]/tet:client-id
       |  |     +--ro te-topology-ref?   ->
   /nw:networks/network[nw:network-id = current()/../network-
   ref]/tet:te-topology-id
       |  |     +--ro network-ref?       ->
   /nw:networks/network/network-id
       |  +--ro path-id               yang-types:uuid
       +--rw pathComputationService
          +--ro _path-ref*                 -> /path/path-id
          +--rw _servicePort
          |  +--ro src-tp-ref
          |  |  +--ro tp-ref?        ->
   /nd:networks/network[nd:network-id=current()/../network-
   ref]/node[nd:node-id=current()/../node-ref]/lnk:termination-
   point/tp-id
          |  |  +--ro node-ref?      ->
   /nd:networks/network[nd:network-id=current()/../network-
   ref]/node/node-id
          |  |  +--ro network-ref?   -> /nd:networks/network/network-id
          |  +--ro dst-tp-ref



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 21]


Internet-DraftYang model for requesting Path Computation  November 2016


          |  |  +--ro tp-ref?        ->
   /nd:networks/network[nd:network-id=current()/../network-
   ref]/node[nd:node-id=current()/../node-ref]/lnk:termination-
   point/tp-id
          |  |  +--ro node-ref?      ->
   /nd:networks/network[nd:network-id=current()/../network-
   ref]/node/node-id
          |  |  +--ro network-ref?   -> /nd:networks/network/network-id
          |  +--ro serviceLayer
          |     +--ro switching-capability?      identityref
          |     +--ro encoding?                  identityref
          |     +--ro inter-layer-lock-id?       uint32
          |     +--ro protection-type?           identityref
          |     +--ro local-link-connectivity* [link-tp-ref]
          |        +--ro link-tp-ref                ->
   ../../../../../nt:termination-point/tp-id
          |        +--ro label-restriction* [inclusive-exclusive label-
   start]
          |        |  +--ro inclusive-exclusive    enumeration
          |        |  +--ro label-start            te-
   types:generalized-label
          |        |  +--ro label-end?             te-
   types:generalized-label
          |        |  +--ro range-bitmap?          binary
          |        +--ro max-lsp-bandwidth* [priority]
          |        |  +--ro priority     uint8
          |        |  +--ro bandwidth?   te-bandwidth
          |        +--ro max-link-bandwidth?        te-bandwidth
          |        +--ro max-resv-link-bandwidth?   te-bandwidth
          |        +--ro unreserved-bandwidth* [priority]
          |        |  +--ro priority     uint8
          |        |  +--ro bandwidth?   te-bandwidth
          |        +--ro te-default-metric?         uint32
          |        +--ro te-delay-metric?           uint32
          |        +--ro te-srlgs
          |           +--ro value*   te-types:srlg
          +--rw _routingConstraint
          |  +--ro requestedCapacity?   decimal64
          |  +--ro pathConstraints



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 22]


Internet-DraftYang model for requesting Path Computation  November 2016


          |  |  +--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
          |  |     +--ro path-srlgs
          |  |        +--ro (style)?
          |  |           +--:(values)
          |  |           |  +--ro usage?         identityref
          |  |           |  +--ro values*        te-types:srlg
          |  |           +--:(named)
          |  |              +--ro constraints* [usage]
          |  |                 +--ro usage         identityref
          |  |                 +--ro constraint
          |  |                    +--ro srlg-names* [name]
          |  |                       +--ro name    string
          |  +--ro _avoidTopology
          |     +--ro provider-ref?      ->
   /nw:networks/network[nw:network-id = current()/../network-
   ref]/tet:provider-id
          |     +--ro client-ref?        ->
   /nw:networks/network[nw:network-id = current()/../network-
   ref]/tet:client-id
          |     +--ro te-topology-ref?   ->
   /nw:networks/network[nw:network-id = current()/../network-
   ref]/tet:te-topology-id



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 23]


Internet-DraftYang model for requesting Path Computation  November 2016


          |     +--ro network-ref?       ->
   /nw:networks/network/network-id
          +--rw _objectiveFunction
          |  +--ro objectiveFunction?   ObjectiveFunction
          +--rw _optimizationConstraint
             +--ro trafficInterruption?   DirectiveValue

     rpcs:
       +---x statelessComputeP2PPath
       |  +---w input
       |  |  +---w servicePort*
       |  |  |  +---w src-tp-ref
       |  |  |  |  +---w tp-ref?        ->
   /nd:networks/network[nd:network-id=current()/../network-
   ref]/node[nd:node-id=current()/../node-ref]/lnk:termination-
   point/tp-id
       |  |  |  |  +---w node-ref?      ->
   /nd:networks/network[nd:network-id=current()/../network-
   ref]/node/node-id
       |  |  |  |  +---w network-ref?   ->
   /nd:networks/network/network-id
       |  |  |  +---w dst-tp-ref
       |  |  |  |  +---w tp-ref?        ->
   /nd:networks/network[nd:network-id=current()/../network-
   ref]/node[nd:node-id=current()/../node-ref]/lnk:termination-
   point/tp-id
       |  |  |  |  +---w node-ref?      ->
   /nd:networks/network[nd:network-id=current()/../network-
   ref]/node/node-id
       |  |  |  |  +---w network-ref?   ->
   /nd:networks/network/network-id
       |  |  |  +---w serviceLayer
       |  |  |     +---w switching-capability?      identityref
       |  |  |     +---w encoding?                  identityref
       |  |  |     +---w inter-layer-lock-id?       uint32
       |  |  |     +---w protection-type?           identityref
       |  |  |     +---w local-link-connectivity* [link-tp-ref]
       |  |  |        +---w link-tp-ref                ->
   ../../../../../nt:termination-point/tp-id



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 24]


Internet-DraftYang model for requesting Path Computation  November 2016


       |  |  |        +---w label-restriction* [inclusive-exclusive
   label-start]
       |  |  |        |  +---w inclusive-exclusive    enumeration
       |  |  |        |  +---w label-start            te-
   types:generalized-label
       |  |  |        |  +---w label-end?             te-
   types:generalized-label
       |  |  |        |  +---w range-bitmap?          binary
       |  |  |        +---w max-lsp-bandwidth* [priority]
       |  |  |        |  +---w priority     uint8
       |  |  |        |  +---w bandwidth?   te-bandwidth
       |  |  |        +---w max-link-bandwidth?        te-bandwidth
       |  |  |        +---w max-resv-link-bandwidth?   te-bandwidth
       |  |  |        +---w unreserved-bandwidth* [priority]
       |  |  |        |  +---w priority     uint8
       |  |  |        |  +---w bandwidth?   te-bandwidth
       |  |  |        +---w te-default-metric?         uint32
       |  |  |        +---w te-delay-metric?           uint32
       |  |  |        +---w te-srlgs
       |  |  |           +---w value*   te-types:srlg
       |  |  +---w routingConstraint
       |  |  |  +---w requestedCapacity?   decimal64
       |  |  |  +---w pathConstraints
       |  |  |  |  +---w path-constraints
       |  |  |  |     +---w topology-id?       te-types:te-topology-id
       |  |  |  |     +---w cost-limit?        uint32
       |  |  |  |     +---w hop-limit?         uint8
       |  |  |  |     +---w metric-type?       identityref
       |  |  |  |     +---w tiebreaker-type?   identityref
       |  |  |  |     +---w ignore-overload?   boolean
       |  |  |  |     +---w path-affinities {named-path-affinities}?
       |  |  |  |     |  +---w (style)?
       |  |  |  |     |     +--:(values)
       |  |  |  |     |     |  +---w value?         uint32
       |  |  |  |     |     |  +---w mask?          uint32
       |  |  |  |     |     +--:(named)
       |  |  |  |     |        +---w constraints* [usage]
       |  |  |  |     |           +---w usage         identityref
       |  |  |  |     |           +---w constraint



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 25]


Internet-DraftYang model for requesting Path Computation  November 2016


       |  |  |  |     |              +---w affinity-names* [name]
       |  |  |  |     |                 +---w name    string
       |  |  |  |     +---w path-srlgs
       |  |  |  |        +---w (style)?
       |  |  |  |           +--:(values)
       |  |  |  |           |  +---w usage?         identityref
       |  |  |  |           |  +---w values*        te-types:srlg
       |  |  |  |           +--:(named)
       |  |  |  |              +---w constraints* [usage]
       |  |  |  |                 +---w usage         identityref
       |  |  |  |                 +---w constraint
       |  |  |  |                    +---w srlg-names* [name]
       |  |  |  |                       +---w name    string
       |  |  |  +---w _avoidTopology
       |  |  |     +---w provider-ref?      ->
   /nw:networks/network[nw:network-id = current()/../network-
   ref]/tet:provider-id
       |  |  |     +---w client-ref?        ->
   /nw:networks/network[nw:network-id = current()/../network-
   ref]/tet:client-id
       |  |  |     +---w te-topology-ref?   ->
   /nw:networks/network[nw:network-id = current()/../network-
   ref]/tet:te-topology-id
       |  |  |     +---w network-ref?       ->
   /nw:networks/network/network-id
       |  |  +---w objectiveFunction
       |  |     +---w objectiveFunction?   ObjectiveFunction
       |  +--ro output
       |     +--ro pathCompService
       |        +--ro _path-ref*                 -> /path/path-id
       |        +--ro _servicePort
       |        |  +--ro src-tp-ref
       |        |  |  +--ro tp-ref?        ->
   /nd:networks/network[nd:network-id=current()/../network-
   ref]/node[nd:node-id=current()/../node-ref]/lnk:termination-
   point/tp-id
       |        |  |  +--ro node-ref?      ->
   /nd:networks/network[nd:network-id=current()/../network-
   ref]/node/node-id



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 26]


Internet-DraftYang model for requesting Path Computation  November 2016


       |        |  |  +--ro network-ref?   ->
   /nd:networks/network/network-id
       |        |  +--ro dst-tp-ref
       |        |  |  +--ro tp-ref?        ->
   /nd:networks/network[nd:network-id=current()/../network-
   ref]/node[nd:node-id=current()/../node-ref]/lnk:termination-
   point/tp-id
       |        |  |  +--ro node-ref?      ->
   /nd:networks/network[nd:network-id=current()/../network-
   ref]/node/node-id
       |        |  |  +--ro network-ref?   ->
   /nd:networks/network/network-id
       |        |  +--ro serviceLayer
       |        |     +--ro switching-capability?      identityref
       |        |     +--ro encoding?                  identityref
       |        |     +--ro inter-layer-lock-id?       uint32
       |        |     +--ro protection-type?           identityref
       |        |     +--ro local-link-connectivity* [link-tp-ref]
       |        |        +--ro link-tp-ref                ->
   ../../../../../nt:termination-point/tp-id
       |        |        +--ro label-restriction* [inclusive-exclusive
   label-start]
       |        |        |  +--ro inclusive-exclusive    enumeration
       |        |        |  +--ro label-start            te-
   types:generalized-label
       |        |        |  +--ro label-end?             te-
   types:generalized-label
       |        |        |  +--ro range-bitmap?          binary
       |        |        +--ro max-lsp-bandwidth* [priority]
       |        |        |  +--ro priority     uint8
       |        |        |  +--ro bandwidth?   te-bandwidth
       |        |        +--ro max-link-bandwidth?        te-bandwidth
       |        |        +--ro max-resv-link-bandwidth?   te-bandwidth
       |        |        +--ro unreserved-bandwidth* [priority]
       |        |        |  +--ro priority     uint8
       |        |        |  +--ro bandwidth?   te-bandwidth
       |        |        +--ro te-default-metric?         uint32
       |        |        +--ro te-delay-metric?           uint32
       |        |        +--ro te-srlgs



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 27]


Internet-DraftYang model for requesting Path Computation  November 2016


       |        |           +--ro value*   te-types:srlg
       |        +--ro _routingConstraint
       |        |  +--ro requestedCapacity?   decimal64
       |        |  +--ro pathConstraints
       |        |  |  +--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
       |        |  |     +--ro path-srlgs
       |        |  |        +--ro (style)?
       |        |  |           +--:(values)
       |        |  |           |  +--ro usage?         identityref
       |        |  |           |  +--ro values*        te-types:srlg
       |        |  |           +--:(named)
       |        |  |              +--ro constraints* [usage]
       |        |  |                 +--ro usage         identityref
       |        |  |                 +--ro constraint
       |        |  |                    +--ro srlg-names* [name]
       |        |  |                       +--ro name    string
       |        |  +--ro _avoidTopology
       |        |     +--ro provider-ref?      ->
   /nw:networks/network[nw:network-id = current()/../network-
   ref]/tet:provider-id




Busi, Belotti, et al.    Expires May 15, 2017                 [Page 28]


Internet-DraftYang model for requesting Path Computation  November 2016


       |        |     +--ro client-ref?        ->
   /nw:networks/network[nw:network-id = current()/../network-
   ref]/tet:client-id
       |        |     +--ro te-topology-ref?   ->
   /nw:networks/network[nw:network-id = current()/../network-
   ref]/tet:te-topology-id
       |        |     +--ro network-ref?       ->
   /nw:networks/network/network-id
       |        +--ro _objectiveFunction
       |        |  +--ro objectiveFunction?   ObjectiveFunction
       |        +--ro _optimizationConstraint
       |           +--ro trafficInterruption?   DirectiveValue
       +---x optimizeP2PPath
          +---w input
          |  +---w pathIdOrName?             string
          |  +---w routingConstraint
          |  |  +---w requestedCapacity?   decimal64
          |  |  +---w pathConstraints
          |  |  |  +---w path-constraints
          |  |  |     +---w topology-id?       te-types:te-topology-id
          |  |  |     +---w cost-limit?        uint32
          |  |  |     +---w hop-limit?         uint8
          |  |  |     +---w metric-type?       identityref
          |  |  |     +---w tiebreaker-type?   identityref
          |  |  |     +---w ignore-overload?   boolean
          |  |  |     +---w path-affinities {named-path-affinities}?
          |  |  |     |  +---w (style)?
          |  |  |     |     +--:(values)
          |  |  |     |     |  +---w value?         uint32
          |  |  |     |     |  +---w mask?          uint32
          |  |  |     |     +--:(named)
          |  |  |     |        +---w constraints* [usage]
          |  |  |     |           +---w usage         identityref
          |  |  |     |           +---w constraint
          |  |  |     |              +---w affinity-names* [name]
          |  |  |     |                 +---w name    string
          |  |  |     +---w path-srlgs
          |  |  |        +---w (style)?
          |  |  |           +--:(values)



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 29]


Internet-DraftYang model for requesting Path Computation  November 2016


          |  |  |           |  +---w usage?         identityref
          |  |  |           |  +---w values*        te-types:srlg
          |  |  |           +--:(named)
          |  |  |              +---w constraints* [usage]
          |  |  |                 +---w usage         identityref
          |  |  |                 +---w constraint
          |  |  |                    +---w srlg-names* [name]
          |  |  |                       +---w name    string
          |  |  +---w _avoidTopology
          |  |     +---w provider-ref?      ->
   /nw:networks/network[nw:network-id = current()/../network-
   ref]/tet:provider-id
          |  |     +---w client-ref?        ->
   /nw:networks/network[nw:network-id = current()/../network-
   ref]/tet:client-id
          |  |     +---w te-topology-ref?   ->
   /nw:networks/network[nw:network-id = current()/../network-
   ref]/tet:te-topology-id
          |  |     +---w network-ref?       ->
   /nw:networks/network/network-id
          |  +---w optimizationConstraint
          |  |  +---w trafficInterruption?   DirectiveValue
          |  +---w objectiveFunction
          |     +---w objectiveFunction?   ObjectiveFunction
          +--ro output
             +--ro pathCompService
                +--ro _path-ref*                 -> /path/path-id
                +--ro _servicePort
                |  +--ro src-tp-ref
                |  |  +--ro tp-ref?        ->
   /nd:networks/network[nd:network-id=current()/../network-
   ref]/node[nd:node-id=current()/../node-ref]/lnk:termination-
   point/tp-id
                |  |  +--ro node-ref?      ->
   /nd:networks/network[nd:network-id=current()/../network-
   ref]/node/node-id
                |  |  +--ro network-ref?   ->
   /nd:networks/network/network-id
                |  +--ro dst-tp-ref



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 30]


Internet-DraftYang model for requesting Path Computation  November 2016


                |  |  +--ro tp-ref?        ->
   /nd:networks/network[nd:network-id=current()/../network-
   ref]/node[nd:node-id=current()/../node-ref]/lnk:termination-
   point/tp-id
                |  |  +--ro node-ref?      ->
   /nd:networks/network[nd:network-id=current()/../network-
   ref]/node/node-id
                |  |  +--ro network-ref?   ->
   /nd:networks/network/network-id
                |  +--ro serviceLayer
                |     +--ro switching-capability?      identityref
                |     +--ro encoding?                  identityref
                |     +--ro inter-layer-lock-id?       uint32
                |     +--ro protection-type?           identityref
                |     +--ro local-link-connectivity* [link-tp-ref]
                |        +--ro link-tp-ref                ->
   ../../../../../nt:termination-point/tp-id
                |        +--ro label-restriction* [inclusive-exclusive
   label-start]
                |        |  +--ro inclusive-exclusive    enumeration
                |        |  +--ro label-start            te-
   types:generalized-label
                |        |  +--ro label-end?             te-
   types:generalized-label
                |        |  +--ro range-bitmap?          binary
                |        +--ro max-lsp-bandwidth* [priority]
                |        |  +--ro priority     uint8
                |        |  +--ro bandwidth?   te-bandwidth
                |        +--ro max-link-bandwidth?        te-bandwidth
                |        +--ro max-resv-link-bandwidth?   te-bandwidth
                |        +--ro unreserved-bandwidth* [priority]
                |        |  +--ro priority     uint8
                |        |  +--ro bandwidth?   te-bandwidth
                |        +--ro te-default-metric?         uint32
                |        +--ro te-delay-metric?           uint32
                |        +--ro te-srlgs
                |           +--ro value*   te-types:srlg
                +--ro _routingConstraint
                |  +--ro requestedCapacity?   decimal64



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 31]


Internet-DraftYang model for requesting Path Computation  November 2016


                |  +--ro pathConstraints
                |  |  +--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
                |  |     +--ro path-srlgs
                |  |        +--ro (style)?
                |  |           +--:(values)
                |  |           |  +--ro usage?         identityref
                |  |           |  +--ro values*        te-types:srlg
                |  |           +--:(named)
                |  |              +--ro constraints* [usage]
                |  |                 +--ro usage         identityref
                |  |                 +--ro constraint
                |  |                    +--ro srlg-names* [name]
                |  |                       +--ro name    string
                |  +--ro _avoidTopology
                |     +--ro provider-ref?      ->
   /nw:networks/network[nw:network-id = current()/../network-
   ref]/tet:provider-id
                |     +--ro client-ref?        ->
   /nw:networks/network[nw:network-id = current()/../network-
   ref]/tet:client-id




Busi, Belotti, et al.    Expires May 15, 2017                 [Page 32]


Internet-DraftYang model for requesting Path Computation  November 2016


                |     +--ro te-topology-ref?   ->
   /nw:networks/network[nw:network-id = current()/../network-
   ref]/tet:te-topology-id
                |     +--ro network-ref?       ->
   /nw:networks/network/network-id
                +--ro _objectiveFunction
                |  +--ro objectiveFunction?   ObjectiveFunction
                +--ro _optimizationConstraint
                   +--ro trafficInterruption?   DirectiveValue

                  Figure 9 - TE path computation tree

6.1.2. YANG Module



   <CODE BEGINS>file " ietf-te-path-computation.yang "
   module ietf-te-path-computation {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-te-path-computation";
     // replace with IANA namespace when assigned

     prefix "tepc";

     import ietf-yang-types {
       prefix "yang-types";
     }

     import ietf-te-types {
       prefix "te-types";
     }

     import ietf-te-topology {
       prefix "tet";
     }

     import ietf-network-topology {
       prefix "nt";
     }



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 33]


Internet-DraftYang model for requesting Path Computation  November 2016


     organization
       "Traffic Engineering Architecture and Signaling (TEAS)
        Working Group";

     contact
       "WG Web:   <http://tools.ietf.org/wg/teas/>
        WG List:  <mailto:teas@ietf.org>

        WG Chair: Lou Berger
                  <mailto:lberger@labn.net>

        WG Chair: Vishnu Pavan Beeram
                  <mailto:vbeeram@juniper.net>

      ";

     description "YANG model for stateless TE path computation";

     revision "2016-10-10" {
       description "Initial revision";
       reference "YANG model for stateless TE path computation";
     }

     /*
      * Features
      */

     feature stateless-path-computation {
       description
         "This feature indicates that the system supports
          stateless path computation.";
     }

     /*
      * Typedefs
      */

     typedef DirectiveValue {
       type enumeration {



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 34]


Internet-DraftYang model for requesting Path Computation  November 2016


         enum MINIMIZE {
           description "Minimize directive.";
         }
         enum MAXIMIZE {
           description "Maximize directive.";
         }
         enum ALLOW {
           description "Allow directive.";
         }
         enum DISALLOW {
           description "Disallow directive.";
         }
         enum DONT_CARE {
           description "Don't care directive.";
         }
       }
       description "Value to determine optimization type.";
     }

     typedef ObjectiveFunction {
       type enumeration {
         enum MCP {
           description "MCP.";
         }
         enum MLP  {
           description "MLP.";
         }
         enum MBP  {
           description "MBP.";
         }
         enum MBC  {
           description "MBC.";
         }
         enum MLL  {
           description "MLL.";
         }
         enum MCC  {
           description "MCC.";
         }



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 35]


Internet-DraftYang model for requesting Path Computation  November 2016


       }
       description "RFC 5541 - Encoding of Objective Functions in the
         Path Computation Element Communication Protocol (PCEP)";
     }

     /*
      * Groupings
      */

     grouping Path {
       list _telink {
         key 'link-ref';
         config false;
         uses nt:link-ref;
         description "List of telink refs.";
       }
       container _routingConstraint {
         config false;
         uses RoutingConstraint;
         description "Extended routing constraints.";
       }
       leaf path-id {
         type yang-types:uuid;
         config false;
         description "path-id ref.";
       }
       description "Path is described by an ordered list of TE Links.";
     }

     grouping PathCompServicePort {
       container src-tp-ref {
         uses nt:tp-ref;
         config false;
         description "Source termination point reference.";
       }
       container dst-tp-ref {
         uses nt:tp-ref;
         config false;
         description "Destination termination point reference.";



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 36]


Internet-DraftYang model for requesting Path Computation  November 2016


       }
       /**leaf direction {
         type PortDirection;
         config false;
         description "The orientation of defined flow.";
       }*/
       container serviceLayer {
         uses tet:te-node-tunnel-termination-attributes;
         config false;
         description "Service Layer.";
       }
       description "Path Computation Service Port grouping.";
     }

     grouping PathComputationService {
       leaf-list _path-ref {
         type leafref {
           path '/path/path-id';
         }
         config false;
         description "List of previously computed path references.";
       }
       container _servicePort {
         uses PathCompServicePort;
         description "Path Computation Service Port.";
       }
       container _routingConstraint {
         uses RoutingConstraint;
         description "Routing constraints.";
       }
       container _objectiveFunction {
         uses PathObjectiveFunction;
         description "Path Objective Function.";
       }
       container _optimizationConstraint {
         uses PathOptimizationConstraint;
         description "Path Optimization Constraint.";
       }
       description "Path computation service.";



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 37]


Internet-DraftYang model for requesting Path Computation  November 2016


     }

     grouping PathObjectiveFunction {
       leaf objectiveFunction {
         type ObjectiveFunction;
         config false;
         description "Objective Function.";
       }
       description "Path Objective Function.";
     }

     grouping PathOptimizationConstraint {
       leaf trafficInterruption {
         type DirectiveValue;
         config false;
         description "Traffic Interruption.";
       }
       description "Path Optimization Constraint.";
     }

     grouping RoutingConstraint {
       leaf requestedCapacity {
         type decimal64 {
           fraction-digits 2;
         }
         config false;
         description "Capacity required for connectivity service.";
       }
       container pathConstraints {
         config false;
         uses te-types:path-constraints;
         description "Service connectivity path selection properties";
       }
       // path-constaints contains include topology
     /*leaf _includeTopology {
         uses te-types:te-topology-ref;
         config false;
       }*/
       container _avoidTopology {



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 38]


Internet-DraftYang model for requesting Path Computation  November 2016


         uses tet:te-topology-ref;
         config false;
         description "Topology to be avoided.";
       }
       // path-constrains already include/exclude path
     /*list _includePath {
         key 'link-ref';
         config false;
         uses nt:link-ref;
       }*/
     /*list _excludePath {
         key 'link-ref';
         config false;
         uses nt:link-ref;
       }*/
       description "Extended routing constraints. Created to align with
   path-constaints.";
     }

     /*
      * Lists
      */
     list path {
       key "path-id";
       uses Path;
       config false;
       description "List of previous computed paths.";
     }

     container pathComputationService {
       uses PathComputationService;
       description "Service for computing paths.";
     }

     /***********************
     * package Interfaces
     **********************/
     rpc statelessComputeP2PPath {
       description "statelessComputeP2PPath";



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 39]


Internet-DraftYang model for requesting Path Computation  November 2016


       input {
         list servicePort {
           min-elements 2;
           max-elements 2;
           uses PathCompServicePort;
           description "List of service ports.";
         }
         container routingConstraint {
           uses RoutingConstraint;
           description "routing constraint.";
         }
         container objectiveFunction {
           uses PathObjectiveFunction;
           description "objective function.";
         }
       }
       output {
         container pathCompService {
             uses PathComputationService;
             description "Path computation service.";
         }
       }
     }

     /**rpc computeP2PPath {
       input {
         list servicePort {
           min-elements 2;
           max-elements 2;
           uses PathCompServicePort;
         }
         container routingConstraint {
           uses RoutingConstraint;
         }
         container objectiveFunction {
           uses PathObjectiveFunction;
         }
       }
       output {



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 40]


Internet-DraftYang model for requesting Path Computation  November 2016


         container pathCompService {
           uses PathComputationService;
         }
       }
     }*/

     rpc optimizeP2PPath {
       description "optimizeP2PPath.";
       input {
         leaf pathIdOrName {
           type string;
           description "path id or path name.";
         }
         container routingConstraint {
           uses RoutingConstraint;
           description "routing constraint.";
         }
         container optimizationConstraint {
           uses PathOptimizationConstraint;
           description "optimizationConstraint.";
         }
         container objectiveFunction {
           uses PathObjectiveFunction;
           description "objective function.";
         }
       }
       output {
         container pathCompService {
           uses PathComputationService;
           description "path computation service.";
         }
       }
     }

     /**rpc deleteP2PPath {
       input {
         leaf pathIdOrName {
           type string;
         }



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 41]


Internet-DraftYang model for requesting Path Computation  November 2016


       }
       output {
         container pathCompService {
           uses PathComputationService;
         }
       }
     }*/
   }
   <CODE ENDS>

              Figure 10 - TE path computation YANG module

7. Security Considerations

   This is for further study

8. IANA Considerations

   This document requires no IANA actions.

9. References

9.1. Normative References

   [RFC7926] Farrel, A. et al., "Problem Statement and Architecture for
             Information Exchange Between Interconnected Traffic
             Engineered Networks", RFC 7926, July 2016.

   [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies",
             draft-ietf-teas-yang-te-topo, work in progress.

   [TE-TUNNEL] Xhang, X. et al., "A YANG Data Model for Traffic
             Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
             te, work in progress.

9.2. Informative References

   [RFC7446] Lee, Y. et al., "Routing and Wavelength Assignment
             Information Model for Wavelength Switched Optical
             Networks", RFC 7446, February 2015.





Busi, Belotti, et al.    Expires May 15, 2017                 [Page 42]


Internet-DraftYang model for requesting Path Computation  November 2016


   [L1-TOPO] Zhang, X. et al., "A YANG Data Model for Layer 1 (ODU)
             Network Topology", draft-zhang-ccamp-l1-topo-yang, work in
             progress.

   [ACTN-Frame]   D, Ceccarelli and Y. Lee (editors), "Framework for
             Abstraction and Control of Transport Networks," draft-
             ceccarelli-actn-framework, work in progress.

   [ACTN-Info] Y. Lee and S. Belotti, D. Dhody and D. Ceccarelli,
             "Information Model for Abstraction and Control of
             Transport Networks", draft-leebelotti-actn-info, work in
             progress.

10. Acknowledgments

   The authors would like to thank Igor Bryskin and Xian Zhang for
   participating in discussions and providing valuable insights.

   This document was prepared using 2-Word-v2.0.template.dot.




























Busi, Belotti, et al.    Expires May 15, 2017                 [Page 43]


Internet-DraftYang model for requesting Path Computation  November 2016


Contributors

   Dieter Beller
   Nokia
   Email: dieter.beller@nokia.com


Authors' Addresses

   Italo Busi
   Huawei
   Email: italo.busi@huawei.com



   Sergio Belotti
   Nokia
   Email: sergio.belotti@nokia.com



   Victor Lopez
   Telefonica
   Email: victor.lopezalvarez@telefonica.com


   Oscar Gonzalez de Dios
   Telefonica
   Email: oscar.gonzalezdedios@telefonica.com


   Anurag Sharma
   Infinera
   Email: AnSharma@infinera.com


   Yan Shi
   China Unicom
   Email: shiyan49@chinaunicom.cn


   Ricard Vilalta
   CTTC
   Email: ricard.vilalta@cttc.es



Busi, Belotti, et al.    Expires May 15, 2017                 [Page 44]


Internet-DraftYang model for requesting Path Computation  November 2016


   Karthik Sethuraman
   NEC
   Email: karthik.sethuraman@necam.com


   Michael Scharf
   Nokia
   Email: michael.scharf@nokia.com


   Daniele Ceccarelli
   Ericsson
   Email: daniele.ceccarelli@ericsson.com


































Busi, Belotti, et al.    Expires May 15, 2017                 [Page 45]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/