< draft-ietf-teas-yang-path-computation-05.txt   draft-ietf-teas-yang-path-computation-06.txt >
TEAS Working Group Italo Busi (Ed.) TEAS Working Group Italo Busi (Ed.)
Internet Draft Huawei Internet Draft Huawei
Intended status: Standard Track Sergio Belotti (Ed.) Intended status: Standard Track Sergio Belotti (Ed.)
Expires: September 2019 Nokia Expires: January 2020 Nokia
Victor Lopez
Oscar Gonzalez de Dios
Telefonica
Anurag Sharma
Google
Yan Shi
China Unicom
Ricard Vilalta
CTTC
Karthik Sethuraman
NEC
March 11, 2019 July 8, 2019
Yang model for requesting Path Computation Yang model for requesting Path Computation
draft-ietf-teas-yang-path-computation-05.txt draft-ietf-teas-yang-path-computation-06.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 4 skipping to change at page 1, line 32
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 11, 2019.
This Internet-Draft will expire on January 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 40 skipping to change at page 2, line 29
request path computation. This model complements the stateful request path computation. This model complements the stateful
solution defined in [TE-TUNNEL]. solution defined in [TE-TUNNEL].
Moreover this document describes some use cases where a path Moreover this document describes some use cases where a path
computation request, via YANG-based protocols (e.g., NETCONF or computation request, via YANG-based protocols (e.g., NETCONF or
RESTCONF), can be needed. RESTCONF), can be needed.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Terminology...............................................5 1.1. Terminology...............................................4
2. Use Cases......................................................5 2. Use Cases......................................................5
2.1. Packet/Optical Integration................................5 2.1. Packet/Optical Integration................................5
2.2. Multi-domain TE Networks.................................10 2.2. Multi-domain TE Networks.................................10
2.3. Data center interconnections.............................12 2.3. Data center interconnections.............................12
3. Motivations...................................................14 2.4. Backward Recursive Path Computation scenario.............14
3.1. Motivation for a YANG Model..............................14 2.5. Hierarchical PCE scenario................................15
3.1.1. Benefits of common data models......................14 3. Motivations...................................................17
3.1.2. Benefits of a single interface......................15 3.1. Motivation for a YANG Model..............................17
3.1.3. Extensibility.......................................15 3.1.1. Benefits of common data models......................17
3.2. Interactions with TE Topology............................16 3.1.2. Benefits of a single interface......................18
3.2.1. TE Topology Aggregation.............................17 3.1.3. Extensibility.......................................19
3.2.2. TE Topology Abstraction.............................20 3.2. Interactions with TE Topology............................19
3.2.3. Complementary use of TE topology and path computation21 3.2.1. TE Topology Aggregation.............................20
3.3. Stateless and Stateful Path Computation..................24 3.2.2. TE Topology Abstraction.............................23
3.3.1. Temporary reporting of the computed path state......26 3.2.3. Complementary use of TE topology and path computation24
4. Path Computation and Optimization for multiple paths..........28 3.3. Stateless and Stateful Path Computation..................27
5. YANG Model for requesting Path Computation....................29 3.3.1. Temporary reporting of the computed path state......29
5.1. Synchronization of multiple path computation requests....29 4. Path Computation and Optimization for multiple paths..........31
5.2. Returned metric values...................................31 5. YANG Model for requesting Path Computation....................32
6. YANG model for stateless TE path computation..................33 5.1. Synchronization of multiple path computation requests....32
6.1. YANG Tree................................................33 5.2. Returned metric values...................................34
6.2. YANG Module..............................................43 6. YANG model for stateless TE path computation..................36
7. Security Considerations.......................................58 6.1. YANG Tree................................................36
8. IANA Considerations...........................................59 6.2. YANG Module..............................................46
9. References....................................................59 7. Security Considerations.......................................61
9.1. Normative References.....................................59 8. IANA Considerations...........................................62
9.1. Informative References...................................60 9. References....................................................62
10. Acknowledgments..............................................61 9.1. Normative References.....................................62
9.1. Informative References...................................64
10. Acknowledgments..............................................64
Appendix A. Examples of dimensioning the "detailed connectivity Appendix A. Examples of dimensioning the "detailed connectivity
matrix" 62 matrix" 66
1. Introduction 1. Introduction
There are scenarios, typically in a hierarchical SDN context, where There are scenarios, typically in a hierarchical SDN context, where
the topology information provided by a TE network provider may not the topology information provided by a TE network provider may not
be sufficient for its client to perform end-to-end path computation. be sufficient for its client to perform end-to-end path computation.
In these cases the client would need to request the provider to In these cases the client would need to request the provider to
calculate some (partial) feasible paths, complementing his topology calculate some (partial) feasible paths, complementing his topology
knowledge, to make his end-to-end path computation feasible. knowledge, to make his end-to-end path computation feasible.
skipping to change at page 5, line 21 skipping to change at page 5, line 7
of computing a network path or route based on a network graph, and of computing a network path or route based on a network graph, and
of applying computational constraints during the computation. The of applying computational constraints during the computation. The
PCE entity is an application that can be located within a network 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 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 PCE would be able to compute the path of a TE LSP by operating on
the TED and considering bandwidth and other constraints applicable the TED and considering bandwidth and other constraints applicable
to the TE LSP service request. [RFC4655] to the TE LSP service request. [RFC4655]
2. Use Cases 2. Use Cases
This section presents different use cases, where a client needs to This section presents some use cases, where a client needs to
request underlying SDN controllers for path computation. 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 The presented uses cases have been grouped, depending on the
different underlying topologies: a) Packet-Optical integration; b) different underlying topologies: a) Packet-Optical integration; b)
Multi-domain Traffic Engineered (TE) Networks; and c) Data center Multi-domain Traffic Engineered (TE) Networks; and c) Data center
interconnections. 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 2.1. Packet/Optical Integration
In this use case, an Optical network is used to provide connectivity In this use case, an Optical network is used to provide connectivity
to some nodes of a Packet network (see Figure 1). to some nodes of a Packet network (see Figure 1).
+----------------+ +----------------+
| | | |
| Packet/Optical | | Packet/Optical |
| Coordinator | | Coordinator |
skipping to change at page 14, line 14 skipping to change at page 14, line 14
resources. It may not be able to make this decision because it has 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). 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 The cloud network orchestrator can request to the TE network
controller to compute the cost of the possible TE paths (e.g., DC1- 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 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 it needs about the required data center resources within DC2 and DC3
and then it can take the decision about the optimal solution based and then it can take the decision about the optimal solution based
on this information and its policy. 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.
+----------------+ +----------------+
| 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
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]
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 3. Motivations
This section provides the motivation for the YANG model defined in This section provides the motivation for the YANG model defined in
this document. this document.
Section 3.1 describes the motivation for a YANG model to request Section 3.1 describes the motivation for a YANG model to request
path computation. path computation.
Section 3.2 describes the motivation for a YANG model which Section 3.2 describes the motivation for a YANG model which
complements the TE Topology YANG model defined in [TE-TOPO]. complements the TE Topology YANG model defined in [TE-TOPO].
skipping to change at page 17, line 37 skipping to change at page 20, line 43
information to calculate by its own the optimal path between R1 and information to calculate by its own the optimal path between R1 and
R2, without requesting any additional information to the Optical R2, without requesting any additional information to the Optical
network Controller. network Controller.
However, when designing the amount of information to provide within However, when designing the amount of information to provide within
the "detailed connectivity matrix", there is a tradeoff to be the "detailed connectivity matrix", there is a tradeoff to be
considered between accuracy (i.e., providing "all" the information considered between accuracy (i.e., providing "all" the information
that might be needed by the PCE available to Orchestrator) and that might be needed by the PCE available to Orchestrator) and
scalability. scalability.
Figure 6 below shows another example, similar to Figure 3, where Figure 8 below shows another example, similar to Figure 3, where
there are two possible Optical paths between VP1 and VP4 with there are two possible Optical paths between VP1 and VP4 with
different properties (e.g., available bandwidth and cost). different properties (e.g., available bandwidth and cost).
............................ ............................
: /--------------------\ : : /--------------------\ :
: / cost=65 \ : : / cost=65 \ :
:/ available-bw=10G \: :/ available-bw=10G \:
O VP1 VP4 O O VP1 VP4 O
cost=10 /:\ /:\ cost=10 cost=10 /:\ /:\ cost=10
/ : \----------------------/ : \ / : \----------------------/ : \
skipping to change at page 18, line 23 skipping to change at page 21, line 23
| |/ : available-bw=2G : \| | | |/ : available-bw=2G : \| |
| R1 | : : | R2 | | R1 | : : | R2 |
| |\ : : /| | | |\ : : /| |
+----+ \ : /--------------------\ : / +----+ +----+ \ : /--------------------\ : / +----+
\ : / cost=55 \ : / \ : / cost=55 \ : /
cost=5 \:/ available-bw=3G \:/ cost=5 cost=5 \:/ available-bw=3G \:/ cost=5
O VP2 VP5 O O VP2 VP5 O
: : : :
:..........................: :..........................:
Figure 6 - Packet/Optical Path Computation Example with multiple Figure 8 - Packet/Optical Path Computation Example with multiple
choices choices
Reporting all the information, as in Figure 6, using the "detailed Reporting all the information, as in Figure 8, using the "detailed
connectivity matrix", is quite challenging from a scalability connectivity matrix", is quite challenging from a scalability
perspective. The amount of this information is not just based on perspective. The amount of this information is not just based on
number of end points (which would scale as N-square), but also on number of end points (which would scale as N-square), but also on
many other parameters, including client rate, user many other parameters, including client rate, user
constraints/policies for the service, e.g. max latency < N ms, max constraints/policies for the service, e.g. max latency < N ms, max
cost, etc., exclusion policies to route around busy links, min OSNR cost, etc., exclusion policies to route around busy links, min OSNR
margin, max preFEC BER etc. All these constraints could be different margin, max preFEC BER etc. All these constraints could be different
based on connectivity requirements. based on connectivity requirements.
Examples of how the "detailed connectivity matrix" can be Examples of how the "detailed connectivity matrix" can be
skipping to change at page 19, line 44 skipping to change at page 22, line 44
takes to keep it up-to-date which increases the likelihood that the takes to keep it up-to-date which increases the likelihood that the
client's PCE computes paths using not updated information. client's PCE computes paths using not updated information.
It seems therefore quite challenging to have a "detailed It seems therefore quite challenging to have a "detailed
connectivity matrix" that provides accurate, scalable and updated connectivity matrix" that provides accurate, scalable and updated
information to allow the client's PCE to take optimal decisions by information to allow the client's PCE to take optimal decisions by
its own. its own.
Instead, if the information in the "detailed connectivity matrix" is Instead, if the information in the "detailed connectivity matrix" is
not complete/accurate, we can have the following drawbacks not complete/accurate, we can have the following drawbacks
considering for example the case in Figure 6: considering for example the case in Figure 8:
o If only the VP1-VP4 path with available bandwidth of 2 Gb/s and 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 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 Gb/s path between routers R1 and R2, although this would be
feasible; feasible;
o If only the VP1-VP4 path with available bandwidth of 10 Gb/s and 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, 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 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 within the Optical domain while the optimal path would actually
skipping to change at page 22, line 6 skipping to change at page 25, line 6
3.2.3. Complementary use of TE topology and path computation 3.2.3. Complementary use of TE topology and path computation
As discussed in section 2.2, there are some scalability issues with As discussed in section 2.2, there are some scalability issues with
path computation requests in a multi-domain TE network with many TE 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 domains, in terms of the number of requests to send to the TE domain
controllers. It would therefore be worthwhile using the TE topology controllers. It would therefore be worthwhile using the TE topology
information provided by the domain controllers to limit the number information provided by the domain controllers to limit the number
of requests. of requests.
An example can be described considering the multi-domain abstract An example can be described considering the multi-domain abstract
topology shown in Figure 7. In this example, an end-to-end TE path 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 between domains A and F needs to be setup. The transit domain should
be selected between domains B, C, D and E. be selected between domains B, C, D and E.
.........B......... .........B.........
: _ _ _ _ _ _ _ _ : : _ _ _ _ _ _ _ _ :
:/ \: :/ \:
+---O NOT FEASIBLE O---+ +---O NOT FEASIBLE O---+
cost=5| : : | cost=5| : : |
......A...... | :.................: | ......F...... ......A...... | :.................: | ......F......
: : | | : : : : | | : :
skipping to change at page 22, line 38 skipping to change at page 25, line 38
: \------\ : : : : /------/ : : \------\ : : : : /------/ :
: cost>=30 \: :.................: :/ cost>=30 : : cost>=30 \: :.................: :/ cost>=30 :
: O-----+ +-----O : : O-----+ +-----O :
:...........: | .........E......... | :...........: :...........: | .........E......... | :...........:
| : /-------------\ : | | : /-------------\ : |
cost=5| :/ \: |cost=5 cost=5| :/ \: |cost=5
+---O cost >= 30 O---+ +---O cost >= 30 O---+
: : : :
:.................: :.................:
Figure 7 - Multi-domain with many domains (Topology information) Figure 9 - Multi-domain with many domains (Topology information)
The actual cost of each intra-domain path is not known a priori from The actual cost of each intra-domain path is not known a priori from
the abstract topology information. The Multi-domain controller only the abstract topology information. The Multi-domain controller only
knows, from the TE topology provided by the underlying domain knows, from the TE topology provided by the underlying domain
controllers, the feasibility of some intra-domain paths and some controllers, the feasibility of some intra-domain paths and some
upper-bound and/or lower-bound cost information. With this upper-bound and/or lower-bound cost information. With this
information, together with the cost of inter-domain links, the information, together with the cost of inter-domain links, the
Multi-domain controller can understand by its own that: Multi-domain controller can understand by its own that:
o Domain B cannot be selected as the path connecting domains A and o Domain B cannot be selected as the path connecting domains A and
skipping to change at page 23, line 45 skipping to change at page 26, line 45
: : cost=5| :/ \: |cost=5 : : : : cost=5| :/ \: |cost=5 : :
: : +-O cost = 15 O-+ : : : : +-O cost = 15 O-+ : :
: : : : : : : : : : : :
: : :.................: : : : : :.................: : :
: O-----+ +-----O : : O-----+ +-----O :
:...........: | .........E......... | :...........: :...........: | .........E......... | :...........:
| : : | | : : |
+---O O---+ +---O O---+
:.................: :.................:
Figure 8 - Multi-domain with many domains (Path Computation Figure 10 - Multi-domain with many domains (Path Computation
information) information)
Based on these requests, the Multi-domain controller can know the Based on these requests, the Multi-domain controller can know the
actual cost of each intra-domain paths which belongs to potential actual cost of each intra-domain paths which belongs to potential
optimal end-to-end paths, as shown in Figure 8, and then compute the optimal end-to-end paths, as shown in Figure 10, and then compute
optimal end-to-end path (e.g., A-D-F, having total cost of 50, 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). instead of A-C-F having a total cost of 70).
3.3. Stateless and Stateful Path Computation 3.3. Stateless and Stateful Path Computation
The TE Tunnel YANG model, defined in [TE-TUNNEL], can support the The TE Tunnel YANG model, defined in [TE-TUNNEL], can support the
need to request path computation. need to request path computation.
It is possible to request path computation by configuring a It is possible to request path computation by configuring a
"compute-only" TE tunnel and retrieving the computed path(s) in the "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 LSP(s) Record-Route Object (RRO) list as described in section 3.3.1
skipping to change at page 29, line 15 skipping to change at page 32, line 15
5. YANG Model for requesting Path Computation 5. YANG Model for requesting Path Computation
This document define a YANG stateless RPC to request path This document define a YANG stateless RPC to request path
computation as an "augmentation" of tunnel-rpc, defined in [TE- computation as an "augmentation" of tunnel-rpc, defined in [TE-
TUNNEL]. This model provides the RPC input attributes that are TUNNEL]. This model provides the RPC input attributes that are
needed to request path computation and the RPC output attributes needed to request path computation and the RPC output attributes
that are needed to report the computed paths. that are needed to report the computed paths.
augment /te:tunnels-rpc/te:input/te:tunnel-info: augment /te:tunnels-rpc/te:input/te:tunnel-info:
+---- path-request* [request-id] +---- path-request* [request-id]
| +---- request-id uint32
........... ...........
augment /te:tunnels-rpc/te:output/te:result:
+--ro response* [response-id] +--ro response* [response-id]
+--ro response-id uint32 +--ro response-id uint32
+--ro (response-type)? +--ro (response-type)?
+--:(no-path-case) +--:(no-path-case)
| +--ro no-path! | +--ro no-path!
+--:(path-case) +--:(path-case)
+--ro computed-path +--ro computed-path
........... ...........
This model extensively re-uses the grouping defined in [TE-TUNNEL] This model extensively re-uses the grouping defined in [TE-TUNNEL]
skipping to change at page 29, line 40 skipping to change at page 32, line 40
5.1. Synchronization of multiple path computation requests 5.1. Synchronization of multiple path computation requests
The YANG model permits to synchronize a set of multiple path The YANG model permits to synchronize a set of multiple path
requests (identified by specific request-id) all related to a "svec" requests (identified by specific request-id) all related to a "svec"
container emulating the syntax of "SVEC" PCEP object [RFC5440]. container emulating the syntax of "SVEC" PCEP object [RFC5440].
+---- synchronization* [synchronization-id] +---- synchronization* [synchronization-id]
+---- synchronization-id uint32 +---- synchronization-id uint32
+---- svec +---- svec
| +---- relaxable? boolean | +---- relaxable? boolean
| +---- disjointness? te-path-disjointness | +---- disjointness? te-types:te-path-disjointness
| +---- request-id-number* uint32 | +---- request-id-number* uint32
+---- svec-constraints +---- svec-constraints
| +---- path-metric-bound* [metric-type] | +---- path-metric-bound* [metric-type]
| +---- metric-type identityref | +---- metric-type identityref
| +---- upper-bound? uint64 | +---- upper-bound? uint64
+---- path-srlgs-lists +---- path-srlgs-values
| +---- path-srlgs-list* [usage] | +---- usage? identityref
| +---- usage identityref | +---- values* srlg
| +---- values* srlg
+---- path-srlgs-names +---- path-srlgs-names
| +---- path-srlgs-name* [usage] | +---- path-srlgs-name* [usage]
| +---- usage identityref | +---- usage identityref
| +---- names* string | +---- srlg-name* [name]
| +---- name string
+---- exclude-objects +---- exclude-objects
........... ...........
+---- optimizations +---- optimizations
+---- (algorithm)? +---- (algorithm)?
+--:(metric) {te-types:path-optimization-metric}? +--:(metric)
| +---- optimization-metric* [metric-type] | +---- optimization-metric* [metric-type]
| +---- metric-type identityref | +---- metric-type identityref
| +---- weight? uint8 | +---- weight? uint8
+--:(objective-function) +--:(objective-function)
{te-types:path-optimization-objective-
function}?
+---- objective-function +---- objective-function
+---- objective-function-type? identityref +---- objective-function-type? identityref
The model, in addition to the metric types, defined in [TE-TUNNEL], The model, in addition to the metric types, defined in [TE-TUNNEL],
which can be applied to each individual path request, defines which can be applied to each individual path request, defines
additional specific metrics types that apply to a set of additional specific metrics types that apply to a set of
synchronized requests, as referenced in [RFC5541]. synchronized requests, as referenced in [RFC5541].
identity svec-metric-type { identity svec-metric-type {
description description
skipping to change at page 31, line 43 skipping to change at page 34, line 42
[RFC5440]: [RFC5440]:
augment /te:tunnels-rpc/te:output/te:result: augment /te:tunnels-rpc/te:output/te:result:
+--ro response* [response-id] +--ro response* [response-id]
+--ro response-id uint32 +--ro response-id uint32
+--ro (response-type)? +--ro (response-type)?
+--:(no-path-case) +--:(no-path-case)
| +--ro no-path! | +--ro no-path!
+--:(path-case) +--:(path-case)
+--ro computed-path +--ro computed-path
+--ro path-id? yang-types:uuid
+--ro path-properties +--ro path-properties
| +--ro path-metric* [metric-type] +--ro path-metric* [metric-type]
| | +--ro metric-type identityref | +--ro metric-type identityref
| | +--ro accumulative-value? uint64 | +--ro accumulative-value? uint64
| +--ro path-affinities-values +--ro path-affinities-values
| | +--ro path-affinities-value* [usage] | +--ro path-affinities-value* [usage]
| | +--ro usage identityref | +--ro usage identityref
| | +--ro value? admin-groups | +--ro value? admin-groups
| +--ro path-affinity-names +--ro path-affinity-names
| | +--ro path-affinity-name* [usage] | +--ro path-affinity-name* [usage]
| | +--ro usage identityref | +--ro usage identityref
| | +--ro affinity-name* [name] | +--ro affinity-name* [name]
| | +--ro name string | +--ro name string
| +--ro path-srlgs-lists +--ro path-srlgs-values
| | +--ro path-srlgs-list* [usage] | +--ro usage? identityref
| | +--ro usage identityref | +--ro values* srlg
| | +--ro values* srlg +--ro path-srlgs-names
| +--ro path-srlgs-names | +--ro path-srlgs-name* [usage]
| | +--ro path-srlgs-name* [usage] | +--ro usage identityref
| | +--ro usage identityref | +--ro srlg-name* [name]
| | +--ro names* string | +--ro name string
| +--ro path-route-objects +--ro path-route-objects
........... ...........
It also allows to request in the input of RPC which information It also allows to request in the input of RPC which information
(metrics, srlg and/or affinities) should be returned: (metrics, srlg and/or affinities) should be returned:
module: ietf-te-path-computation
augment /te:tunnels-rpc/te:input/te:tunnel-info: augment /te:tunnels-rpc/te:input/te:tunnel-info:
+---- path-request* [request-id] +---- path-request* [request-id]
| +---- request-id uint32 | +---- request-id uint32
........... ...........
| +---- requested-metrics* [metric-type] | +---- requested-metrics* [metric-type]
| +---- return-srlgs? boolean | | +---- metric-type identityref
| +---- return-affinities? boolean | +---- return-srlgs? boolean
........... | +---- return-affinities? boolean
...........
This feature is essential for using a stateless path computation in 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, 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 the metrics returned by a path computation requested to a given TE
network controller must be used by the client to compute the best network controller must be used by the client to compute the best
end-to-end path. If they are missing the client cannot compare end-to-end path. If they are missing the client cannot compare
different paths calculated by the TE network controllers and choose different paths calculated by the TE network controllers and choose
the best one for the optimal e2e path. the best one for the optimal e2e path.
6. YANG model for stateless TE path computation 6. YANG model for stateless TE path computation
6.1. YANG Tree 6.1. YANG Tree
Figure 9 below shows the tree diagram of the YANG model defined in Figure 11 below shows the tree diagram of the YANG model defined in
module ietf-te-path-computation.yang. module ietf-te-path-computation.yang.
module: ietf-te-path-computation module: ietf-te-path-computation
augment /te:tunnels-rpc/te:input/te:tunnel-info: augment /te:tunnels-rpc/te:input/te:tunnel-info:
+---- path-request* [request-id] +---- path-request* [request-id]
| +---- request-id uint32 | +---- request-id uint32
| +---- encoding? identityref | +---- encoding? identityref
| +---- switching-type? identityref | +---- switching-type? identityref
| +---- source? inet:ip-address | +---- source? inet:ip-address
| +---- destination? inet:ip-address | +---- destination? inet:ip-address
skipping to change at page 43, line 17 skipping to change at page 46, line 17
+--ro (path)? +--ro (path)?
+--:(primary) +--:(primary)
| +--ro primary-path-ref? leafref | +--ro primary-path-ref? leafref
+--:(secondary) +--:(secondary)
+--ro secondary-path-ref? leafref +--ro secondary-path-ref? leafref
augment /te:tunnels-rpc/te:input/te:tunnel-info: augment /te:tunnels-rpc/te:input/te:tunnel-info:
+---- deleted-paths-transaction-id* string +---- deleted-paths-transaction-id* string
augment /te:tunnels-rpc/te:output/te:result: augment /te:tunnels-rpc/te:output/te:result:
+---- deleted-paths-transaction-id* string +---- deleted-paths-transaction-id* string
Figure 9 - TE path computation YANG tree Figure 11 - TE path computation YANG tree
6.2. YANG Module 6.2. YANG Module
<CODE BEGINS>file "ietf-te-path-computation@2019-03-11.yang" <CODE BEGINS>file "ietf-te-path-computation@2019-03-11.yang"
module ietf-te-path-computation { module ietf-te-path-computation {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-te-path-computation"; namespace "urn:ietf:params:xml:ns:yang:ietf-te-path-computation";
// replace with IANA namespace when assigned // replace with IANA namespace when assigned
prefix "tepc"; prefix "tepc";
skipping to change at page 58, line 20 skipping to change at page 61, line 20
leaf-list deleted-paths-transaction-id { leaf-list deleted-paths-transaction-id {
type string; type string;
description description
"The list of the transaction-id values of the "The list of the transaction-id values of the
transient states that have been successfully deleted"; transient states that have been successfully deleted";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
Figure 10 - TE path computation YANG module Figure 12 - TE path computation YANG module
7. Security Considerations 7. Security Considerations
This document describes use cases of requesting Path Computation This document describes use cases of requesting Path Computation
using YANG models, which could be used at the ABNO Control Interface using YANG models, which could be used at the ABNO Control Interface
[RFC7491] and/or between controllers in ACTN [RFC8453]. As such, it [RFC7491] and/or between controllers in ACTN [RFC8453]. As such, it
does not introduce any new security considerations compared to the does not introduce any new security considerations compared to the
ones related to YANG specification, ABNO specification and ACTN ones related to YANG specification, ABNO specification and ACTN
Framework defined in [RFC7950], [RFC7491] and [RFC8453]. Framework defined in [RFC7950], [RFC7491] and [RFC8453].
skipping to change at page 59, line 39 skipping to change at page 62, line 39
9.1. Normative References 9.1. Normative References
[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January
2004. 2004.
[RFC5440] Vasseur, JP., Le Roux, JL. et al., "Path Computation [RFC5440] Vasseur, JP., Le Roux, JL. et al., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009. 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 [RFC5541] Le Roux, JL. et al., " Encoding of Objective Functions in
the Path Computation Element Communication Protocol the Path Computation Element Communication Protocol
(PCEP)", RFC 5541, June 2009. (PCEP)", RFC 5541, June 2009.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, June 2011. (NETCONF)", RFC 6241, June 2011.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011. Shell (SSH)", RFC 6242, June 2011.
skipping to change at page 60, line 46 skipping to change at page 64, line 10
[TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic
Engineering Tunnels and Interfaces", draft-ietf-teas-yang- Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
te, work in progress. te, work in progress.
9.1. Informative References 9.1. Informative References
[RFC4655] Farrel, A. et al., "A Path Computation Element (PCE)-Based [RFC4655] Farrel, A. et al., "A Path Computation Element (PCE)-Based
Architecture", RFC 4655, August 2006. 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 [RFC7139] Zhang, F. et al., "GMPLS Signaling Extensions for Control
of Evolving G.709 Optical Transport Networks", RFC 7139, of Evolving G.709 Optical Transport Networks", RFC 7139,
March 2014. March 2014.
[RFC7446] Lee, Y. et al., "Routing and Wavelength Assignment [RFC7446] Lee, Y. et al., "Routing and Wavelength Assignment
Information Model for Wavelength Switched Optical Information Model for Wavelength Switched Optical
Networks", RFC 7446, February 2015. Networks", RFC 7446, February 2015.
[RFC8233] Dhody, D. et al., "Extensions to the Path Computation [RFC8233] Dhody, D. et al., "Extensions to the Path Computation
Element Communication Protocol (PCEP) to Compute Service- Element Communication Protocol (PCEP) to Compute Service-
skipping to change at page 67, line 33 skipping to change at page 72, line 4
Ericsson Ericsson
Email: gianmarco.bruno@ericsson.com Email: gianmarco.bruno@ericsson.com
Francesco Lazzeri Francesco Lazzeri
Ericsson Ericsson
Email: francesco.lazzeri@ericsson.com Email: francesco.lazzeri@ericsson.com
Young Lee Young Lee
Huawei Huawei
Email: leeyoung@huawei.com Email: leeyoung@huawei.com
Carlo Perocchio Carlo Perocchio
Ericsson Ericsson
Email: carlo.perocchio@ericsson.com 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 Authors' Addresses
Italo Busi (Editor) Italo Busi (Editor)
Huawei Huawei
Email: italo.busi@huawei.com Email: italo.busi@huawei.com
Sergio Belotti (Editor) Sergio Belotti (Editor)
Nokia Nokia
Email: sergio.belotti@nokia.com Email: sergio.belotti@nokia.com
Victor Lopez Victor Lopez
Telefonica Telefonica
Email: victor.lopezalvarez@telefonica.com Email: victor.lopezalvarez@telefonica.com
Oscar Gonzalez de Dios Oscar Gonzalez de Dios
Telefonica Telefonica
 End of changes. 39 change blocks. 
93 lines changed or deleted 232 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/