draft-ietf-teas-yang-te-topo-21.txt | draft-ietf-teas-yang-te-topo-22.txt | |||
---|---|---|---|---|
skipping to change at page 1, line 14 ¶ | skipping to change at page 1, line 14 ¶ | |||
Intended status: Standards Track Igor Bryskin | Intended status: Standards Track Igor Bryskin | |||
Huawei Technologies | Huawei Technologies | |||
Vishnu Pavan Beeram | Vishnu Pavan Beeram | |||
Tarek Saad | Tarek Saad | |||
Juniper Networks | Juniper Networks | |||
Himanshu Shah | Himanshu Shah | |||
Ciena | Ciena | |||
Oscar Gonzalez De Dios | Oscar Gonzalez De Dios | |||
Telefonica | Telefonica | |||
Expires: November 23, 2019 May 23, 2019 | Expires: December 19, 2019 June 19, 2019 | |||
YANG Data Model for Traffic Engineering (TE) Topologies | YANG Data Model for Traffic Engineering (TE) Topologies | |||
draft-ietf-teas-yang-te-topo-21 | draft-ietf-teas-yang-te-topo-22 | |||
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 1, line 40 ¶ | skipping to change at page 1, line 40 ¶ | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | 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 November 23, 2019. | This Internet-Draft will expire on December 19, 2019. | |||
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 9, line 5 ¶ | skipping to change at page 9, line 5 ¶ | |||
and encapsulated into a server layer signal [RFC5212] [G.805]. The | and encapsulated into a server layer signal [RFC5212] [G.805]. The | |||
server layer signal can be carried in the server layer network across | server layer signal can be carried in the server layer network across | |||
multiple nodes until the server layer signal is terminated and the | multiple nodes until the server layer signal is terminated and the | |||
client layer signals reappear in the node that terminates the server | client layer signals reappear in the node that terminates the server | |||
layer signal. Examples of multi-layer networks are: IP over MPLS over | layer signal. Examples of multi-layer networks are: IP over MPLS over | |||
Ethernet, low order Optical Data Unit-k (ODUk) signals multiplexed | Ethernet, low order Optical Data Unit-k (ODUk) signals multiplexed | |||
into a high order ODUl (l>k) carried over an Optical Channel (OCh) | into a high order ODUl (l>k) carried over an Optical Channel (OCh) | |||
signal in an optical transport network as defined in [G.872] and | signal in an optical transport network as defined in [G.872] and | |||
[G.709]. | [G.709]. | |||
TE links as defined in 3.3. can be used to represent links within a | TE links as defined in Section 3.3. can be used to represent links | |||
network layer. In case of a multi-layer network, TE nodes and TE | within a network layer. In case of a multi-layer network, TE nodes | |||
links only allow representation of each network layer as a separate | and TE links only allow representation of each network layer as a | |||
TE topology. Each of these single layer TE topologies would be | separate TE topology. Each of these single layer TE topologies would | |||
isolated from their client and their server layer TE topology, if | be isolated from their client and their server layer TE topology, if | |||
present. The highest and the lowest network layer in the hierarchy | present. The highest and the lowest network layer in the hierarchy | |||
only have a single adjacent layer below or above, respectively. | only have a single adjacent layer below or above, respectively. | |||
Multiplexing of client layer signals and encapsulating them into a | Multiplexing of client layer signals and encapsulating them into a | |||
server layer signal requires a function that is provided inside a | server layer signal requires a function that is provided inside a | |||
node (typically realized in hardware). This function is also called | node (typically realized in hardware). This function is also called | |||
layer transition. | layer transition. | |||
One of the key requirements for path computation is to be able to | One of the key requirements for path computation is to be able to | |||
calculate a path between two endpoints across a multi-layer network | calculate a path between two endpoints across a multi-layer network | |||
based on the TE topology representing this multi-layer network. This | based on the TE topology representing this multi-layer network. This | |||
skipping to change at page 18, line 40 ¶ | skipping to change at page 18, line 40 ¶ | |||
Figure 8c: Customized TE Topology merged with the Client's Native TE | Figure 8c: Customized TE Topology merged with the Client's Native TE | |||
Topology | Topology | |||
The data model proposed in this document can be used to | The data model proposed in this document can be used to | |||
retrieve/represent/manipulate the customized TE Topology depicted in | retrieve/represent/manipulate the customized TE Topology depicted in | |||
Figure 8b. | Figure 8b. | |||
A customized TE topology is not necessarily an abstract TE topology. | A customized TE topology is not necessarily an abstract TE topology. | |||
The provider may produce, for example, an abstract TE topology of | The provider may produce, for example, an abstract TE topology of | |||
certain type (e.g. single-abstract-node-with-connectivit-matrix | certain type (e.g. single-abstract-node-with-connectivity-matrix | |||
topology, a border_nodes_connected_via_mesh_of_abstract_links | topology, a border-nodes-connected-via-mesh-of-abstract-links | |||
topology, etc.) and expose it to all/some clients in expectation that | topology, etc.) and expose it to all/some clients in expectation that | |||
the clients will use it without customization. | the clients will use it without customization. | |||
On the other hand, a client may request a customized version of the | On the other hand, a client may request a customized version of the | |||
provider's native TE topology (e.g. by requesting removal of TE links | provider's native TE topology (e.g. by requesting removal of TE links | |||
which belong to certain layers, are too slow, not protected and/or | which belong to certain layers, are too slow, not protected and/or | |||
have a certain affinity). Note that the resulting TE topology will | have a certain affinity). Note that the resulting TE topology will | |||
not be abstract (because it will not contain abstract elements), but | not be abstract (because it will not contain abstract elements), but | |||
customized (modified upon client's instructions). | customized (modified upon client's instructions). | |||
The client ID field in the TE topology identifier (Section 5.4. ) | The client ID field in the TE topology identifier (Section 5.4. ) | |||
indicates which client the TE topology is customized for. Although a | indicates which client the TE topology is customized for. Although an | |||
authorized client MAY receive a TE topology with the client ID field | authorized client MAY receive a TE topology with the client ID field | |||
matching some other client, the client can customize only TE | matching some other client, the client can customize only TE | |||
topologies with the client ID field either 0 or matching the ID of | topologies with the client ID field either 0 or matching the ID of | |||
the client in question. If the client starts reconfiguration of a | the client in question. If the client starts reconfiguration of a | |||
topology its client ID will be automatically set in the topology ID | topology its client ID will be automatically set in the topology ID | |||
field for all future configurations and updates wrt. the topology in | field for all future configurations and updates wrt. the topology in | |||
question. | question. | |||
The provider MAY tell the client that a given TE topology cannot be | The provider MAY tell the client that a given TE topology cannot be | |||
re-negotiated, by setting its own (provider's) ID in the client ID | re-negotiated, by setting its own (provider's) ID in the client ID | |||
field of the topology ID. | field of the topology ID. | |||
Even though this data model allows to access TE topology information | ||||
across clients, implementations MAY restrict access for particular | ||||
clients to particular data fields. The Network Configuration Access | ||||
Control Model (NACM) [RFC8341] provides such a mechanism. | ||||
4.3. Merging TE Topologies Provided by Multiple Providers | 4.3. Merging TE Topologies Provided by Multiple Providers | |||
A client may receive TE topologies provided by multiple providers, | A client may receive TE topologies provided by multiple providers, | |||
each of which managing a separate domain of multi-domain network. In | each of which managing a separate domain of multi-domain network. In | |||
order to make use of said topologies, the client is expected to merge | order to make use of said topologies, the client is expected to merge | |||
the provided TE topologies into one or more client's native TE | the provided TE topologies into one or more client's native TE | |||
topologies, each of which homogeneously representing the multi-domain | topologies, each of which homogeneously representing the multi-domain | |||
network. This makes it possible for the client to select end-to-end | network. This makes it possible for the client to select end-to-end | |||
TE paths for its services traversing multiple domains. | TE paths for its services traversing multiple domains. | |||
skipping to change at page 29, line 30 ¶ | skipping to change at page 29, line 30 ¶ | |||
| +--ro path-properties | | +--ro path-properties | |||
........... | ........... | |||
+--rw supporting-tunnel-termination-point* [node-ref tunnel-tp- | +--rw supporting-tunnel-termination-point* [node-ref tunnel-tp- | |||
ref] | ref] | |||
+--rw node-ref inet:uri | +--rw node-ref inet:uri | |||
+--rw tunnel-tp-ref binary | +--rw tunnel-tp-ref binary | |||
The attributes directly under container connectivity-matrices are the | The attributes directly under container connectivity-matrices are the | |||
default attributes for all connectivity-matrix entries when the per | default attributes for all connectivity-matrix entries when the per | |||
entry corresponding attribute is not specified. When a per entry | entry corresponding attribute is not specified. When a per entry | |||
attribute is specified, it overrides the cooresponding attribute | attribute is specified, it overrides the corresponding attribute | |||
directly under the container connectivity-matrices. The same rule | directly under the container connectivity-matrices. The same rule | |||
applies to the attributes directly under container local-link- | applies to the attributes directly under container local-link- | |||
connectivities. | connectivities. | |||
Each TTP (Tunnel Termination Point) MAY be supported by one or more | Each TTP (Tunnel Termination Point) MAY be supported by one or more | |||
supporting TTPs. If the TE node hosting the TTP in question refers to | supporting TTPs. If the TE node hosting the TTP in question refers to | |||
a supporting TE node, then the supporting TTPs are hosted by the | a supporting TE node, then the supporting TTPs are hosted by the | |||
supporting TE node. If the TE node refers to an underlay TE topology, | supporting TE node. If the TE node refers to an underlay TE topology, | |||
the supporting TTPs are hosted by one or more specified TE nodes of | the supporting TTPs are hosted by one or more specified TE nodes of | |||
the underlay TE topology. | the underlay TE topology. | |||
skipping to change at page 32, line 32 ¶ | skipping to change at page 32, line 32 ¶ | |||
+--rw name | +--rw name | |||
| te-types:te-template-name | | te-types:te-template-name | |||
+--rw priority? uint16 | +--rw priority? uint16 | |||
+--rw reference-change-policy? enumeration | +--rw reference-change-policy? enumeration | |||
+--rw te-link-attributes | +--rw te-link-attributes | |||
.......... | .......... | |||
Multiple templates can be specified to a configuration element. When | Multiple templates can be specified to a configuration element. When | |||
two or more templates specify values for the same configuration | two or more templates specify values for the same configuration | |||
field, the value from the template with the highest priority is used. | field, the value from the template with the highest priority is used. | |||
The reference-change-policy specifies the action that needs to be | The range of the priority is from 0 to 65535, with a lower number | |||
taken when the template changes on a configuration element that has a | indicating a higher priority. The reference-change-policy specifies | |||
reference to this template. The choices of action include taking no | the action that needs to be taken when the template changes on a | |||
action, rejecting the change to the template and applying the change | configuration element that has a reference to this template. The | |||
to the corresponding configuration. | choices of action include taking no action, rejecting the change to | |||
the template and applying the change to the corresponding | ||||
configuration. | ||||
5.10. Scheduling Parameters | 5.10. Scheduling Parameters | |||
The model allows time scheduling parameters to be specified for each | The model allows time scheduling parameters to be specified for each | |||
topological element or for the topology as a whole. These parameters | topological element or for the topology as a whole. These parameters | |||
allow the provider to present different topological views to the | allow the provider to present different topological views to the | |||
client at different time slots. The use of "scheduling parameters" is | client at different time slots. The use of "scheduling parameters" is | |||
optional. | optional. | |||
The YANG data model for configuration scheduling is defined in | The YANG data model for configuration scheduling is defined in | |||
skipping to change at page 87, line 11 ¶ | skipping to change at page 87, line 11 ¶ | |||
grouping template-attributes { | grouping template-attributes { | |||
description | description | |||
"Common attributes for all templates."; | "Common attributes for all templates."; | |||
leaf priority { | leaf priority { | |||
type uint16; | type uint16; | |||
description | description | |||
"The preference value to resolve conflicts between different | "The preference value to resolve conflicts between different | |||
templates. When two or more templates specify values for | templates. When two or more templates specify values for | |||
one configuration attribute, the value from the template | one configuration attribute, the value from the template | |||
with the highest priority is used."; | with the highest priority is used. | |||
A lower number indicates a higher priority. The highest | ||||
priority is 0."; | ||||
} | } | |||
leaf reference-change-policy { | leaf reference-change-policy { | |||
type enumeration { | type enumeration { | |||
enum no-action { | enum no-action { | |||
description | description | |||
"When an attribute changes in this template, the | "When an attribute changes in this template, the | |||
configuration node referring to this template does | configuration node referring to this template does | |||
not take any action."; | not take any action."; | |||
} | } | |||
enum not-allowed { | enum not-allowed { | |||
End of changes. 10 change blocks. | ||||
18 lines changed or deleted | 27 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/ |