--- 1/draft-ietf-teas-yang-te-topo-03.txt 2016-03-21 14:21:38.327146009 -0700 +++ 2/draft-ietf-teas-yang-te-topo-04.txt 2016-03-21 14:21:38.839158763 -0700 @@ -4,68 +4,68 @@ Huawei Technologies Vishnu Pavan Beeram Juniper Networks Tarek Saad Cisco Systems Inc Himanshu Shah Ciena Oscar Gonzalez De Dios Telefonica -Expires: September 20, 2016 March 20, 2016 +Expires: September 21, 2016 March 21, 2016 YANG Data Model for TE Topologies - draft-ietf-teas-yang-te-topo-03 + draft-ietf-teas-yang-te-topo-04 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." + 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 - This Internet-Draft will expire on September 20, 2016. + This Internet-Draft will expire on September 21, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with - respect to this document. Code Components extracted from this - document must include Simplified BSD License text as described in - Section 4.e of the Trust Legal Provisions and are provided without - warranty as described in the Simplified BSD License. + 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 This document defines a YANG data model for representing, retrieving - and manipulating TE Topologies. The model serves as a base model - that other technology specific TE Topology models can augment. + and manipulating TE Topologies. The model serves as a base model that + other technology specific TE Topology models can augment. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Table of Contents 1. Introduction...................................................3 @@ -99,26 +99,26 @@ 5.8. Overlay/Underlay Relationship............................20 5.9. Scheduling Parameters....................................22 5.10. Templates...............................................22 5.11. Notifications...........................................23 5.12. Open Items..............................................23 6. Tree Structure................................................23 6.1. Base TE Topology Module..................................23 6.2. Packet Switching TE Topology Module......................49 7. TE Topology Yang Modules......................................50 7.1. Base TE Topology Module..................................50 - 7.2. Packet Switching TE Topology Module......................95 - 8. Security Considerations.......................................99 - 9. IANA Considerations...........................................99 + 7.2. Packet Switching TE Topology Module......................94 + 8. Security Considerations.......................................98 + 9. IANA Considerations...........................................98 10. References...................................................99 10.1. Normative References....................................99 - 10.2. Informative References.................................100 + 10.2. Informative References..................................99 11. Acknowledgments.............................................100 Contributors....................................................100 Authors' Addresses..............................................100 1. Introduction The Traffic Engineering Database (TED) is an essential component of Traffic Engineered (TE) systems that are based on MPLS-TE [RFC2702] and GMPLS [RFC3945]. The TED is a collection of all TE information about all TE nodes and TE links in the network. The TE Topology is a @@ -168,31 +168,31 @@ o for obsolete is one of: rw for read-write configuration data ro for read-only non-configuration data -x for execution rpcs -n for notifications is the name of the node - If the node is augmented into the tree from another module, - its name is printed as : + If the node is augmented into the tree from another module, its + name is printed as : is one of: ? for an optional leaf or node ! for a presence container * for a leaf-list or list Brackets [] for a list's keys - Curly braces {} for optional feature that make - node conditional + Curly braces {} for optional feature that make node + conditional Colon : for marking case nodes Ellipses ("...") subtree contents not shown Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). is the name of the type for leafs and leaf-lists. 1.3. Prefixes in Data Node Names @@ -304,44 +304,44 @@ 3.3. TE Link TE link is an element of a TE topology (presented as an edge on TE graph, arrows indicate one or both directions of the TE link). TE link represents one or several (physical) links or a fraction of a link. TE link belongs to and is fully defined in exactly one TE topology. TE link is assigned with the TE topology scope unique ID. TE link attributes include parameters related to the data plane aspects of the associated link(s) (e.g. unreserved bandwidth, resource maps/pools, etc.), as well as the configuration data (such - as remote node/link IDs, SRLGs, administrative colors, etc.). TE - link is connected to TE node, terminating the TE link via exactly - one TE link termination point (LTP). + as remote node/link IDs, SRLGs, administrative colors, etc.). TE link + is connected to TE node, terminating the TE link via exactly one TE + link termination point (LTP). In Figure 1, Link-12 and Link-23 are TE links. 3.4. TE Link Termination Point (LTP) TE link termination point (LTP) is a conceptual point of connection of a TE node to one of the TE links, terminated by the TE node. Cardinality between an LTP and the associated TE link is 1:0..1. In Figure 1, Node-2 has six LTPs: LTP-1 to LTP-6. 3.5. TE Tunnel Termination Point (TTP) TE tunnel termination point (TTP) is an element of TE topology representing one or several of potential transport service termination points (i.e. service client adaptation points such as WDM/OCh transponder). TTP is associated with (hosted by) exactly one TE node. TTP is assigned with the TE node scope unique ID. Depending on the TE node's internal constraints, a given TTP hosted by the TE - node could be accessed via one, several or all TE links terminated - by the TE node. + node could be accessed via one, several or all TE links terminated by + the TE node. In Figure 1, Node-1 has two TTPs: TTP-1 and TTP-2. 3.6. TE Node Connectivity Matrix TE node connectivity matrix is a TE node's attribute describing the TE node's switching limitations in a form of valid switching combinations of the TE node's LTPs (see below). From the point of view of a potential TE path arriving at the TE node at a given inbound LTP, the node's connectivity matrix describes valid @@ -349,22 +349,22 @@ from. In Figure 1, the connectivity matrix on Node-2 is: {, , , , } 3.7. TTP Local Link Connectivity List (LLCL) TTP Local Link Connectivity List (LLCL) is a List of TE links terminated by the TTP hosting TE node (i.e. list of the TE link - LTPs), which the TTP could be connected to. From the point of view - of a potential TE path LLCL provides a list of valid TE links the TE + LTPs), which the TTP could be connected to. From the point of view of + a potential TE path LLCL provides a list of valid TE links the TE path needs to start/stop on for the connection, taking the TE path, to be successfully terminated on the TTP in question. In Figure 1, the LLCL on Node-1 is: {, , , } 3.8. TE Path TE path is an ordered list of TE links and/or TE nodes on the TE topology graph, inter-connecting a pair of TTPs to be taken by a @@ -374,34 +374,34 @@ In Figure 1, the TE Path for TE-Tunnel-1 is: {Node-1:TTP-1, Link-12, Node-2, Link-23, Node-3:TTP1} 3.9. Underlay TE topology Underlay TE topology is a TE topology that serves as a base for constructing of overlay TE topologies 3.10. Overlay TE topology - Overlay TE topology is a TE topology constructed based on one or - more underlay TE topologies. Each TE node of the overlay TE topology + Overlay TE topology is a TE topology constructed based on one or more + underlay TE topologies. Each TE node of the overlay TE topology represents an arbitrary segment of an underlay TE topology; each TE link of the overlay TE topology represents an arbitrary TE path in one of the underlay TE topologies. The overlay TE topology and the supporting underlay TE topologies may represent distinct layer networks (e.g. OTN/ODUk and WDM/OCh respectively) or the same layer network. 3.11. Abstract TE topology Abstract TE topology is an overlay TE topology created by a topology - provider and customized for a topology provider's client based on - one or more of the provider's native TE topologies (underlay TE + provider and customized for a topology provider's client based on one + or more of the provider's native TE topologies (underlay TE topologies), the provider's policies and the client's preferences. For example, a first level topology provider (such as Domain Controller) can create an abstract TE topology for its client (e.g. Super Controller) based on the provider's one or more native TE topologies, local policies/profiles and the client's TE topology configuration requests Figure 2 shows an example of abstract TE topology. +---+ +---+ @@ -475,23 +475,23 @@ + + ++ ++ [R6] +++++++++ [R7] [R8] ++++ [R9] Figure 3b: Native TE Topology as seen on Node R3 Consider the case of the topology being split in a way that some nodes participate in OSPF-TE while others participate in ISIS-TE (Figure 4a). An implementation MAY choose to construct separate TE Topologies based on the information source. The native TE Topologies constructed using only nodes and links that were learnt via a - specific information source are depicted in Figure 4b. The data - model proposed in this document can be used to retrieve/represent - these TE topologies. + specific information source are depicted in Figure 4b. The data model + proposed in this document can be used to retrieve/represent these TE + topologies. Similarly, the data model can be used to represent/retrieve a TE Topology that is constructed using only nodes and links that belong to a particular technology layer. The data model is flexible enough to retrieve and represent many such native TE Topologies. : TE info distributed via ISIS-TE : TE info distributed via OSPF-TE : +---+ +---+ +---+ +---+ +---+ @@ -520,23 +520,22 @@ + + : ++ ++ [R6] +++++++++ [R7] : [R8] ++++ [R9] Figure 4b: Native TE Topologies as seen on Node R3 4.2. Customized TE Topologies The model discussed in this draft can be used to represent, retrieve and manipulate customized TE Topologies. The model allows the provider to present the network in abstract TE Terms on a per client - basis. These customized topologies contain sufficient information - for the path computing client to select paths according to its - policies. + basis. These customized topologies contain sufficient information for + the path computing client to select paths according to its policies. | +---+ /-\ | | | Router ( ) WDM | +---+ Node \-/ node | o---------------------------- +---+ /-\ /-\ /-\ +---+ | R1|-------( A )--------( C )---------( E )---------| R3| +---+ \-/ \-/ \-/ +---+ @@ -544,27 +543,27 @@ / \ / \ / \ / \ / \ / \ / \ / \ +---+ /-\ /-\ /-\ +---+ | R2|---------( B )---------( D )---------( F )---------| R4| +---+ \-/ \-/ \-/ +---+ Figure 5: Example packet optical topology - Consider the network topology depicted in Figure 5. This is a - typical packet optical transport deployment scenario where the WDM - layer network domain serves as a Server Network Domain providing - transport connectivity to the packet layer network Domain (Client - Network Domain). Nodes R1, R2, R3 and R4 are IP routers that are - connected to an Optical WDM transport network. A, B, C, D, E and F - are WDM nodes that constitute the Server Network Domain. + Consider the network topology depicted in Figure 5. This is a typical + packet optical transport deployment scenario where the WDM layer + network domain serves as a Server Network Domain providing transport + connectivity to the packet layer network Domain (Client Network + Domain). Nodes R1, R2, R3 and R4 are IP routers that are connected to + an Optical WDM transport network. A, B, C, D, E and F are WDM nodes + that constitute the Server Network Domain. | ***** B-F WDM Path | @@@@@ B-E WDM Path | $$$$$ A-E WDM Path o-------------------- +---+ /-\ $$$$$$$$ /-\ $$$$$$$$$ /-\ +---+ | R1|-------( A )--------( C )---------( E )---------| R3| +---+ \-/ @\-/ @@@@@@@@@ \-/ +---+ @/ \ / \ @@ -608,22 +607,21 @@ The data model proposed in this document can be used to retrieve/represent/manipulate the customized TE Topology depicted in Figure 6b. 5. Modeling Considerations 5.1. Generic network topology building blocks The generic network topology building blocks are discussed in [YANG- NET-TOPO]. The TE Topology model proposed in this document augments - and uses the ietf-network-topology module defined in [YANG-NET- - TOPO]. + and uses the ietf-network-topology module defined in [YANG-NET-TOPO]. +------------------------+ | Generic | | Network Topology Model | | (ietf-network-topology)| +------------------------+ | | | V @@ -631,23 +629,22 @@ | TE Topology | | Model | | | +------------------------+ Figure 7: Augmenting the Generic Network Topology Model 5.2. Technology agnostic TE Topology model The TE Topology model proposed in this document is meant to be - technology agnostic. Other technology specific TE Topology models - can augment and use the building blocks provided by the proposed - model. + technology agnostic. Other technology specific TE Topology models can + augment and use the building blocks provided by the proposed model. +-------------------+ | Generic | | TE Topology Model | +-------------------+ | +-------------+-------------+-------------+ | | | | V V V V +------------+ +------------+ @@ -788,24 +786,24 @@ +--ro termination-capability* [link-tp] | +--ro link-tp leafref +--ro switching-capability identityref +--ro encoding identityref 5.7. TED Information Sources The model allows each TE topological element to have multiple TE information sources (OSPF-TE, ISIS-TE, BGP-LS, User-Configured, System-Processed, Other). Each information source is associated with - a credibility preference to indicate precedence. In scenarios where - a customized TE Topology is merged into a Client's native TE - Topology, the merged topological elements would point to the - corresponding customized TE Topology as its information source. + a credibility preference to indicate precedence. In scenarios where a + customized TE Topology is merged into a Client's native TE Topology, + the merged topological elements would point to the corresponding + customized TE Topology as its information source. augment /nw:networks/nw:network/nw:node: +--rw te! ........... +--ro state ........ +--ro information-source? enumeration +--ro information-source-state +--ro credibility-preference? uint16 +--ro topology @@ -831,22 +829,22 @@ | +--ro routing-instance? string +--ro alt-information-sources* [information-source] | ............ 5.8. Overlay/Underlay Relationship The model captures overlay and underlay relationship for TE nodes/links. For example - in networks where multiple TE Topologies are built hierarchically, this model allows the user to start from a specific topological element in the top most topology and traverse - all the way down to the supporting topological elements in the - bottom most topology. + all the way down to the supporting topological elements in the bottom + most topology. This relationship is captured via the "underlay-topology" field for the node and via the "underlay" field for the link. The use of these fields is optional and this functionality is tagged as a "feature" ("te-topology-hierarchy"). augment /nw:networks/nw:network/nw:node: +--rw te! +--rw te-node-id te-node-id +--rw config @@ -886,81 +884,81 @@ | | | ........... | | | +--rw network-ref? leafref | | +--rw underlay-trail-des | | ........... 5.9. 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 and this functionality is tagged as a "feature" + client at different time slots. The use of "scheduling parameters" is + optional and this functionality is tagged as a "feature" ("configuration-schedule"). The YANG data model for configuration scheduling is defined in [YANG-SCHEDULE] and imported by the TE Topology module. 5.10. Templates The data model provides the users with the ability to define templates and apply them to link and node configurations. The use of - "template" configuration is optional and this functionality is - tagged as a "feature" ("template"). + "template" configuration is optional and this functionality is tagged + as a "feature" ("template"). +--rw topology* [provider-id client-id te-topology-id] | ........... | +--rw node* [te-node-id] | | +--rw te-node-template? leafref {template}? | | .......... - | +--rw link* [source-te-node-id source-te-link-id dest-te-node- - id dest-te-link-id] + | +--rw link* [source-te-node-id source-te-link-id dest-te-node-id + dest-te-link-id] | +--rw te-link-template? leafref {template}? | .......... +--rw node-template* [name] {template}? | +--rw name te-template-name | +--rw priority? uint16 | +--rw reference-change-policy? enumeration | +--rw te-node-attributes | .......... +--rw link-template* [name] {template}? +--rw name 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. [Editor's Note: The - notion of "templates" has wider applicability. It is possible for - this to be discussed in a separate document.] + 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. [Editor's Note: The notion of + "templates" has wider applicability. It is possible for this to be + discussed in a separate document.] 5.11. Notifications Notifications are a key component of any topology data model. [YANG-PUSH] defines a subscription and push mechanism for YANG datastores. This mechanism currently allows the user to: - Subscribe notifications on a per client basis - Specify subtree filters or xpath filters so that only interested contents will be sent. - Specify either periodic or on-demand notifications. - The authors would like to recommend the use of this mechanism for - the TE-Topology notifications. They would also like to suggest the + The authors would like to recommend the use of this mechanism for the + TE-Topology notifications. They would also like to suggest the following extensions to [YANG-PUSH] - Specify specific entities that will trigger the push notifications. These entities can be specified by xpath, like the way a filter is specified. - Specify or limit the triggering event type, e.g. "add", "delete", "modify", or "all". The system sends the push notifications only when such events happen on the triggering entities. @@ -1080,28 +1078,24 @@ | | +--rw node-ref? leafref | | +--rw network-ref? leafref | +--rw underlay-trail-des | +--rw tp-ref? leafref | +--rw node-ref? leafref | +--rw network-ref? leafref +--rw admin-status? te-admin- status +--rw performance-metric-throttle {te-performance- metric}? - | +--rw unidirectional-delay-offset? - uint32 - | +--rw measure-interval? - uint32 - | +--rw advertisement-interval? - uint32 - | +--rw suppression-interval? - uint32 + | +--rw unidirectional-delay-offset? uint32 + | +--rw measure-interval? uint32 + | +--rw advertisement-interval? uint32 + | +--rw suppression-interval? uint32 | +--rw threshold-out | | +--rw unidirectional-delay? uint32 | | +--rw unidirectional-min-delay? uint32 | | +--rw unidirectional-max-delay? uint32 | | +--rw unidirectional-delay-variation? uint32 | | +--rw unidirectional-packet-loss? @@ -2035,22 +2028,21 @@ performance-metric-normality | | +--ro unidirectional-packet-loss? performance-metric-normality | | +--ro unidirectional-residual-bandwidth? performance-metric-normality | | +--ro unidirectional-available-bandwidth? performance-metric-normality | | +--ro unidirectional-utilized-bandwidth? performance-metric-normality | +--ro link-protection-type? enumeration - | +--ro interface-switching-capability* [switching- - capability] + | +--ro interface-switching-capability* [switching-capability] | | +--ro switching-capability identityref | | +--ro encoding? identityref | | +--ro max-lsp-bandwidth* [priority] | | | +--ro priority uint8 | | | +--ro bandwidth? decimal64 | | +--ro time-division-multiplex-capable | | | +--ro minimum-lsp-bandwidth? decimal64 | | | +--ro indication? enumeration | | +--ro interface-adjustment-capability* [upper-sc] | | +--ro upper-sc identityref @@ -2110,22 +2102,21 @@ performance-metric-normality | | +--ro unidirectional-packet-loss? performance-metric-normality | | +--ro unidirectional-residual-bandwidth? performance-metric-normality | | +--ro unidirectional-available-bandwidth? performance-metric-normality | | +--ro unidirectional-utilized-bandwidth? performance-metric-normality | +--ro link-protection-type? enumeration - | +--ro interface-switching-capability* [switching- - capability] + | +--ro interface-switching-capability* [switching-capability] | | +--ro switching-capability identityref | | +--ro encoding? identityref | | +--ro max-lsp-bandwidth* [priority] | | | +--ro priority uint8 | | | +--ro bandwidth? decimal64 | | +--ro time-division-multiplex-capable | | | +--ro minimum-lsp-bandwidth? decimal64 | | | +--ro indication? enumeration | | +--ro interface-adjustment-capability* [upper-sc] | | +--ro upper-sc identityref @@ -2148,37 +2139,37 @@ augment /nw:networks/tet:te/tet:templates/tet:link-template/tet:te- link-attributes/tet:interface-switching-capability: +--rw packet-switch-capable +--rw minimum-lsp-bandwidth? decimal64 +--rw interface-mtu? uint16 augment /nw:networks/nw:network/nt:link/tet:te/tet:config/tet:te- link-attributes/tet:interface-switching-capability: +--rw packet-switch-capable +--rw minimum-lsp-bandwidth? decimal64 +--rw interface-mtu? uint16 - augment /nw:networks/nw:network/nt:link/tet:te/tet:state/tet:te- - link-attributes/tet:interface-switching-capability: + augment /nw:networks/nw:network/nt:link/tet:te/tet:state/tet:te-link- + attributes/tet:interface-switching-capability: +--ro packet-switch-capable +--ro minimum-lsp-bandwidth? decimal64 +--ro interface-mtu? uint16 augment /nw:networks/nw:network/nt:link/tet:te/tet:state/tet:alt- information-sources/tet:interface-switching-capability: +--ro packet-switch-capable +--ro minimum-lsp-bandwidth? decimal64 +--ro interface-mtu? uint16 augment /tet:te-link-event/tet:te-link-attributes/tet:interface- switching-capability: +---- packet-switch-capable +---- minimum-lsp-bandwidth? decimal64 +---- interface-mtu? uint16 - augment /tet:te-link-event/tet:alt-information- - sources/tet:interface-switching-capability: + augment /tet:te-link-event/tet:alt-information-sources/tet:interface- + switching-capability: +---- packet-switch-capable +---- minimum-lsp-bandwidth? decimal64 +---- interface-mtu? uint16 7. TE Topology Yang Modules 7.1. Base TE Topology Module file "ietf-te-topology@2016-03-17.yang" module ietf-te-topology { @@ -2291,22 +2281,21 @@ description "Normal."; } enum "abnormal" { value 2; description "Abnormal. The anomalous bit is set."; } } description - "Indicates whether a performance metric is normal, abnormal, - or + "Indicates whether a performance metric is normal, abnormal, or unknown."; reference "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions."; } typedef te-admin-status { type enumeration { enum up { description "Enabled."; @@ -2330,28 +2319,26 @@ enum maintenance { description "Resource is disabled in the data plane for maintenance purposes."; } } description "Defines a type representing the administrative status of a TE resource."; } - typedef te-global-id { type uint32; description "An identifier to uniquely identify an operator, which can be either a provider or a client. - The definition of this type is taken from RFC6370 and - RFC5003. + The definition of this type is taken from RFC6370 and RFC5003. This attribute type is used solely to provide a globally unique context for TE topologies."; } typedef te-link-access-type { type enumeration { enum point-to-point { description "The link is point-to-point."; } @@ -2418,29 +2404,27 @@ type enumeration { enum normal { description "Both the recovery and working spans are fully allocated and active, data traffic is being transported over (or selected from) the working span, and no trigger events are reported."; } enum recovery-started { description - "The recovery action has been started, but not - completed."; + "The recovery action has been started, but not completed."; } enum recovery-succeeded { description "The recovery action has succeeded. The working span has reported a failure/degrade condition and the user traffic - is being transported (or selected) on the recovery - span."; + is being transported (or selected) on the recovery span."; } enum recovery-failed { description "The recovery action has failed."; } enum reversion-started { description "The reversion has started."; } enum reversion-failed { @@ -2511,22 +2494,21 @@ "An identifier for a topology."; } typedef te-tp-id { type union { type uint32; // Unnumbered type inet:ip-address; // IPv4 or IPv6 address } description "An identifier for a TE link endpoint on a node. - This attribute is mapped to local or remote link identifier - in + This attribute is mapped to local or remote link identifier in RFC3630 and RFC5305."; } /* * Identities */ /* * Groupings */ @@ -2748,42 +2729,39 @@ description "Interval in seconds to suppress advertising the extended metric values."; } container threshold-out { uses performance-metric-attributes; description "If the measured parameter falls outside an upper bound for all but the min delay metric (or lower bound for min-delay metric only) and the advertised value is not - already outside that bound, anomalous announcement will - be + already outside that bound, anomalous announcement will be triggered."; } container threshold-in { uses performance-metric-attributes; description "If the measured parameter falls inside an upper bound for all but the min delay metric (or lower bound for min-delay metric only) and the advertised value is not - already inside that bound, normal (anomalous-flag - cleared) + already inside that bound, normal (anomalous-flag cleared) announcement will be triggered."; } container threshold-accelerated-advertisement { description "When the difference between the last advertised value and current measured value exceed this threshold, anomalous announcement will be triggered."; uses performance-metric-attributes; } - } } // performance-metric-throttle-container grouping te-link-augment { description "Augmentation for TE link."; container te { presence "TE support."; description @@ -2942,24 +2921,22 @@ } // te-link-attributes } // te-link-config-attributes grouping te-link-info-attributes { description "Advertised TE information attributes."; leaf link-index { type uint64; description "The link identifier. If OSPF is used, this represents an - ospfLsdbID. If IS-IS is used, this represents an - isisLSPID. - If a locally configured link is used, this object - represents + ospfLsdbID. If IS-IS is used, this represents an isisLSPID. + If a locally configured link is used, this object represents a unique value, which is locally defined in a router."; } leaf administrative-group { type te-types:admin-groups; description "Administrative group or color of the link. This attribute covers both administrative group (defined in RFC3630, RFC5329, and RFC5305), and extended administrative group (defined in RFC7308)."; } @@ -3133,22 +3110,21 @@ } } description "Indication whether the interface supports Standard or Arbitrary SONET/SDH"; } } list interface-adjustment-capability { key "upper-sc"; description - "List of Interface Adjustment Capability Descriptors - (IACD) + "List of Interface Adjustment Capability Descriptors (IACD) for this link."; reference "RFC6001: Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)."; leaf upper-sc { type identityref { base te-types:switching-capabilities; } description "Switching Capability for this interface."; @@ -3264,22 +3239,21 @@ leaf path-element-id { type uint32; description "To identify the element in a path."; } uses te-path-element; } } // underlay-primary-path list underlay-backup-path { key "index"; description - "A list of backup service paths on the underlay topology - that + "A list of backup service paths on the underlay topology that protect the underlay primary path. If the primary path is not protected, the list contains zero elements. If the primary path is protected, the list contains one or more elements."; leaf index { type uint32; description "A sequence number to identify a backup path."; } uses te-topology-ref; @@ -3412,39 +3384,37 @@ description "The administrative state of the link."; } uses te-node-connectivity-matrix; uses te-node-info-attributes; } // te-node-attributes } // te-node-config-attributes grouping te-node-config-attributes-notification { description - "Configuration node attributes for template in a TE - topology."; + "Configuration node attributes for template in a TE topology."; container te-node-attributes { description "Containing node attributes in a TE topology."; uses sch:schedules; leaf admin-status { type te-admin-status; description "The administrative state of the link."; } uses te-node-connectivity-matrix-abs; uses te-node-info-attributes; } // te-node-attributes } // te-node-config-attributes-notification grouping te-node-config-attributes-template { description - "Configuration node attributes for template in a TE - topology."; + "Configuration node attributes for template in a TE topology."; container te-node-attributes { description "Containing node attributes in a TE topology."; uses sch:schedules; leaf admin-status { type te-admin-status; description "The administrative state of the link."; } uses te-node-info-attributes; } // te-node-attributes @@ -3814,27 +3785,25 @@ "A reference to a provider-id."; } leaf client-id-ref { type leafref { path "/nw:networks/nw:network[nw:network-id = " + "current()/../network-id-ref]/tet:te/tet:client-id"; require-instance false; } description "A reference to a client-id."; - } leaf te-topology-id-ref { type leafref { path "/nw:networks/nw:network[nw:network-id = " - + "current()/../network-id-ref]/tet:te/tet:te-topology- - id"; + + "current()/../network-id-ref]/tet:te/tet:te-topology-id"; require-instance false; } description "A reference to a te-topology-id."; } leaf network-id-ref { type leafref { path "/nw:networks/nw:network/nw:network-id"; require-instance false; } @@ -3880,22 +3850,21 @@ } enum cascade { description "When an attribute changes in this template, the configuration object referring to this template applies the new attribute value to the corresponding configuration."; } } description - "This attribute specifies the action taken to a - configuration + "This attribute specifies the action taken to a configuration node that has a reference to this template."; } } // template-attributes /* * Configuration data nodes */ augment "/nw:networks/nw:network/nw:network-types" { description "Introduce new network type for TE topology."; @@ -4204,23 +4172,23 @@ Scheduling", draft-liu-netmod-yang-schedule-00 (Work in Progress). 10.2. Informative References [RFC2702] Awduche, D., "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. 11. Acknowledgments - The authors would like to thank Lou Berger, Sue Hares, Mazen - Khaddam, Cyril Margaria and Zafar Ali for participating in design - discussions and providing valuable insights. + The authors would like to thank Lou Berger, Sue Hares, Mazen Khaddam, + Cyril Margaria and Zafar Ali for participating in design discussions + and providing valuable insights. Contributors Sergio Belotti Alcatel Lucent Email: sergio.belotti@alcatel-lucent.com Dieter Beller Alcatel Lucent Email: dieter.beller@alcatel-lucent.com