TEAS Working Group Italo Busi (Ed.)
Internet Draft Huawei
Intended status: Standard Track Sergio Belotti (Ed.)
Expires: May 2020 Nokia
Victor Lopez
Oscar Gonzalez de Dios
Telefonica
Anurag Sharma
Google
Yan Shi
China Unicom
Ricard Vilalta
CTTC
Karthik Sethuraman
NEC
November 18, 2019
Yang model for requesting Path Computation
draft-ietf-teas-yang-path-computation-07.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
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Busi, Belotti, al. Expires May 18, 2020 [Page 1]
Internet-Draft Yang for Path Computation November 2019
This Internet-Draft will expire on May 18, 2020.
Copyright Notice
Copyright (c) 2019 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, where
the topology information provided by a TE network provider may not
be sufficient for its client to perform end-to-end path computation.
In these cases the client would need to request the provider to
calculate some (partial) feasible paths.
This document defines a YANG data model for a stateless RPC to
request path computation. This model complements the stateful
solution defined in [TE-TUNNEL].
Moreover this document describes some use cases where a path
computation request, via YANG-based protocols (e.g., NETCONF or
RESTCONF), can be needed.
Table of Contents
1. Introduction...................................................3
1.1. Terminology...............................................5
2. Use Cases......................................................5
2.1. Packet/Optical Integration................................5
2.2. Multi-domain TE Networks.................................10
2.3. Data center interconnections.............................12
2.4. Backward Recursive Path Computation scenario.............14
2.5. Hierarchical PCE scenario................................15
3. Motivations...................................................17
Busi, Belotti, et al. Expires May 18, 2020 [Page 2]
Internet-Draft Yang for Path Computation November 2019
3.1. Motivation for a YANG Model..............................17
3.1.1. Benefits of common data models......................17
3.1.2. Benefits of a single interface......................18
3.1.3. Extensibility.......................................19
3.2. Interactions with TE Topology............................19
3.2.1. TE Topology Aggregation.............................20
3.2.2. TE Topology Abstraction.............................23
3.2.3. Complementary use of TE topology and path computation24
3.3. Stateless and Stateful Path Computation..................27
3.3.1. Temporary reporting of the computed path state......29
4. Path Computation and Optimization for multiple paths..........31
5. YANG Model for requesting Path Computation....................32
5.1. Synchronization of multiple path computation requests....32
5.2. Returned metric values...................................34
5.3. Path Associations........................................36
6. YANG model for stateless TE path computation..................38
6.1. YANG Tree................................................38
6.2. YANG Module..............................................49
7. Security Considerations.......................................64
8. IANA Considerations...........................................64
9. References....................................................65
9.1. Normative References.....................................65
9.1. Informative References...................................66
10. Acknowledgments..............................................67
Appendix A. Examples of dimensioning the "detailed connectivity
matrix"...........................................68
Appendix B. New proposed YANG Tree overview...................74
1. Introduction
There are scenarios, typically in a hierarchical SDN context, where
the topology information provided by a TE network provider may not
be sufficient for its client to perform end-to-end path computation.
In these cases the client would need to request the provider to
calculate some (partial) feasible paths, complementing his topology
knowledge, to make his end-to-end path computation feasible.
This type of scenarios can be applied to different interfaces in
different reference architectures:
o ABNO control interface [RFC7491], in which an Application Service
Coordinator can request ABNO controller to take in charge path
calculation (see Figure 1 in [RFC7491]).
Busi, Belotti, et al. Expires May 18, 2020 [Page 3]
Internet-Draft Yang for Path Computation November 2019
o ACTN [RFC8453], where a 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). [RFC8454] 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
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. [OTN-TOPO] for OTN 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.
Note: This document assumes that the client of the YANG data model
defined in this document may not implement a "PCE" functionality, as
defined in [RFC4655].
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 proposes a YANG model for a path computation request
defined as a stateless RPC, which complements the stateful solution
defined in [TE-TUNNEL].
Moreover, this document describes some use cases where a path
computation request, via YANG-based protocols (e.g., NETCONF or
RESTCONF), can be needed.
Busi, Belotti, et al. Expires May 18, 2020 [Page 4]
Internet-Draft Yang for Path Computation November 2019
1.1. Terminology
TED: The traffic engineering database is a collection of all TE
information about all TE nodes and TE links in a given network.
PCE: A Path Computation Element (PCE) is an entity that is capable
of computing a network path or route based on a network graph, and
of applying computational constraints during the computation. The
PCE entity is an application that can be located within a network
node or component, on an out-of-network server, etc. For example, a
PCE would be able to compute the path of a TE LSP by operating on
the TED and considering bandwidth and other constraints applicable
to the TE LSP service request. [RFC4655]
2. Use Cases
This section presents some use cases, where a client needs to
request underlying SDN controllers for path computation.
The use of the YANG model defined in this document is not restricted
to these use cases but can be used in any other use case when deemed
useful.
The presented uses cases have been grouped, depending on the
different underlying topologies: a) Packet-Optical integration; b)
Multi-domain Traffic Engineered (TE) Networks; and c) Data center
interconnections. Use cases d) and e) respectively present how to
apply this Yang model for standard multi-domain PCE i.e. Backward
Recursive Path Computation [RFC5441] and Hierarchical PCE [RFC6805].
2.1. Packet/Optical Integration
In this use case, an Optical network is used to provide connectivity
to some nodes of a Packet network (see Figure 1).
Busi, Belotti, et al. Expires May 18, 2020 [Page 5]
Internet-Draft Yang for Path Computation November 2019
+----------------+
| |
| Packet/Optical |
| Coordinator |
| |
+---+------+-----+
| |
+------------+ |
| +-----------+
+------V-----+ |
| | +------V-----+
| Packet | | |
| Network | | Optical |
| Controller | | Network |
| | | Controller |
+------+-----+ +-------+----+
| |
.........V......................... |
: Packet Network : |
+----+ +----+ |
| R1 |= = = = = = = = = = = = = = = =| R2 | |
+-+--+ +--+-+ |
| : : | |
| :................................ : | |
| | |
| +-----+ | |
| ...........| Opt |........... | |
| : | C | : | |
| : /+--+--+\ : | |
| : / | \ : | |
| : / | \ : | |
| +-----+ / +--+--+ \ +-----+ | |
| | Opt |/ | Opt | \| Opt | | |
+---| A | | D | | B |---+ |
+-----+\ +--+--+ /+-----+ |
: \ | / : |
: \ | / : |
: \ +--+--+ / Optical<---------+
: \| Opt |/ Network:
:..........| E |..........:
+-----+
Figure 1 - Packet/Optical Integration Use Case
Busi, Belotti, et al. Expires May 18, 2020 [Page 6]
Internet-Draft Yang for Path Computation November 2019
Figure 1 as well as Figure 2 below only show a partial view of the
packet network connectivity, before additional packet connectivity
is provided by the Optical network.
It is assumed that the Optical network controller provides to the
packet/optical coordinator an abstracted view of the Optical
network. A possible abstraction could be to represent the whole
optical network as one "virtual node" with "virtual ports" connected
to the access links, as shown in Figure 2.
It is also assumed that Packet network controller can provide the
packet/optical coordinator the information it needs to setup
connectivity between packet nodes through the Optical network (e.g.,
the access links).
The path computation request helps the coordinator to know the real
connections that can be provided by the optical network.
Busi, Belotti, et al. Expires May 18, 2020 [Page 7]
Internet-Draft Yang for Path Computation November 2019
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,.
, Packet/Optical Coordinator view ,
, +----+ , .
, | | ,
, | R2 | , .
, +----+ +------------ + /+----+ ,
, | | | |/-----/ / / , .
, | R1 |--O VP1 VP4 O / / ,
, | |\ | | /----/ / , .
, +----+ \| |/ / ,
, / O VP2 VP5 O / , .
, / | | +----+ ,
, / | | | | , .
, / O VP3 VP6 O--| R4 | ,
, +----+ /-----/|_____________| +----+ , .
, | |/ +------------ + ,
, | R3 | , .
, +----+ ,,,,,,,,,,,,,,,,,
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,.
. Packet Network Controller view +----+ ,
only packet nodes and packet links | | , .
. with access links to the optical network | R2 | ,
, +----+ /+----+ , .
. , | | /-----/ / / ,
, | R1 |--- / / , .
. , +----+\ /----/ / ,
, / \ / / , .
. , / / ,
, / +----+ , .
. , / | | ,
, / ---| R4 | , .
. , +----+ /-----/ +----+ ,
, | |/ , .
. , | R3 | ,
, +----+ ,,,,,,,,,,,,,,,,,.
.,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,
Optical Network Controller view , .
. only optical nodes, +--+ ,
optical links and /|OF| , .
. access links from the +--++--+ / ,
packet network |OA| \ /-----/ / , .
. , ---+--+--\ +--+/ / ,
, \ | \ \-|OE|-------/ , .
. , \ | \ /-+--+ ,
, \+--+ X | , .
Busi, Belotti, et al. Expires May 18, 2020 [Page 8]
Internet-Draft Yang for Path Computation November 2019
. , |OB|-/ \ | ,
, +--+-\ \+--+ , .
. , / \ \--|OD|--- ,
, /-----/ +--+ +--+ , .
. , / |OC|/ ,
, +--+ , .
., ,,,,,,,,,,,,,,,,,,
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,
. Actual Physical View +----+ ,
, +--+ | | ,
. , /|OF| | R2 | ,
, +----+ +--++--+ /+----+ ,
. , | | |OA| \ /-----/ / / ,
, | R1 |---+--+--\ +--+/ / / ,
. , +----+\ | \ \-|OE|-------/ / ,
, / \ | \ /-+--+ / ,
. , / \+--+ X | / ,
, / |OB|-/ \ | +----+ ,
. , / +--+-\ \+--+ | | ,
, / / \ \--|OD|---| R4 | ,
. , +----+ /-----/ +--+ +--+ +----+ ,
, | |/ |OC|/ ,
. , | R3 | +--+ ,
, +----+ ,
.,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Figure 2 - Packet and Optical Topology Abstractions
In this use case, the coordinator needs to setup an optimal
underlying path for an IP link between R1 and R2.
As depicted in Figure 2, the coordinator 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 coordinator 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 which one
of these potential paths to use to setup the optimal end-to-end path
crossing optical network.
Busi, Belotti, et al. Expires May 18, 2020 [Page 9]
Internet-Draft Yang for Path Computation November 2019
............................
: :
O VP1 VP4 O
cost=10 /:\ /:\ cost=10
/ : \----------------------/ : \
+----+ / : cost=50 : \ +----+
| |/ : : \| |
| R1 | : : | R2 |
| |\ : : /| |
+----+ \ : /--------------------\ : / +----+
\ : / cost=55 \ : /
cost=5 \:/ \:/ cost=5
O VP2 VP5 O
: :
:..........................:
Figure 3 - Packet/Optical Path Computation Example
For example, in Figure 3, the Coordinator can request the Optical
network 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
network controller when requested by the Coordinator is no longer
valid/available when the Coordinator requests it to be setup up.
This is further discussed in section 3.3.
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.
Busi, Belotti, et al. Expires May 18, 2020 [Page 10]
Internet-Draft Yang for Path Computation November 2019
+--------------+
| Multi-domain |
| Controller |
+---+------+---+
| |
+------------+ |
| +-----------+
+------V-----+ |
| | |
| TE Domain | +------V-----+
| Controller | | |
| 1 | | TE Domain |
+------+-----+ | Controller |
| | 2 |
| +------+-----+
.........V.......... |
: : |
+-----+ : |
| | : .........V..........
| X | : : :
| | +-----+ +-----+ :
+-----+ | | | | :
: | C |------| E | :
+-----+ +-----+ /| | | |\ +-----+ +-----+
| | | |/ +-----+ +-----+ \| | | |
| A |----| B | : : | G |----| H |
| | | |\ : : /| | | |
+-----+ +-----+ \+-----+ +-----+/ +-----+ +-----+
: | | | | :
: | D |------| F | :
: | | | | +-----+
: +-----+ +-----+ | |
: : : | Y |
: : : | |
: Domain 1 : : Domain 2 +-----+
:..................: :.................:
Figure 4 - Multi-domain multi-link interconnection
In order to setup an end-to-end multi-domain TE path (e.g., between
nodes A and H), the multi-domain controller 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-
Busi, Belotti, et al. Expires May 18, 2020 [Page 11]
Internet-Draft Yang for Path Computation November 2019
specific optical attributes (which may be different in the two
domains if they are provided by different vendors).
In order to setup a multi-domain TE path (e.g., between nodes A and
H), the multi-domain controller 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 multi-domain controller 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 multi-domain controller 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 multi-domain controller
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 multi-domain controller)
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 TE domain controllers to limit the
number of potential optimal end-to-end paths and then request path
computation to fewer TE domain controllers in order to decide what
the optimal path within this limited set is.
For more details, see section 3.2.3.
2.3. Data center interconnections
In these use case, there is a 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 18, 2020 [Page 12]
Internet-Draft Yang for Path Computation November 2019
+--------------+
| Cloud Network|
| Orchestrator |
+--------------+
| | | |
+-------------+ | | +------------------------+
| | +------------------+ |
| +--------V---+ | |
| | | | |
| | TE Network | | |
+------V-----+ | Controller | +------V-----+ |
| DC | +------------+ | DC | |
| Controller | | | Controller | |
+------------+ | +-----+ +------------+ |
| ....V...| |........ | |
| : | P | : | |
.....V..... : /+-----+\ : .....V..... |
: : +-----+ / | \ +-----+ : : |
: DC1 || : | |/ | \| | : DC2 || : |
: ||||----| PE1 | | | PE2 |---- |||| : |
: _|||||| : | |\ | /| | : _|||||| : |
: : +-----+ \ +-----+ / +-----+ : : |
:.........: : \| |/ : :.........: |
:.......| PE3 |.......: |
| | |
+-----+ +---------V--+
.....|..... | DC |
: : | Controller |
: DC3 || : +------------+
: |||| : |
: _|||||| <------------------+
: :
:.........:
Figure 5 - Data Center Interconnection Use Case
In this use case, there is need to transfer data from Data Center 1
(DC1) to either DC2 or DC3 (e.g. workload migration).
The optimal decision depends both on the cost of the TE path (DC1-
DC2 or DC1-DC3) and of the data center resources within DC2 or DC3.
The cloud network orchestrator needs to make a decision for optimal
connection based on TE Network constraints and data centers
Busi, Belotti, et al. Expires May 18, 2020 [Page 13]
Internet-Draft Yang for Path Computation November 2019
resources. It 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 network orchestrator can request to the TE network
controller to compute the cost of the possible TE paths (e.g., DC1-
DC2 and DC1-DC3) and to the DC controller to provide the information
it needs about the required data center resources within DC2 and DC3
and then it can take the decision about the optimal solution based
on this information and its policy.
2.4. Backward Recursive Path Computation scenario
[RFC5441] has defined the Virtual Source Path Tree (VSPT) TLV within
PCE Reply Object in order to compute inter-domain paths following a
"Backward Recursive Path Computation" (BRPC) method. The main
principle is to forward the PCE request message up to the
destination domain. Then, each PCE involved in the computation will
compute its part of the path and send it back to the requester
through PCE Response message. The resulting computation is spread
from destination PCE to source PCE. Each PCE is in charge of merging
the path it received with the one it calculated. At the end, the
source PCE merges its local part of the path with the received one
to achieve the end-to-end path.
Figure 6 below show a typical BRPC scenario where 3 PCEs cooperate
to compute inter-domain paths.
Busi, Belotti, et al. Expires May 18, 2020 [Page 14]
Internet-Draft Yang for Path Computation November 2019
+----------------+ +----------------+
| Domain (B) | | Domain (C) |
| | | |
| /-------|---PCEP---|--------\ |
| / | | \ |
| (PCE) | | (PCE) |
| / <----------> |
| / | Inter | |
+---|----^-------+ Domain +----------------+
| | Link
PCEP |
| | Inter-domain Link
| |
+---|----v-------+
| | |
| | Domain (A) |
| \ |
| (PCE) |
| |
| |
+----------------+
Figure 6 - BRPC Scenario
In this use case, a client can use the YANG model defined in this
document to request path computation to the PCE that controls the
source of the tunnel. For example, a client can request to the PCE
of domain A to compute a path from a source S, within domain A, to a
destination D, within domain C. Then PCE of domain A will use PCEP
protocol, as per [RFC5441], to compute the path from S to D and in
turn gives the final answer to the requester.
2.5. Hierarchical PCE scenario
[RFC6805] has defined an architecture and extensions to the PCE
standard to compute inter-domain path following a hierarchical
method. Two new roles have been defined: Parent PCE and child PCE.
The parent PCE is in charge to coordinate the end-to-end path
computation. For that purpose it sends to each child PCE involve in
the multi-domain path computation a PCE Request message to obtain
the local part of the path. Once received all answer through PCE
Response message, the Parent PCE will merge the different local
parts of the path to achieve the end-to-end path.
Figure 7 below shows a typical hierarchical scenario where a Parent
PCE request end-to-end path to the different child PCE. Note that a
Busi, Belotti, et al. Expires May 18, 2020 [Page 15]
Internet-Draft Yang for Path Computation November 2019
PCE could take independently the role of Child or Parent PCE
depending of which PCE will request the path.
-----------------------------------------------------------------
| Domain 5 |
| ----- |
| |PCE 5| |
| ----- |
| |
| ---------------- ---------------- ---------------- |
| | Domain 1 | | Domain 2 | | Domain 3 | |
| | | | | | | |
| | ----- | | ----- | | ----- | |
| | |PCE 1| | | |PCE 2| | | |PCE 3| | |
| | ----- | | ----- | | ----- | |
| | | | | | | |
| | ----| |---- ----| |---- | |
| | |BN11+---+BN21| |BN23+---+BN31| | |
| | - ----| |---- ----| |---- - | |
| | |S| | | | | |D| | |
| | - ----| |---- ----| |---- - | |
| | |BN12+---+BN22| |BN24+---+BN32| | |
| | ----| |---- ----| |---- | |
| | | | | | | |
| | ---- | | | | ---- | |
| | |BN13| | | | | |BN33| | |
| -----------+---- ---------------- ----+----------- |
| \ / |
| \ ---------------- / |
| \ | | / |
| \ |---- ----| / |
| ----+BN41| |BN42+---- |
| |---- ----| |
| | | |
| | ----- | |
| | |PCE 4| | |
| | ----- | |
| | | |
| | Domain 4 | |
| ---------------- |
| |
-----------------------------------------------------------------
Figure 7 - Hierarchical domain topology from [RFC6805]
Busi, Belotti, et al. Expires May 18, 2020 [Page 16]
Internet-Draft Yang for Path Computation November 2019
In this use case, a client can use the YANG model defined in this
document to request to the Parent PCE a path from a source S to a
destination D. The Parent PCE will in turn contact the child PCEs
through PCEP protocol to compute the end-to-end path and then return
the computed path to the client, using the YANG model defined in
this document. For example the YANG model can be used to request to
PCE5 acting as Parent PCE to compute a path from source S, within
domain 1, to destination D, within domain 3. PCE5 will contact child
PCEs of domain 1, 2 and 3 to obtain local part of the end-to-end
path through the PCEP protocol. Once received the PCE Response
message, it merges the answers to compute the end-to-end path and
send it back to the client.
3. Motivations
This section provides the motivation for the YANG model defined in
this document.
Section 3.1 describes the motivation for a YANG model to request
path computation.
Section 3.2 describes the motivation for a YANG model which
complements the TE Topology YANG model defined in [TE-TOPO].
Section 3.3 describes the motivation for a stateless YANG RPC which
complements the TE Tunnel YANG model defined in [TE-TUNNEL].
3.1. Motivation for a YANG Model
3.1.1. Benefits of common data models
The YANG data model for requesting path computation is 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].
There are many benefits in aligning the data model used for path
computation requests with the YANG data models used for TE topology
information and for TE Tunnels configuration and management:
o There is no need for an error-prone mapping or correlation of
information.
o It is possible to use the same endpoint identifiers in path
computation requests and in the topology modeling.
Busi, Belotti, et al. Expires May 18, 2020 [Page 17]
Internet-Draft Yang for Path Computation November 2019
o The attributes used for path computation constraints are the same
as those used when setting up a TE Tunnel.
3.1.2. Benefits of a single interface
The system integration effort is typically lower if a single,
consistent interface is used by controllers, 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 18, 2020 [Page 18]
Internet-Draft Yang for Path Computation November 2019
3.1.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.
3.2. 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 its client thus allowing a PCE available within its
client to perform multi-domain path computation by its own, without
requesting path computations to the underlying SDN controllers.
In case the client does not implement a PCE function, as discussed
in section 1, it could not perform path computation based on TE
Topology information and would instead need to request path
computation to the underlying controllers to get the information it
needs to compute the optimal end-to-end path.
This section analyzes the need for a client to request underlying
SDN controllers for path computation even in case it implements a
Busi, Belotti, et al. Expires May 18, 2020 [Page 19]
Internet-Draft Yang for Path Computation November 2019
PCE functionality, 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 PCE, when implemented by the client, to
take optimal path computation decisions by its own versus sending
too many requests to underlying SDN Domain Controllers to compute a
set of feasible optimal intra-domain TE paths.
3.2.1. TE Topology Aggregation
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".
The concept of a "detailed connectivity matrix" is defined in [TE-
TOPO] to provide specific TE attributes (e.g., delay, SRLGs and
summary TE metrics) as an extension of the "basic connectivity
matrix", which is based on the "connectivity matrix" defined in
[RFC7446].
The information provided by the "detailed connectivity matrix" would
be equivalent to the information that should be provided by "virtual
link model" as defined in [RFC7926].
For example, in the Packet/Optical integration use case, described
in section 2.1, the Optical network controller can make the
information shown in Figure 3 available to the Coordinator as part
of the TE Topology information and the Coordinator could use this
information to calculate by its own the optimal path between R1 and
R2, without requesting any additional information to the Optical
network Controller.
However, when designing the amount of information to provide within
the "detailed connectivity matrix", there is a tradeoff to be
considered between accuracy (i.e., providing "all" the information
that might be needed by the PCE available to Orchestrator) and
scalability.
Figure 8 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).
Busi, Belotti, et al. Expires May 18, 2020 [Page 20]
Internet-Draft Yang for Path Computation November 2019
............................
: /--------------------\ :
: / cost=65 \ :
:/ available-bw=10G \:
O VP1 VP4 O
cost=10 /:\ /:\ cost=10
/ : \----------------------/ : \
+----+ / : cost=50 : \ +----+
| |/ : available-bw=2G : \| |
| R1 | : : | R2 |
| |\ : : /| |
+----+ \ : /--------------------\ : / +----+
\ : / cost=55 \ : /
cost=5 \:/ available-bw=3G \:/ cost=5
O VP2 VP5 O
: :
:..........................:
Figure 8 - Packet/Optical Path Computation Example with multiple
choices
Reporting all the information, as in Figure 8, using the "detailed
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.
Examples of how the "detailed connectivity matrix" can be
dimensioned are described in Appendix A.
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 "basic 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 connectivity constraints of an Optical domain can change over
Busi, Belotti, et al. Expires May 18, 2020 [Page 21]
Internet-Draft Yang for Path Computation November 2019
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 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 connectivity matrix" while not
changing the feasibility of the path.
The "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 "detailed
connectivity matrix" updated which means that there another tradeoff
between the accuracy (i.e., providing "all" the information that
might be needed by the client'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
client's PCE computes paths using not updated information.
It seems therefore quite challenging to have a "detailed
connectivity matrix" that provides accurate, scalable and updated
information to allow the client's PCE to take optimal decisions by
its own.
Instead, if the information in the "detailed connectivity matrix" is
not complete/accurate, we can have the following drawbacks
considering for example the case in Figure 8:
Busi, Belotti, et al. Expires May 18, 2020 [Page 22]
Internet-Draft Yang for Path Computation November 2019
o If only the VP1-VP4 path with available bandwidth of 2 Gb/s and
cost 50 is reported, the client'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 client'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.
Using the approach proposed in this document, the client, 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.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, representing the abstract view of 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 18, 2020 [Page 23]
Internet-Draft Yang for Path Computation November 2019
In order to setup a multi-domain TE path (e.g., between nodes A and
H), the multi-domain controller 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 Multi-domain controller'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 multi-domain controller computed is not good and need
to re-start the path computation from scratch
As discussed in section 3.2.1, providing more extensive abstract
information from the TE domain controllers to the multi-domain
controller 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.2.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 18, 2020 [Page 24]
Internet-Draft Yang for Path Computation November 2019
An example can be described considering the multi-domain abstract
topology shown in Figure 9. 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.
.........B.........
: _ _ _ _ _ _ _ _ :
:/ \:
+---O NOT FEASIBLE O---+
cost=5| : : |
......A...... | :.................: | ......F......
: : | | : :
: O-----+ .........C......... +-----O :
: : : /-------------\ : : :
: : :/ \: : :
: cost<=20 O---------O cost <= 30 O---------O cost<=20 :
: /: cost=5 : : cost=5 :\ :
: /------/ : :.................: : \------\ :
: / : : \ :
:/ cost<=25 : .........D......... : cost<=25 \:
O-----------O-------+ : /-------------\ : +-------O-----------O
:\ : cost=5| :/ \: |cost=5 : /:
: \ : +-O cost <= 30 O-+ : / :
: \------\ : : : : /------/ :
: cost>=30 \: :.................: :/ cost>=30 :
: O-----+ +-----O :
:...........: | .........E......... | :...........:
| : /-------------\ : |
cost=5| :/ \: |cost=5
+---O cost >= 30 O---+
: :
:.................:
Figure 9 - 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 Multi-domain controller 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
Multi-domain controller can understand by its own that:
o Domain B cannot be selected as the path connecting domains A and
E is not feasible;
Busi, Belotti, et al. Expires May 18, 2020 [Page 25]
Internet-Draft Yang for Path Computation November 2019
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 Multi-domain controller can understand by its own
that the optimal multi-domain path could be either A-D-F or A-E-F
but it cannot known which one of the two possible option actually
provides the optimal end-to-end path.
The Multi-domain controller 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).
.........B.........
: :
+---O O---+
......A...... | :.................: | ......F......
: : | | : :
: O-----+ .........C......... +-----O :
: : : /-------------\ : : :
: : :/ \: : :
: cost=15 O---------O cost = 25 O---------O cost=10 :
: /: cost=5 : : cost=5 :\ :
: /------/ : :.................: : \------\ :
: / : : \ :
:/ cost=10 : .........D......... : cost=15 \:
O-----------O-------+ : /-------------\ : +-------O-----------O
: : cost=5| :/ \: |cost=5 : :
: : +-O cost = 15 O-+ : :
: : : : : :
: : :.................: : :
: O-----+ +-----O :
:...........: | .........E......... | :...........:
| : : |
+---O O---+
:.................:
Figure 10 - Multi-domain with many domains (Path Computation
information)
Based on these requests, the Multi-domain controller can know the
actual cost of each intra-domain paths which belongs to potential
Busi, Belotti, et al. Expires May 18, 2020 [Page 26]
Internet-Draft Yang for Path Computation November 2019
optimal end-to-end paths, as shown in Figure 10, 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).
3.3. Stateless and Stateful Path Computation
The TE Tunnel YANG model, defined in [TE-TUNNEL], can support the
need to request path computation.
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 section 3.3.1
of [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.
It is very useful to provide options for both stateless and stateful
path computation mechanisms. It is suggested to use stateless
mechanisms as much as possible and to rely on stateful path
computation when really needed.
Stateless RPC allows requesting path computation using a simple
atomic operation and it is the natural option/choice, especially
with stateless PCE. The stateless path computation solution assumes
that the underlying SDN controller (e.g., a PNC) will compute a path
twice during the process to setup an LSP: at time T1, when its
client (e.g., an MDSC) sends a path computation RPC request to it,
and later, at time T2, when the same client (MDSC) creates a
te-tunnel requesting the setup of the LSP. The underlying assumption
is that, if network conditions have not changed, the same path that
has been computed at time T1 is also computed at time T2 by the
underlying SDN controller (e.g. PNC) and therefore the path that is
setup at time T2 is exactly the same path that has been computed at
time T1.
Since the operation is stateless, there is no guarantee that the
returned path would still be available when path setup is requested:
this does not cause major issues in case the time between path
computation and path setup is short (especially if compared with the
time that would be needed to update the information of a very
detailed connectivity matrix).
Busi, Belotti, et al. Expires May 18, 2020 [Page 27]
Internet-Draft Yang for Path Computation November 2019
In most of the cases, there is even no need to guarantee that the
path that has been setup is the exactly same as the path that has
been returned by path computation, especially if it has the same or
even better metrics. Depending on the abstraction level applied by
the server, the client may also not know the actual computed path.
The most important requirement is that the required global
objectives (e.g., multi-domain path metrics and constraints) are
met. For this reason a path verification phase is necessary to
verify that the actual path that has been setup meets the global
objectives (for example in a multi-domain network, the resulting
end-to-end path meets the required end-to-end metrics and
constraints).
In most of the cases, even if the setup path is not exactly the same
as the path returned by path computation, its metrics and
constraints are "good enough" (the path verification passes
successfully). In the few corner cases where the path verification
fails, it is possible repeat the whole process (path computation,
path setup and path verification).
In case the stateless solution is not sufficient and it would be the
need to setup at T2 exactly the same path computed at T1 a stateful
solution, based on "compute-only" TE tunnel, could be used to get
notifications in case the computed path has been changed. In this
case at time T1, the client (MDSC) creates a te-tunnel in a
compute-only mode in the config DS and later, at time T2, changes
the configuration of that te-tunnel (not to be any more in a
compute-only mode) to trigger the setup of the LSP.
It is worth noting that also the stateful solution, although
increasing the likelihood that the computed path is available at
path setup, does not guaranteed that because notifications may not
be reliable or delivered on time. Path verification is needed also
when stateful path computation is used.
The stateful path computation has also the following drawbacks:
o Several messages required for any path computation
o Requires persistent storage in the provider controller
o Need for garbage collection for stranded paths
Busi, Belotti, et al. Expires May 18, 2020 [Page 28]
Internet-Draft Yang for Path Computation November 2019
o Process burden to detect changes on the computed paths in order
to provide notifications update
3.3.1. Temporary reporting of the computed path state
This section describes an optional extension to the stateless
behavior where the underlying SDN controller, after having received
a path computation RPC request, maintains some "temporary
state" associated with the computed path, allowing the client to
request the setup of exactly that path, if still available.
This is similar to the stateful solution but, to avoid the drawbacks
of the stateful approach, is leveraging the path computation RPC and
the separation between configuration and operational DS, as defined
in the NMDA architecture [RFC8342].
The underlying SDN controller, after having computed a path, as
requested by a path computation RPC, also creates a te-tunnel
instance within the operational DS, to store that computed path.
This would be similar to the stateful solution with the only
difference that there is no associated te-tunnel instance within the
running DS.
Since underlying SDN controller stores in the operational DS the
computed path based on an abstract topology it exposes, it also
remembers, internally, which is the actual native path (physical
path), within its native topology (physical topology), associated
with that compute-only te-tunnel instance.
Afterwards, the client (e.g., MDSC) can request to setup that
specific path by creating a te-tunnel instance (not in compute-only
mode) in the running DS using the same tunnel-name of
the existing te-tunnel in the operational datastore: this will
trigger the underlying SDN controller to setup that path, if still
available.
There are still cases where the path being setup is not exactly the
same as the path that has been computed:
o When the tunnel is configured with path constraints which are not
compatible with the computed path
o When the tunnel setup is requested after the resources of the
computed path are no longer available
Busi, Belotti, et al. Expires May 18, 2020 [Page 29]
Internet-Draft Yang for Path Computation November 2019
o When the tunnel setup is requested after the computed path is no
longer known (e.g. due to a server reboot) by the underlying SDN
controller
In all these cases, the underlying SDN controller should compute and
setup a new path.
Therefore the "path verification" phase, as described in section 3.3
above, is still needed to check that the path that has been setup is
still "good enough".
Since this new approach is not completely stateless, garbage
collection is implemented using a timeout that, when it expires,
triggers the removal of the computed path from the operational DS.
This operation is fully controlled by the underlying SDN controller
without the need for any action to be taken by the client that is
not able to act on the operational datastore. The default value of
this timeout is 10 minutes but a different value may be configured
by the client.
In addition, it is possible for the client to tag each path
computation requests with a transaction-id allowing for a faster
removal of all the paths associated with a transaction-id, without
waiting for their timers to expire.
The underlying SDN controller can remove from the operational DS all
the paths computed with a given transaction-id which have not been
setup either when it receives a Path Delete RPC request for that
transaction-id or, automatically, right after the setup up of a path
that have been previously computed with that transaction-id.
This possibility is useful when multiple paths are computed but, at
most, only one is setup (e.g., in multi-domain path computation
scenario scenarios). After the selected path has been setup (e.g, in
one domain during multi-domain path setup), all the other
alternative computed paths can be automatically deleted by the
underlying SDN controller (since no longer needed). The client can
also request, using the Path Delete RPC request, the underlying SDN
controller to remove all the computed paths, if none of them is
going to be setup (e.g., in a transit domain not being selected by
multi-domain path computation and so not being automatically
deleted).
This approach is complimentary and not alternative to the timer
which is always needed to avoid stranded computed paths being stored
Busi, Belotti, et al. Expires May 18, 2020 [Page 30]
Internet-Draft Yang for Path Computation November 2019
in the operational DS when no path is setup and no explicit delete
RPC is received.
4. Path Computation and Optimization for multiple paths
There are use cases, where it is advantageous to request path
computation for a set of paths, through a network or through a
network domain, using a single request [RFC5440].
In this case, sending a single request for multiple path
computations, instead of sending multiple requests for each path
computation, would reduce the protocol overhead and it would consume
less resources (e.g., threads in the client and server).
In the context of a typical multi-domain TE network, there could
multiple choices for the ingress/egress points of a domain and the
Multi-domain controller needs to request path computation between
all the ingress/egress pairs to select the best pair. For example,
in the example of section 2.2, the Multi-domain controller needs to
request the TE network controller 1 to compute the A-C and the A-D
paths and to the TE network controller 2 to compute the E-H and the
F-H paths.
It is also possible that the Multi-domain controller receives a
request to setup a group of multiple end to end connections. The
multi-domain controller needs to request each TE domain controller
to compute multiple paths, one (or more) for each end to end
connection.
There are also scenarios where it can be needed to request path
computation for a set of paths in a synchronized fashion.
One example could be computing multiple diverse paths. Computing a
set of diverse paths in a not-synchronized fashion, leads to the
possibility of not being able to satisfy the diversity requirement.
In this case, it is preferable to compute a sub-optimal primary path
for which a diversely routed secondary path exists.
There are also scenarios where it is needed to request optimizing a
set of paths using objective functions that apply to the whole set
of paths, see [RFC5541], e.g. to minimize the sum of the costs of
all the computed paths in the set.
Busi, Belotti, et al. Expires May 18, 2020 [Page 31]
Internet-Draft Yang for Path Computation November 2019
5. YANG Model for requesting Path Computation
This document define a YANG stateless RPC to request path
computation as an "augmentation" of tunnel-rpc, defined in [TE-
TUNNEL]. This model provides the RPC input attributes that are
needed to request path computation and the RPC output attributes
that are needed to report the computed paths.
augment /te:tunnels-rpc/te:input/te:tunnel-info:
+---- path-request* [request-id]
| +---- request-id uint32
...........
augment /te:tunnels-rpc/te:output/te:result:
+--ro response* [response-id]
+--ro response-id uint32
+--ro (response-type)?
+--:(no-path-case)
| +--ro no-path!
+--:(path-case)
+--ro computed-path
...........
This model extensively re-uses the grouping defined in [TE-TUNNEL]
to ensure maximal syntax and semantics commonality.
This YANG model allows one RPC to include multiple path requests,
each path request being identified by a request-id. Therefore, one
RPC can return multiple responses, one for each path request, being
identified by a response-id equal to the corresponding request-id.
5.1. Synchronization of multiple path computation requests
The YANG model permits to synchronize a set of multiple path
requests (identified by specific request-id) all related to a "svec"
container emulating the syntax of "SVEC" PCEP object [RFC5440].
+---- synchronization* [synchronization-id]
+---- synchronization-id uint32
+---- svec
| +---- relaxable? boolean
| +---- disjointness? te-types:te-path-disjointness
Busi, Belotti, et al. Expires May 18, 2020 [Page 32]
Internet-Draft Yang for Path Computation November 2019
| +---- request-id-number* uint32
+---- svec-constraints
| +---- path-metric-bound* [metric-type]
| +---- metric-type identityref
| +---- upper-bound? uint64
+---- path-srlgs-values
| +---- usage? identityref
| +---- values* srlg
+---- path-srlgs-names
| +---- path-srlgs-name* [usage]
| +---- usage identityref
| +---- srlg-name* [name]
| +---- name string
+---- exclude-objects
...........
+---- optimizations
+---- (algorithm)?
+--:(metric)
| +---- optimization-metric* [metric-type]
| +---- metric-type identityref
| +---- weight? uint8
+--:(objective-function)
+---- objective-function
+---- objective-function-type? identityref
The model, in addition to the metric types, defined in [TE-TUNNEL],
which can be applied to each individual path request, defines
additional specific metrics types that apply to a set of
synchronized requests, as referenced in [RFC5541].
identity svec-metric-type {
description
"Base identity for svec metric type";
}
identity svec-metric-cumul-te {
base svec-metric-type;
description
"TE cumulative path metric";
}
Busi, Belotti, et al. Expires May 18, 2020 [Page 33]
Internet-Draft Yang for Path Computation November 2019
identity svec-metric-cumul-igp {
base svec-metric-type;
description
"IGP cumulative path metric";
}
identity svec-metric-cumul-hop {
base svec-metric-type;
description
"Hop cumulative path metric";
}
identity svec-metric-aggregate-bandwidth-consumption {
base svec-metric-type;
description
"Cumulative bandwith consumption of the set of
synchronized paths";
}
identity svec-metric-load-of-the-most-loaded-link {
base svec-metric-type;
description
"Load of the most loaded link";
}
5.2. Returned metric values
This YANG model provides a way to return the values of the metrics
computed by the path computation in the output of RPC, together with
other important information (e.g. srlg, affinities, explicit route),
emulating the syntax of the "C" flag of the "METRIC" PCEP object
[RFC5440]:
augment /te:tunnels-rpc/te:output/te:result:
+--ro response* [response-id]
+--ro response-id uint32
+--ro (response-type)?
+--:(no-path-case)
| +--ro no-path!
Busi, Belotti, et al. Expires May 18, 2020 [Page 34]
Internet-Draft Yang for Path Computation November 2019
+--:(path-case)
+--ro computed-path
+--ro path-id? yang-types:uuid
+--ro path-properties
+--ro path-metric* [metric-type]
| +--ro metric-type identityref
| +--ro accumulative-value? uint64
+--ro path-affinities-values
| +--ro path-affinities-value* [usage]
| +--ro usage identityref
| +--ro value? admin-groups
+--ro path-affinity-names
| +--ro path-affinity-name* [usage]
| +--ro usage identityref
| +--ro affinity-name* [name]
| +--ro name string
+--ro path-srlgs-values
| +--ro usage? identityref
| +--ro values* srlg
+--ro path-srlgs-names
| +--ro path-srlgs-name* [usage]
| +--ro usage identityref
| +--ro srlg-name* [name]
| +--ro name string
+--ro path-route-objects
...........
It also allows to request in the input of RPC which information
(metrics, srlg and/or affinities) should be returned:
module: ietf-te-path-computation
augment /te:tunnels-rpc/te:input/te:tunnel-info:
+---- path-request* [request-id]
| +---- request-id uint32
...........
| +---- requested-metrics* [metric-type]
| | +---- metric-type identityref
| +---- return-srlgs? boolean
| +---- return-affinities? boolean
...........
Busi, Belotti, et al. Expires May 18, 2020 [Page 35]
Internet-Draft Yang for Path Computation November 2019
This feature is essential for using a stateless path computation in
a multi-domain TE network as described in section 2.2. In this case,
the metrics returned by a path computation requested to a given TE
network controller must be used by the client to compute the best
end-to-end path. If they are missing the client cannot compare
different paths calculated by the TE network controllers and choose
the best one for the optimal e2e path.
5.3. Path Associations
Note - This section describes the models changes that are proposed
and not yet defined in section 6.
The YANG model allows including multiple path requests intended to
be used within the same tunnel or within different tunnels.
Multiple path requests that are intended to be used within the same
tunnel needs to be associated, indicating also the role of the path
being requested within the intended tunnel (e.g., primary or
secondary path).
The choice below is proposed to be added to the model to distinguish
whether the requested path is intended to be associated with other
requested paths within one tunnel, or not:
+---- (tunnel-information)?
| +----:(tunnel-association)
| | ...........
| +----:(tunnel-attributes)
| | ...........
The tunnel-attributes case will provide the set of attributes that
are usually configured on per-tunnel basis rather than on per-path
basis (e.g., tunnel-name, source/destination TTP, encoding and
switching-type).
The tunnel-association case provides the information needed to
associate multiple path requests that are intended to be used within
the same tunnel.
For this purpose, it is proposed to define a tunnel-associations
list:
Busi, Belotti, et al. Expires May 18, 2020 [Page 36]
Internet-Draft Yang for Path Computation November 2019
+---- tunnel-associations* [tunnel-association-id]
| +---- tunnel-association-id? uint32
| +---- tunnel-name? string
| ...........
The path requests that are intended to be used within the same
tunnel should reference the same tunnel-association-id. The
tunnel-associations list allows also to configure the per-tunnel
attributes common to all these path requests. This allow:
o avoiding repeating the same set of per-tunnel parameters on all
the requested path that are intended to belong to the same
tunnel;
o the server to understand what attributes (e.g., associations) are
intended to be configured per-tunnel and what attributes (e.g.,
associations) are intended to be configured per-path, which could
useful especially when the server also creates a te-tunnel
instance within the operational DS to report the computed paths,
as described in section 3.3.1.
In order to indicate the role of the path being requested within the
intended tunnel (e.g., primary or secondary path), the following
choice is proposed to be added to the:
+---- (path-role)?
| +----:(candidate-primary-path)
| | +---- candidate-primary-path empty
| +----:(candidate-secondary-path)
| | +---- candidate-secondary-path
| | | ...........
The candidate-secondary-path container references another requested
path that is intended to be the primary path associated with this
requested secondary path.
The YANG model allows also including path requests intended to be
used to modify existing tunnel (e.g., adding a protection path for
an existing un-protected tunnel). In this case, the path request
needs to be associated with existing path(s) within an existing
tunnel.
Busi, Belotti, et al. Expires May 18, 2020 [Page 37]
Internet-Draft Yang for Path Computation November 2019
Moreover, also the per-tunnel attributes are already provided in the
existing te-tunnel instance and do not need to be re-configured in
the RPC. Therefore, the tunnel-association list will not be used,
but the requested path(s) are proposed to be associated by
referencing the existing te-tunnel:
+----:(tunnel-association)
| +---- (tunnel-exist)?
| | +----:(tunnel-ref)
| | | +---- tunnel-ref leafref
| | +----:(tunnel-association-id)
| | | +---- tunnel-association-id uint32
| ...........
Open issue: need to evaluate whether this te-tunnel instance should
be within the operational DS or within the intended DS, or maybe, on
either one of the two DS
Moreover, a requested secondary path can either be associated with
another requested primary path or with an existing primary path, as
described in the proposal below:
+---- candidate-secondary-path
| +---- (primary-path-exist)?
| | +----:(primary-path-reference)
| | | +---- primary-path-ref leafref
| | +----:(primary-path-request)
| | | +---- primary-path-request-id uint32
...........
6. YANG model for stateless TE path computation
6.1. YANG Tree
Figure 11 below shows the tree diagram of the YANG model defined in
module ietf-te-path-computation.yang.
module: ietf-te-path-computation
augment /te:tunnels-rpc/te:input/te:tunnel-info:
+-- path-request* [request-id]
| +-- request-id uint32
| +-- encoding? identityref
Busi, Belotti, et al. Expires May 18, 2020 [Page 38]
Internet-Draft Yang for Path Computation November 2019
| +-- switching-type? identityref
| +-- source? inet:ip-address
| +-- destination? inet:ip-address
| +-- src-tp-id? binary
| +-- dst-tp-id? binary
| +-- bidirectional? boolean
| +-- te-topology-identifier
| | +-- provider-id? te-global-id
| | +-- client-id? te-global-id
| | +-- topology-id? te-topology-id
| +-- explicit-route-objects-always
| | +-- route-object-exclude-always* [index]
| | | +-- index uint32
| | | +-- (type)?
| | | +--:(numbered-node-hop)
| | | | +-- numbered-node-hop
| | | | +-- node-id te-node-id
| | | | +-- hop-type? te-hop-type
| | | +--:(numbered-link-hop)
| | | | +-- numbered-link-hop
| | | | +-- link-tp-id te-tp-id
| | | | +-- hop-type? te-hop-type
| | | | +-- direction? te-link-direction
| | | +--:(unnumbered-link-hop)
| | | | +-- unnumbered-link-hop
| | | | +-- link-tp-id te-tp-id
| | | | +-- node-id te-node-id
| | | | +-- hop-type? te-hop-type
| | | | +-- direction? te-link-direction
| | | +--:(as-number)
| | | | +-- as-number-hop
| | | | +-- as-number inet:as-number
| | | | +-- hop-type? te-hop-type
| | | +--:(label)
| | | +-- label-hop
| | | +-- te-label
| | | +-- (technology)?
| | | | +--:(generic)
Busi, Belotti, et al. Expires May 18, 2020 [Page 39]
Internet-Draft Yang for Path Computation November 2019
| | | | +-- generic? rt-types:generalized-
label
| | | +-- direction? te-label-direction
| | +-- route-object-include-exclude* [index]
| | +-- explicit-route-usage? identityref
| | +-- index uint32
| | +-- (type)?
| | +--:(numbered-node-hop)
| | | +-- numbered-node-hop
| | | +-- node-id te-node-id
| | | +-- hop-type? te-hop-type
| | +--:(numbered-link-hop)
| | | +-- numbered-link-hop
| | | +-- link-tp-id te-tp-id
| | | +-- hop-type? te-hop-type
| | | +-- direction? te-link-direction
| | +--:(unnumbered-link-hop)
| | | +-- unnumbered-link-hop
| | | +-- link-tp-id te-tp-id
| | | +-- node-id te-node-id
| | | +-- hop-type? te-hop-type
| | | +-- direction? te-link-direction
| | +--:(as-number)
| | | +-- as-number-hop
| | | +-- as-number inet:as-number
| | | +-- hop-type? te-hop-type
| | +--:(label)
| | | +-- label-hop
| | | +-- te-label
| | | +-- (technology)?
| | | | +--:(generic)
| | | | +-- generic? rt-types:generalized-
label
| | | +-- direction? te-label-direction
| | +--:(srlg)
| | +-- srlg
| | +-- srlg? uint32
| +-- path-constraints
| | +-- te-bandwidth
Busi, Belotti, et al. Expires May 18, 2020 [Page 40]
Internet-Draft Yang for Path Computation November 2019
| | | +-- (technology)?
| | | +--:(generic)
| | | +-- generic? te-bandwidth
| | +-- link-protection? identityref
| | +-- setup-priority? uint8
| | +-- hold-priority? uint8
| | +-- signaling-type? identityref
| | +-- path-metric-bounds
| | | +-- path-metric-bound* [metric-type]
| | | +-- metric-type identityref
| | | +-- upper-bound? uint64
| | +-- path-affinities-values
| | | +-- path-affinities-value* [usage]
| | | +-- usage identityref
| | | +-- value? admin-groups
| | +-- path-affinity-names
| | | +-- path-affinity-name* [usage]
| | | +-- usage identityref
| | | +-- affinity-name* [name]
| | | +-- name string
| | +-- path-srlgs-lists
| | | +-- path-srlgs-list* [usage]
| | | +-- usage identityref
| | | +-- values* srlg
| | +-- path-srlgs-names
| | | +-- path-srlgs-name* [usage]
| | | +-- usage identityref
| | | +-- names* string
| | +-- disjointness? te-path-disjointness
| +-- optimizations
| | +-- (algorithm)?
| | +--:(metric) {path-optimization-metric}?
| | | +-- optimization-metric* [metric-type]
| | | | +-- metric-type identityref
| | | | +-- weight? uint8
| | | | +-- explicit-route-exclude-objects
| | | | | +-- route-object-exclude-object* [index]
| | | | | +-- index uint32
| | | | | +-- (type)?
Busi, Belotti, et al. Expires May 18, 2020 [Page 41]
Internet-Draft Yang for Path Computation November 2019
| | | | | +--:(numbered-node-hop)
| | | | | | +-- numbered-node-hop
| | | | | | +-- node-id te-node-id
| | | | | | +-- hop-type? te-hop-type
| | | | | +--:(numbered-link-hop)
| | | | | | +-- numbered-link-hop
| | | | | | +-- link-tp-id te-tp-id
| | | | | | +-- hop-type? te-hop-type
| | | | | | +-- direction? te-link-
direction
| | | | | +--:(unnumbered-link-hop)
| | | | | | +-- unnumbered-link-hop
| | | | | | +-- link-tp-id te-tp-id
| | | | | | +-- node-id te-node-id
| | | | | | +-- hop-type? te-hop-type
| | | | | | +-- direction? te-link-
direction
| | | | | +--:(as-number)
| | | | | | +-- as-number-hop
| | | | | | +-- as-number inet:as-number
| | | | | | +-- hop-type? te-hop-type
| | | | | +--:(label)
| | | | | | +-- label-hop
| | | | | | +-- te-label
| | | | | | +-- (technology)?
| | | | | | | +--:(generic)
| | | | | | | +-- generic? rt-
types:generalized-label
| | | | | | +-- direction? te-label-
direction
| | | | | +--:(srlg)
| | | | | +-- srlg
| | | | | +-- srlg? uint32
| | | | +-- explicit-route-include-objects
| | | | +-- route-object-include-object* [index]
| | | | +-- index uint32
| | | | +-- (type)?
| | | | +--:(numbered-node-hop)
| | | | | +-- numbered-node-hop
Busi, Belotti, et al. Expires May 18, 2020 [Page 42]
Internet-Draft Yang for Path Computation November 2019
| | | | | +-- node-id te-node-id
| | | | | +-- hop-type? te-hop-type
| | | | +--:(numbered-link-hop)
| | | | | +-- numbered-link-hop
| | | | | +-- link-tp-id te-tp-id
| | | | | +-- hop-type? te-hop-type
| | | | | +-- direction? te-link-
direction
| | | | +--:(unnumbered-link-hop)
| | | | | +-- unnumbered-link-hop
| | | | | +-- link-tp-id te-tp-id
| | | | | +-- node-id te-node-id
| | | | | +-- hop-type? te-hop-type
| | | | | +-- direction? te-link-
direction
| | | | +--:(as-number)
| | | | | +-- as-number-hop
| | | | | +-- as-number inet:as-number
| | | | | +-- hop-type? te-hop-type
| | | | +--:(label)
| | | | +-- label-hop
| | | | +-- te-label
| | | | +-- (technology)?
| | | | | +--:(generic)
| | | | | +-- generic? rt-
types:generalized-label
| | | | +-- direction? te-label-
direction
| | | +-- tiebreakers
| | | +-- tiebreaker* [tiebreaker-type]
| | | +-- tiebreaker-type identityref
| | +--:(objective-function) {path-optimization-objective-
function}?
| | +-- objective-function
| | +-- objective-function-type? identityref
| +-- path-in-segment!
| | +-- label-restrictions
| | +-- label-restriction* [index]
| | +-- restriction? enumeration
Busi, Belotti, et al. Expires May 18, 2020 [Page 43]
Internet-Draft Yang for Path Computation November 2019
| | +-- index uint32
| | +-- label-start
| | | +-- te-label
| | | +-- (technology)?
| | | | +--:(generic)
| | | | +-- generic? rt-types:generalized-
label
| | | +-- direction? te-label-direction
| | +-- label-end
| | | +-- te-label
| | | +-- (technology)?
| | | | +--:(generic)
| | | | +-- generic? rt-types:generalized-
label
| | | +-- direction? te-label-direction
| | +-- label-step
| | | +-- (technology)?
| | | +--:(generic)
| | | +-- generic? int32
| | +-- range-bitmap? yang:hex-string
| +-- path-out-segment!
| | +-- label-restrictions
| | +-- label-restriction* [index]
| | +-- restriction? enumeration
| | +-- index uint32
| | +-- label-start
| | | +-- te-label
| | | +-- (technology)?
| | | | +--:(generic)
| | | | +-- generic? rt-types:generalized-
label
| | | +-- direction? te-label-direction
| | +-- label-end
| | | +-- te-label
| | | +-- (technology)?
| | | | +--:(generic)
| | | | +-- generic? rt-types:generalized-
label
| | | +-- direction? te-label-direction
Busi, Belotti, et al. Expires May 18, 2020 [Page 44]
Internet-Draft Yang for Path Computation November 2019
| | +-- label-step
| | | +-- (technology)?
| | | +--:(generic)
| | | +-- generic? int32
| | +-- range-bitmap? yang:hex-string
| +-- requested-metrics* [metric-type]
| | +-- metric-type identityref
| +-- return-srlgs? boolean
| +-- return-affinities? boolean
| +-- requested-state!
| +-- timer? uint16
| +-- transaction-id? string
| +-- tunnel-name? string
| +-- (path)?
| +--:(primary)
| | +-- primary-path-name? string
| +--:(secondary)
| +-- secondary-path-name? string
+-- synchronization* [synchronization-id]
+-- synchronization-id uint32
+-- svec
| +-- relaxable? boolean
| +-- disjointness? te-path-disjointness
| +-- request-id-number* uint32
+-- svec-constraints
| +-- path-metric-bound* [metric-type]
| +-- metric-type identityref
| +-- upper-bound? uint64
+-- path-srlgs-lists
| +-- path-srlgs-list* [usage]
| +-- usage identityref
| +-- values* srlg
+-- path-srlgs-names
| +-- path-srlgs-name* [usage]
| +-- usage identityref
| +-- names* string
+-- exclude-objects
| +-- excludes* [index]
| +-- index uint32
Busi, Belotti, et al. Expires May 18, 2020 [Page 45]
Internet-Draft Yang for Path Computation November 2019
| +-- (type)?
| +--:(numbered-node-hop)
| | +-- numbered-node-hop
| | +-- node-id te-node-id
| | +-- hop-type? te-hop-type
| +--:(numbered-link-hop)
| | +-- numbered-link-hop
| | +-- link-tp-id te-tp-id
| | +-- hop-type? te-hop-type
| | +-- direction? te-link-direction
| +--:(unnumbered-link-hop)
| | +-- unnumbered-link-hop
| | +-- link-tp-id te-tp-id
| | +-- node-id te-node-id
| | +-- hop-type? te-hop-type
| | +-- direction? te-link-direction
| +--:(as-number)
| | +-- as-number-hop
| | +-- as-number inet:as-number
| | +-- hop-type? te-hop-type
| +--:(label)
| +-- label-hop
| +-- te-label
| +-- (technology)?
| | +--:(generic)
| | +-- generic? rt-types:generalized-
label
| +-- direction? te-label-direction
+-- optimizations
+-- (algorithm)?
+--:(metric) {te-types:path-optimization-metric}?
| +-- optimization-metric* [metric-type]
| +-- metric-type identityref
| +-- weight? uint8
+--:(objective-function) {te-types:path-optimization-
objective-function}?
+-- objective-function
+-- objective-function-type? identityref
augment /te:tunnels-rpc/te:output/te:result:
Busi, Belotti, et al. Expires May 18, 2020 [Page 46]
Internet-Draft Yang for Path Computation November 2019
+--ro response* [response-id]
+--ro response-id uint32
+--ro (response-type)?
+--:(no-path-case)
| +--ro no-path!
+--:(path-case)
+--ro computed-path
+--ro path-properties
| +--ro path-metric* [metric-type]
| | +--ro metric-type identityref
| | +--ro accumulative-value? uint64
| +--ro path-affinities-values
| | +--ro path-affinities-value* [usage]
| | +--ro usage identityref
| | +--ro value? admin-groups
| +--ro path-affinity-names
| | +--ro path-affinity-name* [usage]
| | +--ro usage identityref
| | +--ro affinity-name* [name]
| | +--ro name string
| +--ro path-srlgs-lists
| | +--ro path-srlgs-list* [usage]
| | +--ro usage identityref
| | +--ro values* srlg
| +--ro path-srlgs-names
| | +--ro path-srlgs-name* [usage]
| | +--ro usage identityref
| | +--ro names* string
| +--ro path-route-objects
| +--ro path-route-object* [index]
| +--ro index uint32
| +--ro (type)?
| +--:(numbered-node-hop)
| | +--ro numbered-node-hop
| | +--ro node-id te-node-id
| | +--ro hop-type? te-hop-type
| +--:(numbered-link-hop)
| | +--ro numbered-link-hop
| | +--ro link-tp-id te-tp-id
Busi, Belotti, et al. Expires May 18, 2020 [Page 47]
Internet-Draft Yang for Path Computation November 2019
| | +--ro hop-type? te-hop-type
| | +--ro direction? te-link-
direction
| +--:(unnumbered-link-hop)
| | +--ro unnumbered-link-hop
| | +--ro link-tp-id te-tp-id
| | +--ro node-id te-node-id
| | +--ro hop-type? te-hop-type
| | +--ro direction? te-link-
direction
| +--:(as-number)
| | +--ro as-number-hop
| | +--ro as-number inet:as-number
| | +--ro hop-type? te-hop-type
| +--:(label)
| +--ro label-hop
| +--ro te-label
| +--ro (technology)?
| | +--:(generic)
| | +--ro generic? rt-
types:generalized-label
| +--ro direction? te-
label-direction
+--ro tunnel-ref? te:tunnel-ref
+--ro (path)?
+--:(primary)
| +--ro primary-path-ref? ->
/te:te/tunnels/tunnel[te:name=current()/../tunnel-ref]/p2p-primary-
paths/p2p-primary-path/name
+--:(secondary)
+--ro secondary-path-ref? ->
/te:te/tunnels/tunnel[te:name=current()/../tunnel-ref]/p2p-
secondary-paths/p2p-secondary-path/name
augment /te:tunnels-rpc/te:input/te:tunnel-info:
+-- deleted-paths-transaction-id* string
augment /te:tunnels-rpc/te:output/te:result:
+-- deleted-paths-transaction-id* string
Figure 11 - TE path computation YANG tree
Busi, Belotti, et al. Expires May 18, 2020 [Page 48]
Internet-Draft Yang for Path Computation November 2019
6.2. YANG Module
<CODE BEGINS>file "ietf-te-path-computation@2019-03-11.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-inet-types {
prefix "inet";
}
import ietf-te {
prefix "te";
}
import ietf-te-types {
prefix "te-types";
}
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";
Busi, Belotti, et al. Expires May 18, 2020 [Page 49]
Internet-Draft Yang for Path Computation November 2019
revision "2019-03-11" {
description
"Initial revision";
reference
"draft-ietf-teas-yang-path-computation";
}
/*
* Features
*/
feature stateless-path-computation {
description
"This feature indicates that the system supports
stateless path computation.";
}
/*
* Groupings
*/
grouping path-info {
uses te-types:generic-path-properties;
description "Path computation output information";
}
grouping requested-info {
description
"This grouping defines the information (e.g., metrics)
which must be returned in the response";
list requested-metrics {
key 'metric-type';
description
"The list of the requested metrics
The metrics listed here must be returned in the response.
Returning other metrics in the response is optional.";
leaf metric-type {
type identityref {
Busi, Belotti, et al. Expires May 18, 2020 [Page 50]
Internet-Draft Yang for Path Computation November 2019
base te-types:path-metric-type;
}
description
"The metric that must be returned in the response";
}
}
leaf return-srlgs {
type boolean;
default false;
description
"If true, path srlgs must be returned in the response.
If false, returning path srlgs in the response optional.";
}
leaf return-affinities {
type boolean;
default false;
description
"If true, path affinities must be returned in the response.
If false, returning path affinities in the response is
optional.";
}
}
grouping requested-state {
description
"Configuration for the transient state used
to report the computed path";
leaf timer {
type uint16;
units minutes;
default 10;
description
"The timeout after which the transient state reporting
the computed path should be removed.";
}
leaf transaction-id {
type string;
description
"
Busi, Belotti, et al. Expires May 18, 2020 [Page 51]
Internet-Draft Yang for Path Computation November 2019
The transaction-id associated with this path computation
to be used for fast deletion of the transient states
associated with multiple path computations.
This transaction-id can be used to explicitly delete all
the transient states of all the computed paths associated
with the same transaction-id.
When one path associated with a transaction-id is setup,
the transient states of all the other computed paths
with the same transaction-id are automatically removed.
If not specified, the transient state is removed only
when the timer expires (when the timer is specified)
or not created at all (stateless path computation,
when the timer is not specified).
";
}
leaf tunnel-name {
type string;
description
"
The suggested name to be assigned to the te-tunnel
instance which is created to report the computed path.
In case multiple paths are requested with the same
suggested name, the server will create only one te-tunnel
instance to report all the computed paths
with the same suggested name.
A different name can be assigned by server (e.g., when a
te-tunnel with this name already exists).
";
}
choice path {
description
"The transient state of the computed path can be reported
as a primary or a secondary path of a te-tunnel";
case primary {
Busi, Belotti, et al. Expires May 18, 2020 [Page 52]
Internet-Draft Yang for Path Computation November 2019
leaf primary-path-name {
type string;
description
"
The suggested name to be assigned to the
p2p-primary-path instance which is created
to report the computed path.
A different name can be assigned by the server
(e.g., when a p2p-primary-path with this name
already exists).
";
}
}
case secondary {
leaf secondary-path-name {
type string;
description
"
The suggested name to be assigned to the
p2p-secondary-path instance which is created
to report the computed path.
A different name can be assigned by the server
(e.g., when a p2p-secondary-path with this
name already exists).
If not specified, the a p2p-primary-path is created
by the server.
";
}
}
}
}
grouping reported-state {
description
"Information about the transient state created
to report the computed path";
Busi, Belotti, et al. Expires May 18, 2020 [Page 53]
Internet-Draft Yang for Path Computation November 2019
leaf tunnel-ref {
type te:tunnel-ref;
description
"
Reference to the tunnel that reports the transient state
of the computed path.
If no transient state is created, this attribute is empty.
";
}
choice path {
description
"The transient state of the computed path can be reported
as a primary or a secondary path of a te-tunnel";
case primary {
leaf primary-path-ref {
type leafref {
path "/te:te/te:tunnels/" +
"te:tunnel[te:name=current()/../tunnel-ref]/" +
"te:p2p-primary-paths/te:p2p-primary-path/" +
"te:name";
}
must "../tunnel-ref" {
description
"The primary-path-name can only be reported
if also the tunnel is reported
to provide the complete reference.";
}
description
"
Reference to the p2p-primary-path that reports
the transient state of the computed path.
If no transient state is created,
this attribute is empty.
";
}
}
Busi, Belotti, et al. Expires May 18, 2020 [Page 54]
Internet-Draft Yang for Path Computation November 2019
case secondary {
leaf secondary-path-ref {
type leafref {
path "/te:te/te:tunnels/" +
"te:tunnel[te:name=current()/../tunnel-ref]/" +
"te:p2p-secondary-paths/te:p2p-secondary-path/" +
"te:name";
}
must "../tunnel-ref" {
description
"The secondary-path-name can only be reported
if also the tunnel is reported to provide
the complete reference.";
}
description
"
Reference to the p2p-secondary-path that reports
the transient state of the computed path.
If no transient state is created,
this attribute is empty.
";
}
}
}
}
identity svec-metric-type {
description
"Base identity for svec metric type";
}
identity svec-metric-cumul-te {
base svec-metric-type;
description
"TE cumulative path metric";
}
identity svec-metric-cumul-igp {
Busi, Belotti, et al. Expires May 18, 2020 [Page 55]
Internet-Draft Yang for Path Computation November 2019
base svec-metric-type;
description
"IGP cumulative path metric";
}
identity svec-metric-cumul-hop {
base svec-metric-type;
description
"Hop cumulative path metric";
}
identity svec-metric-aggregate-bandwidth-consumption {
base svec-metric-type;
description
"Cumulative bandwith consumption of the set of
synchronized paths";
}
identity svec-metric-load-of-the-most-loaded-link {
base svec-metric-type;
description
"Load of the most loaded link";
}
grouping svec-metrics-bounds_config {
description
"TE path metric bounds grouping for computing a set of
synchronized requests";
leaf metric-type {
type identityref {
base svec-metric-type;
}
description "TE path metric type usable for computing a set of
synchronized requests";
}
leaf upper-bound {
type uint64;
description "Upper bound on end-to-end svec path metric";
}
Busi, Belotti, et al. Expires May 18, 2020 [Page 56]
Internet-Draft Yang for Path Computation November 2019
}
grouping svec-metrics-optimization_config {
description
"TE path metric bounds grouping for computing a set of
synchronized requests";
leaf metric-type {
type identityref {
base svec-metric-type;
}
description "TE path metric type usable for computing a set of
synchronized requests";
}
leaf weight {
type uint8;
description "Metric normalization weight";
}
}
grouping svec-exclude {
description "List of resources to be excluded by all the paths
in the SVEC";
container exclude-objects {
description "resources to be excluded";
list excludes {
key index;
ordered-by user;
leaf index {
type uint32;
description "XRO subobject index";
}
description
"List of explicit route objects to always exclude
from synchronized path computation";
uses te-types:explicit-route-hop;
}
}
}
Busi, Belotti, et al. Expires May 18, 2020 [Page 57]
Internet-Draft Yang for Path Computation November 2019
grouping synchronization-constraints {
description "Global constraints applicable to synchronized
path computation";
container svec-constraints {
description "global svec constraints";
list path-metric-bound {
key metric-type;
description "list of bound metrics";
uses svec-metrics-bounds_config;
}
}
uses te-types:generic-path-srlgs;
uses svec-exclude;
}
grouping synchronization-optimization {
description "Synchronized request optimization";
container optimizations {
description
"The objective function container that includes attributes
to impose when computing a synchronized set of paths";
choice algorithm {
description "Optimizations algorithm.";
case metric {
if-feature te-types:path-optimization-metric;
list optimization-metric {
key "metric-type";
description "svec path metric type";
uses svec-metrics-optimization_config;
}
}
case objective-function {
if-feature te-types:path-optimization-objective-function;
container objective-function {
description
"The objective function container that includes
attributes to impose when computing a TE path";
Busi, Belotti, et al. Expires May 18, 2020 [Page 58]
Internet-Draft Yang for Path Computation November 2019
leaf objective-function-type {
type identityref {
base te-types:objective-function-type;
}
default te-types:of-minimize-cost-path;
description "Objective function entry";
}
}
}
}
}
}
grouping synchronization-info {
description "Information for sync";
list synchronization {
key "synchronization-id";
description "sync list";
leaf synchronization-id {
type uint32;
description "index";
}
container svec {
description
"Synchronization VECtor";
leaf relaxable {
type boolean;
default true;
description
"If this leaf is true, path computation process is
free to ignore svec content.
Otherwise, it must take into account this svec.";
}
uses te-types:generic-path-disjointness;
leaf-list request-id-number {
type uint32;
description
"This list reports the set of path computation
requests that must be synchronized.";
Busi, Belotti, et al. Expires May 18, 2020 [Page 59]
Internet-Draft Yang for Path Computation November 2019
}
}
uses synchronization-constraints;
uses synchronization-optimization;
}
}
grouping no-path-info {
description "no-path-info";
container no-path {
presence "Response without path information, due to failure
performing the path computation";
description "if path computation cannot identify a path,
rpc returns no path.";
}
}
/*
* These groupings should be removed when defined in te-types
*/
grouping encoding-and-switching-type {
description
"Common grouping to define the LSP encoding and
switching types";
leaf encoding {
type identityref {
base te-types:lsp-encoding-types;
}
description "LSP encoding type";
reference "RFC3945";
}
leaf switching-type {
type identityref {
base te-types:switching-capabilities;
}
description "LSP switching type";
reference "RFC3945";
Busi, Belotti, et al. Expires May 18, 2020 [Page 60]
Internet-Draft Yang for Path Computation November 2019
}
}
grouping tunnel-p2p-common-params {
description
"Common grouping to define the TE tunnel parameters";
uses encoding-and-switching-type;
leaf source {
type inet:ip-address;
description "TE tunnel source address.";
}
leaf destination {
type inet:ip-address;
description "P2P tunnel destination address";
}
leaf src-tp-id {
type binary;
description
"TE tunnel source termination point identifier.";
}
leaf dst-tp-id {
type binary;
description
"TE tunnel destination termination point identifier.";
}
leaf bidirectional {
type boolean;
default 'false';
description "TE tunnel bidirectional";
}
}
/*
* AUGMENTS TO TE RPC
*/
augment "/te:tunnels-rpc/te:input/te:tunnel-info" {
description "Path Computation RPC input";
Busi, Belotti, et al. Expires May 18, 2020 [Page 61]
Internet-Draft Yang for Path Computation November 2019
list path-request {
key "request-id";
description "request-list";
leaf request-id {
type uint32;
mandatory true;
description
"Each path computation request is uniquely identified
by the request-id-number.";
}
uses tunnel-p2p-common-params;
uses te-types:te-topology-identifier;
uses te-types:path-constraints-route-objects;
uses te-types:generic-path-constraints;
uses te-types:generic-path-optimization;
uses te:path-access-segment-info;
uses requested-info;
container requested-state {
presence
"Request temporary reporting of the computed path state";
description
"Configures attributes for the temporary reporting of the
computed path state (e.g., expiration timer).";
uses requested-state;
}
}
uses synchronization-info;
}
augment "/te:tunnels-rpc/te:output/te:result" {
description "Path Computation RPC output";
list response {
key "response-id";
config false;
description "response";
leaf response-id {
type uint32;
description
"The response-id has the same value of the corresponding
Busi, Belotti, et al. Expires May 18, 2020 [Page 62]
Internet-Draft Yang for Path Computation November 2019
request-id.";
}
choice response-type {
config false;
description "response-type";
case no-path-case {
uses no-path-info;
}
case path-case {
container computed-path {
uses path-info;
uses reported-state;
description "Path computation service.";
}
}
}
}
}
augment "/te:tunnels-rpc/te:input/te:tunnel-info" {
description "Path Delete RPC input";
leaf-list deleted-paths-transaction-id {
type string;
description
"The list of the transaction-id values of the
transient states to be deleted";
}
}
augment "/te:tunnels-rpc/te:output/te:result" {
description "Path Delete RPC output";
leaf-list deleted-paths-transaction-id {
type string;
description
"The list of the transaction-id values of the
transient states that have been successfully deleted";
}
}
}
Busi, Belotti, et al. Expires May 18, 2020 [Page 63]
Internet-Draft Yang for Path Computation November 2019
<CODE ENDS>
Figure 12 - TE path computation YANG module
7. Security Considerations
This document describes use cases of requesting Path Computation
using YANG models, which could be used at the ABNO Control Interface
[RFC7491] and/or between controllers in ACTN [RFC8453]. As such, it
does not introduce any new security considerations compared to the
ones related to YANG specification, ABNO specification and ACTN
Framework defined in [RFC7950], [RFC7491] and [RFC8453].
The YANG module defined in this draft is designed to be accessed via
the NETCONF protocol [RFC6241] or RESTCONF protocol [RFC8040]. The
lowest NETCONF layer is the secure transport layer, and the
mandatory-to-implement secure transport is Secure Shell (SSH)
[RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-
implement secure transport is TLS [RFC8446].
This document also defines common data types using the YANG data
modeling language. The definitions themselves have no security
impact on the Internet, but the usage of these definitions in
concrete YANG modules might have. The security considerations
spelled out in the YANG specification [RFC7950] apply for this
document as well.
The NETCONF access control model [RFC8341] provides the means to
restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
Note - The security analysis of each leaf is for further study.
8. IANA Considerations
This document registers the following URIs in the IETF XML registry
[RFC3688]. Following the format in [RFC3688], the following
registration is requested to be made.
URI: urn:ietf:params:xml:ns:yang:ietf-te-path-computation
XML: N/A, the requested URI is an XML namespace.
Busi, Belotti, et al. Expires May 18, 2020 [Page 64]
Internet-Draft Yang for Path Computation November 2019
This document registers a YANG module in the YANG Module Names
registry [RFC7950].
name: ietf-te-path-computation
namespace: urn:ietf:params:xml:ns:yang:ietf-te-path-computation
prefix: tepc
9. References
9.1. Normative References
[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January
2004.
[RFC5440] Vasseur, JP., Le Roux, JL. et al., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
"A Backward-Recursive PCE-Based Computation (BRPC)
Procedure to Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched Paths", RFC 5441,
DOI 10.17487/RFC5441, April 2009, <https://www.rfc-
editor.org/info/rfc5441>.
[RFC5541] Le Roux, JL. et al., " Encoding of Objective Functions in
the Path Computation Element Communication Protocol
(PCEP)", RFC 5541, June 2009.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, June 2011.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, January 2017.
[RFC8341] Bierman, A., and M. Bjorklund, "Network Configuration
Access Control Model", RFC 8341, March 2018.
Busi, Belotti, et al. Expires May 18, 2020 [Page 65]
Internet-Draft Yang for Path Computation November 2019
[RFC7491] Farrel, A., King, D., "A PCE-Based Architecture for
Application-Based Network Operations", RFC 7491, March
2015.
[RFC7926] Farrel, A. et al., "Problem Statement and Architecture for
Information Exchange Between Interconnected Traffic
Engineered Networks", RFC 7926, July 2016.
[RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC
7950, August 2016.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, January 2017.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, August 2018.
[RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction
and Control of TE Networks (ACTN)", RFC8453, August 2018.
[RFC8454] Lee, Y. et al., "Information Model for Abstraction and
Control of TE Networks (ACTN)", RFC8454, September 2018.
[TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies",
draft-ietf-teas-yang-te-topo, work in progress.
[TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic
Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
te, work in progress.
9.1. Informative References
[RFC4655] Farrel, A. et al., "A Path Computation Element (PCE)-Based
Architecture", RFC 4655, August 2006.
[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the
Path Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI
10.17487/RFC6805, November 2012, <https://www.rfc-
editor.org/info/rfc6805>.
[RFC7139] Zhang, F. et al., "GMPLS Signaling Extensions for Control
of Evolving G.709 Optical Transport Networks", RFC 7139,
March 2014.
Busi, Belotti, et al. Expires May 18, 2020 [Page 66]
Internet-Draft Yang for Path Computation November 2019
[RFC7446] Lee, Y. et al., "Routing and Wavelength Assignment
Information Model for Wavelength Switched Optical
Networks", RFC 7446, February 2015.
[RFC8233] Dhody, D. et al., "Extensions to the Path Computation
Element Communication Protocol (PCEP) to Compute Service-
Aware Label Switched Paths (LSPs)", RFC 8233, September
2017
[RFC8342] Bjorklund,M. et al. "Network Management Datastore
Architecture (NMDA)", RFC 8342, March 2018
[OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical
Transport Network Topology", draft-ietf-ccamp-otn-topo-
yang, work in progress.
[ITU-T G.709-2016] ITU-T Recommendation G.709 (06/16), "Interface
for the optical transport network", June 2016.
10. Acknowledgments
The authors would like to thank Igor Bryskin and Xian Zhang for
participating in the initial discussions that have triggered this
work and providing valuable insights.
The authors would like to thank the authors of the TE Tunnel YANG
model [TE-TUNNEL], in particular Igor Bryskin, Vishnu Pavan Beeram,
Tarek Saad and Xufeng Liu, for their inputs to the discussions and
support in having consistency between the Path Computation and TE
Tunnel YANG models.
The authors would like to thank Adrian Farrel, Dhruv Dhody, Igor
Bryskin, Julien Meuric and Lou Berger for their valuable input to
the discussions that has clarified that the path being setup is not
necessarily the same as the path that have been previously computed
and, in particular to Dhruv Dhody, for his suggestion to describe
the need for a path verification phase to check that the actual path
being setup meets the required end-to-end metrics and constraints.
This document was prepared using 2-Word-v2.0.template.dot.
Busi, Belotti, et al. Expires May 18, 2020 [Page 67]
Internet-Draft Yang for Path Computation November 2019
Appendix A. Examples of dimensioning the "detailed connectivity matrix"
In the following table, a list of the possible constraints,
associated with their potential cardinality, is reported.
The maximum number of potential connections to be computed and
reported is, in first approximation, the multiplication of all of
them.
Constraint Cardinality
---------- -------------------------------------------------------
End points N(N-1)/2 if connections are bidirectional (OTN and WDM),
N(N-1) for unidirectional connections.
Bandwidth In WDM networks, bandwidth values are expressed in GHz.
On fixed-grid WDM networks, the central frequencies are
on a 50GHz grid and the channel width of the transmitters
are typically 50GHz such that each central frequency can
be used, i.e., adjacent channels can be placed next to
each other in terms of central frequencies.
On flex-grid WDM networks, the central frequencies are on
a 6.25GHz grid and the channel width of the transmitters
can be multiples of 12.5GHz.
For fixed-grid WDM networks typically there is only one
possible bandwidth value (i.e., 50GHz) while for flex-
grid WDM networks typically there are 4 possible
bandwidth values (e.g., 37.5GHz, 50GHz, 62.5GHz, 75GHz).
In OTN (ODU) networks, bandwidth values are expressed as
pairs of ODU type and, in case of ODUflex, ODU rate in
bytes/sec as described in section 5 of [RFC7139].
For "fixed" ODUk types, 6 possible bandwidth values are
possible (i.e., ODU0, ODU1, ODU2, ODU2e, ODU3, ODU4).
For ODUflex(GFP), up to 80 different bandwidth values can
be specified, as defined in Table 7-8 of [ITU-T G.709-
2016].
For other ODUflex types, like ODUflex(CBR), the number of
possible bandwidth values depends on the rates of the
Busi, Belotti, et al. Expires May 18, 2020 [Page 68]
Internet-Draft Yang for Path Computation November 2019
clients that could be mapped over these ODUflex types, as
shown in Table 7.2 of [ITU-T G.709-2016], which in theory
could be a countinuum of values. However, since different
ODUflex bandwidths that use the same number of TSs on
each link along the path are equivalent for path
computation purposes, up to 120 different bandwidth
ranges can be specified.
Ideas to reduce the number of ODUflex bandwidth values in
the detailed connectivity matrix, to less than 100, are
for further study.
Bandwidth specification for ODUCn is currently for
further study but it is expected that other bandwidth
values can be specified as integer multiples of 100Gb/s.
In IP we have bandwidth values in bytes/sec. In
principle, this is a countinuum of values, but in
practice we can identify a set of bandwidth ranges, where
any bandwidth value inside the same range produces the
same path.
The number of such ranges is the cardinality, which
depends on the topology, available bandwidth and status
of the network. Simulations (Note: reference paper
submitted for publication) show that values for medium
size topologies (around 50-150 nodes) are in the range 4-
7 (5 on average) for each end points couple.
Metrics IGP, TE and hop number are the basic objective metrics
defined so far. There are also the 2 objective functions
defined in [RFC5541]: Minimum Load Path (MLP) and Maximum
Residual Bandwidth Path (MBP). Assuming that one only
metric or objective function can be optimized at once,
the total cardinality here is 5.
With [RFC8233], a number of additional metrics are
defined, including Path Delay metric, Path Delay
Variation metric and Path Loss metric, both for point-to-
point and point-to-multipoint paths. This increases the
cardinality to 8.
Bounds Each metric can be associated with a bound in order to
find a path having a total value of that metric lower
than the given bound. This has a potentially very high
cardinality (as any value for the bound is allowed). In
Busi, Belotti, et al. Expires May 18, 2020 [Page 69]
Internet-Draft Yang for Path Computation November 2019
practice there is a maximum value of the bound (the one
with the maximum value of the associated metric) which
results always in the same path, and a range approach
like for bandwidth in IP should produce also in this case
the cardinality. Assuming to have a cardinality similar
to the one of the bandwidth (let say 5 on average) we
should have 6 (IGP, TE, hop, path delay, path delay
variation and path loss; we don't consider here the two
objective functions of [RFC5541] as they are conceived
only for optimization)*5 = 30 cardinality.
Technology
constraints For further study
Priority We have 8 values for setup priority, which is used in
path computation to route a path using free resources
and, where no free resources are available, resources
used by LSPs having a lower holding priority.
Local prot It's possible to ask for a local protected service, where
all the links used by the path are protected with fast
reroute (this is only for IP networks, but line
protection schemas are available on the other
technologies as well). This adds an alternative path
computation, so the cardinality of this constraint is 2.
Administrative
Colors Administrative colors (aka affinities) are typically
assigned to links but when topology abstraction is used
affinity information can also appear in the detailed
connectivity matrix.
There are 32 bits available for the affinities. Links can
be tagged with any combination of these bits, and path
computation can be constrained to include or exclude any
or all of them. The relevant cardinality is 3 (include-
any, exclude-any, include-all) times 2^32 possible
values. However, the number of possible values used in
real networks is quite small.
Included Resources
A path computation request can be associated to an
ordered set of network resources (links, nodes) to be
included along the computed path. This constraint would
Busi, Belotti, et al. Expires May 18, 2020 [Page 70]
Internet-Draft Yang for Path Computation November 2019
have a huge cardinality as in principle any combination
of network resources is possible. However, as far as the
Orchestrator doesn't know details about the internal
topology of the domain, it shouldn't include this type of
constraint at all (see more details below).
Excluded Resources
A path computation request can be associated to a set of
network resources (links, nodes, SRLGs) to be excluded
from the computed path. Like for included resources,
this constraint has a potentially very high cardinality,
but, once again, it can't be actually used by the
Orchestrator, if it's not aware of the domain topology
(see more details below).
As discussed above, the Orchestrator can specify include or exclude
resources depending on the abstract topology information that the
domain controller exposes:
o In case the domain controller exposes the entire domain as a
single abstract TE node with his own external terminations and
detailed connectivity matrix (whose size we are estimating), no
other topological details are available, therefore the size of
the detailed connectivity matrix only depends on the combination
of the constraints that the Orchestrator can use in a path
computation request to the domain controller. These constraints
cannot refer to any details of the internal topology of the
domain, as those details are not known to the Orchestrator and so
they do not impact size of the detailed connectivity matrix
exported.
Busi, Belotti, et al. Expires May 18, 2020 [Page 71]
Internet-Draft Yang for Path Computation November 2019
o Instead in case the domain controller exposes a topology
including more than one abstract TE nodes and TE links, and their
attributes (e.g. SRLGs, affinities for the links), the
Orchestrator knows these details and therefore could compute a
path across the domain referring to them in the constraints. The
detailed connectivity matrixes, whose size need to be estimated
here, are the ones relevant to the abstract TE nodes exported to
the Orchestrator. These detailed connectivity matrixes and
therefore theirs sizes, while cannot depend on the other abstract
TE nodes and TE links, which are external to the given abstract
node, could depend to SRLGs (and other attributes, like
affinities) which could be present also in the portion of the
topology represented by the abstract nodes, and therefore
contribute to the size of the related detailed connectivity
matrix.
We also don't consider here the possibility to ask for more than one
path in diversity or for point-to-multi-point paths, which are for
further study.
Considering for example an IP domain without considering SRLG and
affinities, we have an estimated number of paths depending on these
estimated cardinalities:
Endpoints = N*(N-1), Bandwidth = 5, Metrics = 6, Bounds = 20,
Priority = 8, Local prot = 2
The number of paths to be pre-computed by each IP domain is
therefore 24960 * N(N-1) where N is the number of domain access
points.
This means that with just 4 access points we have nearly 300000
paths to compute, advertise and maintain (if a change happens in the
domain, due to a fault, or just the deployment of new traffic, a
substantial number of paths need to be recomputed and the relevant
changes advertised to the upper controller).
This seems quite challenging. In fact, if we assume a mean length of
1K for the json describing a path (a quite conservative estimate),
reporting 300000 paths means transferring and then parsing more than
300 Mbytes for each domain. If we assume that 20% (to be checked) of
this paths change when a new deployment of traffic occurs, we have
60 Mbytes of transfer for each domain traversed by a new end-to-end
path. If a network has, let say, 20 domains (we want to estimate the
load for a non-trivial domain setup) in the beginning a total
Busi, Belotti, et al. Expires May 18, 2020 [Page 72]
Internet-Draft Yang for Path Computation November 2019
initial transfer of 6Gigs is needed, and eventually, assuming 4-5
domains are involved in mean during a path deployment we could have
240-300 Mbytes of changes advertised to the higher order controller.
Further bare-bone solutions can be investigated, removing some more
options, if this is considered not acceptable; in conclusion, it
seems that an approach based only on the information provided by the
detailed connectivity matrix is hardly feasible, and could be
applicable only to small networks with a limited meshing degree
between domains and renouncing to a number of path computation
features.
Busi, Belotti, et al. Expires May 18, 2020 [Page 73]
Internet-Draft Yang for Path Computation November 2019
Appendix B. New proposed YANG Tree overview
This Appendix provides an overview of the YANG Tree that would
results from the proposed changes described in section 5.3.
module: ietf-te-path-computation
augment /te:tunnels-rpc/te:input/te:tunnel-info:
+---- path-request* [request-id]
| +--- request-id uint32
| +---- (tunnel-information)?
| | +----:(tunnel-association)
| | | +---- (tunnel-exist)?
| | | | +----:(tunnel-ref)
| | | | | +---- tunnel-ref leafref
| | | | +----:(tunnel-association-id)
| | | | | +---- tunnel-association-id uint32
| | | +---- path-name? string
| | | +---- (path-role)?
| | | | +----:(candidate-primary-path)
| | | | | +---- candidate-primary-path empty
| | | | +----:(candidate-secondary-path)
| | | | | +---- candidate-secondary-path
| | | | | | +---- (primary-path-exist)?
| | | | | | | +----:(primary-path-reference)
| | | | | | | | +---- primary-path-ref
leafref
| | | | | | | +----:(primary-path-request)
| | | | | | | | +---- primary-path-request-id
uint32
| | +----:(tunnel-attributes)
| | | +---- tunnel-name? string
| | | | +---- (path-role)?
| | | | +--:(primary)
| | | | | +---- primary-path-name? string
| | | | +--:(secondary)
| | | | +---- secondary-path-name? string
| | | +--- encoding? identityref
| | | +--- switching-type? identityref
| | | +--- source? inet:ip-
address
Busi, Belotti, et al. Expires May 18, 2020 [Page 74]
Internet-Draft Yang for Path Computation November 2019
| | | +--- destination? inet:ip-
address
| | | +--- src-tp-id? binary
| | | +--- dst-tp-id? binary
| | | +--- bidirectional? boolean
| | | +--- te-topology-identifier
| | | | +--- provider-id? te-global-id
| | | | +--- client-id? te-global-id
| | | | +--- topology-id? te-topology-id
| +---- explicit-route-objects-always
| | ...........
| +---- path-constraints
| | +---- preference? uint8
| | ...........
| +---- optimizations
| | ...........
| +---- path-in-segment!
| | ...........
| +---- path-out-segment!
| | ...........
| +---- requested-metrics* [metric-type]
| | +---- metric-type identityref
| +---- return-srlgs? boolean
| +---- return-affinities? boolean
| +---- requested-state!
| +---- timer? uint16
| +---- transaction-id? string
+---- tunnel-associations* [tunnel-association-id]
| +---- tunnel-association-id? uint32
| +---- tunnel-name? string
| +---- encoding? identityref
| +---- switching-type? identityref
| +---- source? inet:ip-address
| +---- destination? inet:ip-address
| +---- src-tp-id? binary
| +---- dst-tp-id? binary
| +---- bidirectional? boolean
| +---- te-topology-identifier
| | +---- provider-id? te-global-id
Busi, Belotti, et al. Expires May 18, 2020 [Page 75]
Internet-Draft Yang for Path Computation November 2019
| | +---- client-id? te-global-id
| | +---- topology-id? te-topology-id
| +---- preference? uint8
| +---- association-objects
| | ...........
| +---- protection-type? identityref
| +---- restoration-type? identityref
| +---- te-bandwidth
| | ...........
| +---- link-protection? identityref
| +---- setup-priority? uint8
| +---- hold-priority? uint8
| +---- signaling-type? identityref
+---- synchronization* [synchronization-id]
...........
...........
Busi, Belotti, et al. Expires May 18, 2020 [Page 76]
Internet-Draft Yang for Path Computation November 2019
Contributors
Dieter Beller
Nokia
Email: dieter.beller@nokia.com
Gianmarco Bruno
Ericsson
Email: gianmarco.bruno@ericsson.com
Francesco Lazzeri
Ericsson
Email: francesco.lazzeri@ericsson.com
Young Lee
Huawei
Email: leeyoung@huawei.com
Carlo Perocchio
Ericsson
Email: carlo.perocchio@ericsson.com
Olivier Dugeon
Orange Labs
Email: olivier.dugeon@orange.com
Julien Meuric
Orange Labs
Email: julien.meuric@orange.com
Authors' Addresses
Italo Busi (Editor)
Huawei
Email: italo.busi@huawei.com
Busi, Belotti, et al. Expires May 18, 2020 [Page 77]
Internet-Draft Yang for Path Computation November 2019
Sergio Belotti (Editor)
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
Google
Email: ansha@google.com
Yan Shi
China Unicom
Email: shiyan49@chinaunicom.cn
Ricard Vilalta
CTTC
Email: ricard.vilalta@cttc.es
Karthik Sethuraman
NEC
Email: karthik.sethuraman@necam.com
Michael Scharf
Nokia
Email: michael.scharf@gmail.com
Daniele Ceccarelli
Ericsson
Email: daniele.ceccarelli@ericsson.com
Busi, Belotti, et al. Expires May 18, 2020 [Page 78]