--- 1/draft-ietf-teas-yang-te-topo-10.txt 2017-07-03 13:13:08.994334319 -0700 +++ 2/draft-ietf-teas-yang-te-topo-11.txt 2017-07-03 13:13:09.270340943 -0700 @@ -4,24 +4,24 @@ Huawei Technologies Vishnu Pavan Beeram Juniper Networks Tarek Saad Cisco Systems Inc Himanshu Shah Ciena Oscar Gonzalez De Dios Telefonica -Expires: January 2, 2018 July 2, 2017 +Expires: January 3, 2018 July 3, 2017 YANG Data Model for TE Topologies - draft-ietf-teas-yang-te-topo-10 + draft-ietf-teas-yang-te-topo-11 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. @@ -30,21 +30,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 January 2, 2018. + This Internet-Draft will expire on January 3, 2018. Copyright Notice Copyright (c) 2017 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 @@ -93,33 +93,33 @@ 4.3. Merging TE Topologies Provided by Multiple Providers.....18 4.4. Dealing with Multiple Abstract TE Topologies Provided by the Same Provider.................................................21 5. Modeling Considerations.......................................24 5.1. Network topology building blocks.........................24 5.2. Technology agnostic TE Topology model....................24 5.3. Model Structure..........................................25 5.4. Topology Identifiers.....................................26 5.5. Generic TE Link Attributes...............................26 5.6. Generic TE Node Attributes...............................27 - 5.7. TED Information Sources..................................29 - 5.8. Overlay/Underlay Relationship............................30 - 5.9. Templates................................................31 - 5.10. Scheduling Parameters...................................32 - 5.11. Notifications...........................................32 + 5.7. TED Information Sources..................................28 + 5.8. Overlay/Underlay Relationship............................29 + 5.9. Templates................................................30 + 5.10. Scheduling Parameters...................................31 + 5.11. Notifications...........................................31 6. Tree Structure................................................32 7. TE Topology Yang Module.......................................68 - 8. Security Considerations......................................116 - 9. IANA Considerations..........................................116 + 8. Security Considerations......................................115 + 9. IANA Considerations..........................................115 10. References..................................................116 10.1. Normative References...................................116 - 10.2. Informative References.................................117 - 11. Acknowledgments.............................................117 + 10.2. Informative References.................................116 + 11. Acknowledgments.............................................116 Appendix A. Companion YANG Model for Non-NMDA Compliant Implementations.................................................118 A.1. TE Topology State Yang Module...........................118 Contributors....................................................125 Authors' Addresses..............................................126 1. Introduction The Traffic Engineering Database (TED) is an essential component of Traffic Engineered (TE) systems that are based on MPLS-TE [RFC2702] @@ -1052,52 +1052,41 @@ +--rw node-template* [name] {template}? | ............ +--rw link-template* [name] {template}? ............ augment /nw:networks/nw:network: +--rw provider-id? te-types:te-global-id +--rw client-id? te-types:te-global-id +--rw te-topology-id? te-types:te-topology-id +--rw te! - +--rw config | ............ - +--ro state - ............ augment /nw:networks/nw:network/nw:node: +--rw te-node-id? te-types:te-node-id +--rw te! - +--rw config - | ............ - +--ro state | ............ +--rw tunnel-termination-point* [tunnel-tp-id] +--rw tunnel-tp-id binary - +--rw config | ............ - +--ro state + +--rw supporting-tunnel-termination-point* [node-ref tunnel- + tp-ref] + | ............ augment /nw:networks/nw:network/nt:link: +--rw te! - +--rw config | .......... - +--ro state - .......... augment /nw:networks/nw:network/nw:node/nt:termination-point: +--rw te-tp-id? te-types:te-tp-id +--rw te! - +--rw config | ............ - +--ro state - ............ 5.4. Topology Identifiers The TE-Topology is uniquely identified by a key that has 3 constituents - te-topology-id, provider-id and client-id. The combination of provider-id and te-topology-id uniquely identifies a native TE Topology on a given provider. The client-id is used only when Customized TE Topologies come into play; a value of "0" is used as the client-id for native TE Topologies. @@ -1136,89 +1126,68 @@ The definition of a generic connectivity matrix is shown below: +--rw te-node-attributes ........... +--rw connectivity-matrices ........... | +--rw connectivity-matrix* [id] | | +--rw id uint32 | | +--rw from | | | +--rw tp-ref? leafref + | | | +--rw label-restriction* [inclusive-exclusive label- + start] | | +--rw to | | | +--rw tp-ref? leafref + | | | +--rw label-restriction* [inclusive-exclusive label- + start] | | +--rw is-allowed? boolean - | | +--rw label-restriction* [inclusive-exclusive label-start] ........... | | +--rw underlay! {te-topology-hierarchy}? ........... - | | +--rw max-link-bandwidth? te-bandwidth - | | +--rw max-resv-link-bandwidth? te-bandwidth - | | +--rw unreserved-bandwidth* [priority] + | | +--rw path-constraints ........... - | | +--rw te-default-metric? uint32 - | | +--rw te-delay-metric? uint32 - | | +--rw te-srlgs - | | +--rw te-nsrlgs {nsrlg}? ...........The definition of - a TTP Local Link Connectivity List is shown below: + | | +--rw optimizations + ........... + | | +--ro computed-path-properties + ........... + + The definition of a TTP Local Link Connectivity List is shown below: +--rw tunnel-termination-point* [tunnel-tp-id] +--rw tunnel-tp-id binary - +--rw config - | +--rw switching-capability? identityref - | +--rw encoding? identityref - | +--rw inter-layer-lock-id? uint32 - | +--rw protection-type? identityref - | +--rw local-link-connectivities + +--rw admin-status? te-types:te-admin-status + +--rw name? string + +--rw switching-capability? identityref + +--rw encoding? identityref + +--rw inter-layer-lock-id? uint32 + +--rw protection-type? Identityref + +--rw client-layer-adaptation + ........... + +--rw local-link-connectivities ........... | +--rw local-link-connectivity* [link-tp-ref] | +--rw link-tp-ref leafref - | +--rw label-restriction* [inclusive-exclusive label- - start] - ........... - | +--rw max-lsp-bandwidth* [priority] - ........... - | +--rw max-link-bandwidth? te-bandwidth - | +--rw max-resv-link-bandwidth? te-bandwidth - | +--rw unreserved-bandwidth* [priority] - ........... - | +--rw te-default-metric? uint32 - | +--rw te-delay-metric? uint32 - | +--rw te-srlgs - | +--rw te-nsrlgs {nsrlg}? - ........... - +--ro state - | +--ro switching-capability? identityref - | +--ro encoding? identityref - | +--ro inter-layer-lock-id? uint32 - | +--ro protection-type? identityref - | +--ro local-link-connectivities + | +--rw label-restriction* [inclusive-exclusive label-start] ........... - | +--ro local-link-connectivity* [link-tp-ref] - | | +--ro link-tp-ref leafref - | | +--ro label-restriction* [inclusive-exclusive label- - start] + | +--rw is-allowed? boolean + | +--rw underlay {te-topology-hierarchy}? ........... - | | +--ro max-lsp-bandwidth* [priority] + | +--rw path-constraints ........... - | | +--ro max-link-bandwidth? te-bandwidth - | | +--ro max-resv-link-bandwidth? te-bandwidth - | | +--ro unreserved-bandwidth* [priority] + | +--rw optimizations ........... - | | +--ro te-default-metric? uint32 - | | +--ro te-delay-metric? uint32 - | | +--ro te-srlgs - | | +--ro te-nsrlgs {nsrlg}? + | +--ro computed-path-properties ........... +--rw supporting-tunnel-termination-point* [node-ref tunnel-tp- ref] - +--rw node-ref union - +--rw tunnel-tp-ref union + +--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 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 @@ -1234,96 +1203,90 @@ 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. augment /nw:networks/nw:network/nw:node: +--rw te! ........... - +--ro state - ........ - | +--ro information-source? te-info-source - | +--ro information-source-state - | | +--ro credibility-preference? uint16 - | | +--ro logical-network-element? string - | | +--ro network-instance? string - | | +--ro topology - | | +--ro network-ref? leafref - | | +--ro node-ref? leafref - | +--ro information-source-entry* [information-source] + +--ro information-source? te-info-source + +--ro information-source-state + | +--ro credibility-preference? uint16 + | +--ro logical-network-element? string + | +--ro network-instance? string + | +--ro topology + | +--ro node-ref? leafref + | +--ro network-ref? leafref + +--ro information-source-entry* [information-source] + | +--ro information-source te-info-source ............ augment /nw:networks/nw:network/nt:link: +--rw te! ........... - +--ro state - ......... - | +--ro information-source? te-info-source - | +--ro information-source-state - | | +--ro credibility-preference? uint16 - | | +--ro logical-network-element? string - | | +--ro network-instance? string - | | +--ro topology - | | +--ro network-ref? leafref - | | +--ro link-ref? leafref - | +--ro information-source-entry* [information-source] + +--ro information-source? te-info-source + +--ro information-source-state + | +--ro credibility-preference? uint16 + | +--ro logical-network-element? string + | +--ro network-instance? string + | +--ro topology + | +--ro link-ref? leafref + | +--ro network-ref? leafref + +--ro information-source-entry* [information-source] + | +--ro information-source te-info-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. 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-node-id? te-types:te-node-id +--rw te! - +--rw te-node-id te-node-id - +--rw config - | +--rw te-node-template* leafref {template}? - | +--rw te-node-attributes - | .................... + +--rw te-node-template* leafref {template}? + +--rw te-node-attributes + | +--rw admin-status? te-types:te-admin-status + | | .................... | +--rw underlay-topology {te-topology-hierarchy}? | +--rw network-ref? leafref augment /nw:networks/nw:network/nt:link: +--rw te! - +--rw config - | ......... - | +--rw te-link-attributes + +--rw te-link-attributes | .................... - - | +--rw underlay! {te-topology-hierarchy}? + | +--rw underlay {te-topology-hierarchy}? + | | +--rw enabled? boolean | | +--rw primary-path | | | +--rw network-ref? leafref - | | | +--rw path-element* [path-element-id] - | | | ............... + | | | .................... | | +--rw backup-path* [index] | | | +--rw index uint32 | | | +--rw network-ref? leafref - | | | +--rw path-element* [path-element-id] - | | | ............... - | | +--rw underlay-protection-type? uint16 - | | +--rw underlay-tunnel-src - | | | ........... - - | | +--rw underlay-tunnel-des - | | ........... + | | | .................... + | | +--rw protection-type? identityref + | | +--rw tunnel-termination-points + | | | +--rw source? binary + | | | +--rw destination? binary + | | +--rw tunnels + | | | .................... 5.9. 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"). +--rw topology* [provider-id client-id te-topology-id] | ........... @@ -5037,27 +4994,34 @@ 9. IANA Considerations This document registers the following URIs in the IETF XML registry [RFC3688]. Following the format in [RFC3688], the following registration is requested to be made. URI: urn:ietf:params:xml:ns:yang:ietf-te-topology XML: N/A, the requested URI is an XML namespace. + URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-state + XML: N/A, the requested URI is an XML namespace. + This document registers a YANG module in the YANG Module Names registry [RFC6020]. name: ietf-te-topology namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology prefix: tet + name: ietf-te-topology-state + namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-state + prefix: tet-s + 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. @@ -5425,20 +5388,28 @@ Contributors Sergio Belotti Nokia Email: sergio.belotti@nokia.com Dieter Beller Nokia Email: Dieter.Beller@nokia.com + Carlo Perocchio + Ericsson + Email: carlo.perocchio@ericsson.com + + Italo Busi + Huawei Technologies + Email: Italo.Busi@huawei.com + Authors' Addresses Xufeng Liu Jabil Email: Xufeng_Liu@jabil.com Igor Bryskin Huawei Technologies Email: Igor.Bryskin@huawei.com