--- 1/draft-ietf-teas-yang-te-topo-21.txt 2019-06-19 07:13:22.398451385 -0700 +++ 2/draft-ietf-teas-yang-te-topo-22.txt 2019-06-19 07:13:22.798461498 -0700 @@ -3,24 +3,24 @@ Intended status: Standards Track Igor Bryskin Huawei Technologies Vishnu Pavan Beeram Tarek Saad Juniper Networks Himanshu Shah Ciena Oscar Gonzalez De Dios Telefonica -Expires: November 23, 2019 May 23, 2019 +Expires: December 19, 2019 June 19, 2019 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 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. @@ -29,21 +29,21 @@ 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 - This Internet-Draft will expire on November 23, 2019. + This Internet-Draft will expire on December 19, 2019. 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 @@ -341,25 +341,25 @@ and encapsulated into a server layer signal [RFC5212] [G.805]. The server layer signal can be carried in the server layer network across multiple nodes until the server layer signal is terminated and the client layer signals reappear in the node that terminates the server layer signal. Examples of multi-layer networks are: IP over MPLS over Ethernet, low order Optical Data Unit-k (ODUk) signals multiplexed 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 [G.709]. - TE links as defined in 3.3. can be used to represent links within a - network layer. In case of a multi-layer network, TE nodes and TE - links only allow representation of each network layer as a separate - TE topology. Each of these single layer TE topologies would be - isolated from their client and their server layer TE topology, if + TE links as defined in Section 3.3. can be used to represent links + within a network layer. In case of a multi-layer network, TE nodes + and TE links only allow representation of each network layer as a + separate TE topology. Each of these single layer TE topologies would + be isolated from their client and their server layer TE topology, if present. The highest and the lowest network layer in the hierarchy only have a single adjacent layer below or above, respectively. Multiplexing of client layer signals and encapsulating them into a server layer signal requires a function that is provided inside a node (typically realized in hardware). This function is also called layer transition. One of the key requirements for path computation is to be able to calculate a path between two endpoints across a multi-layer network based on the TE topology representing this multi-layer network. This @@ -783,45 +783,50 @@ Figure 8c: Customized TE Topology merged with the Client's Native TE Topology The data model proposed in this document can be used to retrieve/represent/manipulate the customized TE Topology depicted in Figure 8b. A customized TE topology is not necessarily an abstract TE topology. The provider may produce, for example, an abstract TE topology of - certain type (e.g. single-abstract-node-with-connectivit-matrix - topology, a border_nodes_connected_via_mesh_of_abstract_links + certain type (e.g. single-abstract-node-with-connectivity-matrix + topology, a border-nodes-connected-via-mesh-of-abstract-links topology, etc.) and expose it to all/some clients in expectation that the clients will use it without customization. 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 which belong to certain layers, are too slow, not protected and/or have a certain affinity). Note that the resulting TE topology will not be abstract (because it will not contain abstract elements), but customized (modified upon client's instructions). 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 matching some other client, the client can customize only TE topologies with the client ID field either 0 or matching the ID of the client in question. If the client starts reconfiguration of a topology its client ID will be automatically set in the topology ID field for all future configurations and updates wrt. the topology in question. 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 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 A client may receive TE topologies provided by multiple providers, 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 the provided TE topologies into one or more client's native TE topologies, each of which homogeneously representing the multi-domain network. This makes it possible for the client to select end-to-end TE paths for its services traversing multiple domains. @@ -1221,21 +1226,21 @@ | +--ro path-properties ........... +--rw supporting-tunnel-termination-point* [node-ref tunnel-tp- ref] +--rw node-ref inet:uri +--rw tunnel-tp-ref binary The attributes directly under container connectivity-matrices are the default attributes for all connectivity-matrix entries when the per 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 applies to the attributes directly under container local-link- connectivities. 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 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, the supporting TTPs are hosted by one or more specified TE nodes of the underlay TE topology. @@ -1364,25 +1369,27 @@ +--rw name | te-types:te-template-name +--rw priority? uint16 +--rw reference-change-policy? enumeration +--rw te-link-attributes .......... Multiple templates can be specified to a configuration element. When two or more templates specify values for the same configuration field, the value from the template with the highest priority is used. - The reference-change-policy specifies the action that needs to be - taken when the template changes on a configuration element that has a - reference to this template. The choices of action include taking no - action, rejecting the change to the template and applying the change - to the corresponding configuration. + The range of the priority is from 0 to 65535, with a lower number + indicating a higher priority. The reference-change-policy specifies + the action that needs to be taken when the template changes on a + configuration element that has a reference to this template. The + 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 The model allows time scheduling parameters to be specified for each topological element or for the topology as a whole. These parameters allow the provider to present different topological views to the client at different time slots. The use of "scheduling parameters" is optional. The YANG data model for configuration scheduling is defined in @@ -3620,21 +3627,23 @@ grouping template-attributes { description "Common attributes for all templates."; leaf priority { type uint16; description "The preference value to resolve conflicts between different templates. When two or more templates specify values for 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 { type enumeration { enum no-action { description "When an attribute changes in this template, the configuration node referring to this template does not take any action."; } enum not-allowed {