Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8345

A YANG Data Model for Network Topologies

Pages: 57
Proposed Standard
Errata
Part 2 of 3 – Pages 19 to 39
First   Prev   Next

Top   ToC   RFC8345 - Page 19   prevText

5. Interactions with Other YANG Modules

The data model makes use of data types that have been defined in [RFC6991]. This is a protocol-independent YANG data model with topology information. It is separate from, and not linked with, data models that are used to configure routing protocols or routing information. This includes, for example, the "ietf-routing" YANG module [RFC8022].
Top   ToC   RFC8345 - Page 20
   The data model obeys the requirements for the ephemeral state as
   specified in [RFC8242].  For ephemeral topology data that is system
   controlled, the process tasked with maintaining topology information
   will load information from the routing process (such as OSPF) into
   the operational state datastore without relying on a configuration
   datastore.

6. YANG Modules

6.1. Defining the Abstract Network: ietf-network

<CODE BEGINS> file "ietf-network@2018-02-26.yang" module ietf-network { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-network"; prefix nw; import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types"; } organization "IETF I2RS (Interface to the Routing System) Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/i2rs/> WG List: <mailto:i2rs@ietf.org> Editor: Alexander Clemm <mailto:ludwig@clemm.org> Editor: Jan Medved <mailto:jmedved@cisco.com> Editor: Robert Varga <mailto:robert.varga@pantheon.tech> Editor: Nitin Bahadur <mailto:nitin_bahadur@yahoo.com> Editor: Hariharan Ananthakrishnan <mailto:hari@packetdesign.com> Editor: Xufeng Liu <mailto:xufeng.liu.ietf@gmail.com>";
Top   ToC   RFC8345 - Page 21
     description
       "This module defines a common base data model for a collection
        of nodes in a network.  Node definitions are further used
        in network topologies and inventories.

        Copyright (c) 2018 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject
        to the license terms contained in, the Simplified BSD License
        set forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (https://trustee.ietf.org/license-info).

        This version of this YANG module is part of RFC 8345;
        see the RFC itself for full legal notices.";

     revision 2018-02-26 {
       description
         "Initial revision.";
       reference
         "RFC 8345: A YANG Data Model for Network Topologies";
     }

     typedef node-id {
       type inet:uri;
       description
         "Identifier for a node.  The precise structure of the node-id
          will be up to the implementation.  For example, some
          implementations MAY pick a URI that includes the network-id
          as part of the path.  The identifier SHOULD be chosen
          such that the same node in a real network topology will
          always be identified through the same identifier, even if
          the data model is instantiated in separate datastores.  An
          implementation MAY choose to capture semantics in the
          identifier -- for example, to indicate the type of node.";
     }
Top   ToC   RFC8345 - Page 22
     typedef network-id {
       type inet:uri;
       description
         "Identifier for a network.  The precise structure of the
          network-id will be up to the implementation.  The identifier
          SHOULD be chosen such that the same network will always be
          identified through the same identifier, even if the data model
          is instantiated in separate datastores.  An implementation MAY
          choose to capture semantics in the identifier -- for example,
          to indicate the type of network.";
     }

     grouping network-ref {
       description
         "Contains the information necessary to reference a network --
          for example, an underlay network.";
       leaf network-ref {
         type leafref {
           path "/nw:networks/nw:network/nw:network-id";
         require-instance false;
         }
         description
           "Used to reference a network -- for example, an underlay
            network.";
       }
     }

     grouping node-ref {
       description
         "Contains the information necessary to reference a node.";
       leaf node-ref {
         type leafref {
           path "/nw:networks/nw:network[nw:network-id=current()/../"+
             "network-ref]/nw:node/nw:node-id";
           require-instance false;
         }
         description
           "Used to reference a node.
            Nodes are identified relative to the network that
            contains them.";
       }
       uses network-ref;
     }
Top   ToC   RFC8345 - Page 23
     container networks {
       description
         "Serves as a top-level container for a list of networks.";
       list network {
         key "network-id";
         description
           "Describes a network.
            A network typically contains an inventory of nodes,
            topological information (augmented through the
            network-topology data model), and layering information.";
         leaf network-id {
           type network-id;
           description
             "Identifies a network.";
         }
         container network-types {
           description
             "Serves as an augmentation target.
              The network type is indicated through corresponding
              presence containers augmented into this container.";
         }
         list supporting-network {
           key "network-ref";
           description
             "An underlay network, used to represent layered network
              topologies.";
           leaf network-ref {
             type leafref {
               path "/nw:networks/nw:network/nw:network-id";
             require-instance false;
             }
             description
               "References the underlay network.";
           }
         }
Top   ToC   RFC8345 - Page 24
         list node {
           key "node-id";
           description
             "The inventory of nodes of this network.";
           leaf node-id {
             type node-id;
             description
               "Uniquely identifies a node within the containing
                network.";
           }
           list supporting-node {
             key "network-ref node-ref";
             description
               "Represents another node that is in an underlay network
                and that supports this node.  Used to represent layering
                structure.";
             leaf network-ref {
               type leafref {
                 path "../../../nw:supporting-network/nw:network-ref";
               require-instance false;
               }
               description
                 "References the underlay network of which the
                  underlay node is a part.";
             }
             leaf node-ref {
               type leafref {
                 path "/nw:networks/nw:network/nw:node/nw:node-id";
               require-instance false;
               }
               description
                 "References the underlay node itself.";
             }
           }
         }
       }
     }
   }

   <CODE ENDS>
Top   ToC   RFC8345 - Page 25

6.2. Creating Abstract Network Topology: ietf-network-topology

<CODE BEGINS> file "ietf-network-topology@2018-02-26.yang" module ietf-network-topology { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology"; prefix nt; import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types"; } import ietf-network { prefix nw; reference "RFC 8345: A YANG Data Model for Network Topologies"; } organization "IETF I2RS (Interface to the Routing System) Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/i2rs/> WG List: <mailto:i2rs@ietf.org> Editor: Alexander Clemm <mailto:ludwig@clemm.org> Editor: Jan Medved <mailto:jmedved@cisco.com> Editor: Robert Varga <mailto:robert.varga@pantheon.tech> Editor: Nitin Bahadur <mailto:nitin_bahadur@yahoo.com> Editor: Hariharan Ananthakrishnan <mailto:hari@packetdesign.com> Editor: Xufeng Liu <mailto:xufeng.liu.ietf@gmail.com>";
Top   ToC   RFC8345 - Page 26
     description
       "This module defines a common base model for a network topology,
        augmenting the base network data model with links to connect
        nodes, as well as termination points to terminate links
        on nodes.

        Copyright (c) 2018 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject
        to the license terms contained in, the Simplified BSD License
        set forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (https://trustee.ietf.org/license-info).

        This version of this YANG module is part of RFC 8345;
        see the RFC itself for full legal notices.";

     revision 2018-02-26 {
       description
         "Initial revision.";
       reference
         "RFC 8345: A YANG Data Model for Network Topologies";
     }

     typedef link-id {
       type inet:uri;
       description
         "An identifier for a link in a topology.  The precise
          structure of the link-id will be up to the implementation.
          The identifier SHOULD be chosen such that the same link in a
          real network topology will always be identified through the
          same identifier, even if the data model is instantiated in
          separate datastores.  An implementation MAY choose to capture
          semantics in the identifier -- for example, to indicate the
          type of link and/or the type of topology of which the link is
          a part.";
     }

     typedef tp-id {
       type inet:uri;
       description
         "An identifier for termination points on a node.  The precise
          structure of the tp-id will be up to the implementation.
          The identifier SHOULD be chosen such that the same termination
          point in a real network topology will always be identified
          through the same identifier, even if the data model is
Top   ToC   RFC8345 - Page 27
          instantiated in separate datastores.  An implementation MAY
          choose to capture semantics in the identifier -- for example,
          to indicate the type of termination point and/or the type of
          node that contains the termination point.";
     }

     grouping link-ref {
       description
         "This grouping can be used to reference a link in a specific
          network.  Although it is not used in this module, it is
          defined here for the convenience of augmenting modules.";
       leaf link-ref {
         type leafref {
           path "/nw:networks/nw:network[nw:network-id=current()/../"+
             "network-ref]/nt:link/nt:link-id";
           require-instance false;
         }
         description
           "A type for an absolute reference to a link instance.
            (This type should not be used for relative references.
            In such a case, a relative path should be used instead.)";
       }
       uses nw:network-ref;
     }

     grouping tp-ref {
       description
         "This grouping can be used to reference a termination point
          in a specific node.  Although it is not used in this module,
          it is defined here for the convenience of augmenting
          modules.";
       leaf tp-ref {
         type leafref {
           path "/nw:networks/nw:network[nw:network-id=current()/../"+
             "network-ref]/nw:node[nw:node-id=current()/../"+
             "node-ref]/nt:termination-point/nt:tp-id";
           require-instance false;
         }
         description
           "A type for an absolute reference to a termination point.
            (This type should not be used for relative references.
            In such a case, a relative path should be used instead.)";
       }
       uses nw:node-ref;
     }
Top   ToC   RFC8345 - Page 28
     augment "/nw:networks/nw:network" {
       description
         "Add links to the network data model.";
       list link {
         key "link-id";
         description
           "A network link connects a local (source) node and
            a remote (destination) node via a set of the respective
            node's termination points.  It is possible to have several
            links between the same source and destination nodes.
            Likewise, a link could potentially be re-homed between
            termination points.  Therefore, in order to ensure that we
            would always know to distinguish between links, every link
            is identified by a dedicated link identifier.  Note that a
            link models a point-to-point link, not a multipoint link.";
         leaf link-id {
           type link-id;
           description
             "The identifier of a link in the topology.
              A link is specific to a topology to which it belongs.";
         }
         container source {
           description
             "This container holds the logical source of a particular
              link.";
           leaf source-node {
             type leafref {
               path "../../../nw:node/nw:node-id";
               require-instance false;
             }
             description
               "Source node identifier.  Must be in the same topology.";
           }
           leaf source-tp {
             type leafref {
               path "../../../nw:node[nw:node-id=current()/../"+
                 "source-node]/termination-point/tp-id";
               require-instance false;
             }
             description
               "This termination point is located within the source node
                and terminates the link.";
           }
         }
Top   ToC   RFC8345 - Page 29
         container destination {
           description
             "This container holds the logical destination of a
              particular link.";
           leaf dest-node {
             type leafref {
               path "../../../nw:node/nw:node-id";
             require-instance false;
             }
             description
               "Destination node identifier.  Must be in the same
                network.";
           }
           leaf dest-tp {
             type leafref {
               path "../../../nw:node[nw:node-id=current()/../"+
                 "dest-node]/termination-point/tp-id";
               require-instance false;
             }
             description
               "This termination point is located within the
                destination node and terminates the link.";
           }
         }
         list supporting-link {
           key "network-ref link-ref";
           description
             "Identifies the link or links on which this link depends.";
           leaf network-ref {
             type leafref {
               path "../../../nw:supporting-network/nw:network-ref";
             require-instance false;
             }
             description
               "This leaf identifies in which underlay topology
                the supporting link is present.";
           }
Top   ToC   RFC8345 - Page 30
           leaf link-ref {
             type leafref {
               path "/nw:networks/nw:network[nw:network-id=current()/"+
                 "../network-ref]/link/link-id";
               require-instance false;
             }
             description
               "This leaf identifies a link that is a part
                of this link's underlay.  Reference loops in which
                a link identifies itself as its underlay, either
                directly or transitively, are not allowed.";
           }
         }
       }
     }
     augment "/nw:networks/nw:network/nw:node" {
       description
         "Augments termination points that terminate links.
          Termination points can ultimately be mapped to interfaces.";
       list termination-point {
         key "tp-id";
         description
           "A termination point can terminate a link.
            Depending on the type of topology, a termination point
            could, for example, refer to a port or an interface.";
         leaf tp-id {
           type tp-id;
           description
             "Termination point identifier.";
         }
         list supporting-termination-point {
           key "network-ref node-ref tp-ref";
           description
             "This list identifies any termination points on which a
              given termination point depends or onto which it maps.
              Those termination points will themselves be contained
              in a supporting node.  This dependency information can be
              inferred from the dependencies between links.  Therefore,
              this item is not separately configurable.  Hence, no
              corresponding constraint needs to be articulated.
              The corresponding information is simply provided by the
              implementing system.";
Top   ToC   RFC8345 - Page 31
           leaf network-ref {
             type leafref {
               path "../../../nw:supporting-node/nw:network-ref";
             require-instance false;
             }
             description
               "This leaf identifies in which topology the
                supporting termination point is present.";
           }
           leaf node-ref {
             type leafref {
               path "../../../nw:supporting-node/nw:node-ref";
             require-instance false;
             }
             description
               "This leaf identifies in which node the supporting
                termination point is present.";
           }
           leaf tp-ref {
             type leafref {
               path "/nw:networks/nw:network[nw:network-id=current()/"+
                 "../network-ref]/nw:node[nw:node-id=current()/../"+
                 "node-ref]/termination-point/tp-id";
               require-instance false;
             }
             description
               "Reference to the underlay node (the underlay node must
                be in a different topology).";
           }
         }
       }
     }
   }

   <CODE ENDS>
Top   ToC   RFC8345 - Page 32

7. IANA Considerations

This document registers the following namespace URIs in the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-network Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-network-topology Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-network-state Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-network-topology-state Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document registers the following YANG modules in the "YANG Module Names" registry [RFC6020]: Name: ietf-network Namespace: urn:ietf:params:xml:ns:yang:ietf-network Prefix: nw Reference: RFC 8345 Name: ietf-network-topology Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology Prefix: nt Reference: RFC 8345 Name: ietf-network-state Namespace: urn:ietf:params:xml:ns:yang:ietf-network-state Prefix: nw-s Reference: RFC 8345 Name: ietf-network-topology-state Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology-state Prefix: nt-s Reference: RFC 8345
Top   ToC   RFC8345 - Page 33

8. Security Considerations

The YANG modules specified in this document define a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC5246]. The NETCONF access control model [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. The network topology and inventory created by these modules reveal information about the structure of networks that could be very helpful to an attacker. As a privacy consideration, although there is no personally identifiable information defined in these modules, it is possible that some node identifiers may be associated with devices that are in turn associated with specific users. The YANG modules define information that can be configurable in certain instances -- for example, in the case of overlay topologies that can be created by client applications. In such cases, a malicious client could introduce topologies that are undesired. Specifically, a malicious client could attempt to remove or add a node, a link, or a termination point by creating or deleting corresponding elements in node, link, or termination point lists, respectively. In the case of a topology that is learned, the server will automatically prohibit such misconfiguration attempts. In the case of a topology that is configured, i.e., whose origin is "intended", the undesired configuration could become effective and be reflected in the operational state datastore, leading to disruption of services provided via this topology. For example, the topology could be "cut" or could be configured in a suboptimal way, leading to increased consumption of resources in the underlay network due to the routing and bandwidth utilization inefficiencies that would result. Likewise, it could lead to degradation of service levels as well as possible disruption of service. For those reasons, it is important that the NETCONF access control model be vigorously applied to prevent topology misconfiguration by unauthorized clients. There are a number of data nodes defined in these YANG modules that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config)
Top   ToC   RFC8345 - Page 34
   to these data nodes without proper protection can have a negative
   effect on network operations.  These are the subtrees and data nodes
   and their sensitivity/vulnerability:

   In the "ietf-network" module:

   o  network: A malicious client could attempt to remove or add a
      network in an effort to remove an overlay topology or to create an
      unauthorized overlay.

   o  supporting network: A malicious client could attempt to disrupt
      the logical structure of the model, resulting in a lack of overall
      data integrity and making it more difficult to, for example,
      troubleshoot problems rooted in the layering of network
      topologies.

   o  node: A malicious client could attempt to remove or add a node
      from the network -- for example, in order to sabotage the topology
      of a network overlay.

   o  supporting node: A malicious client could attempt to change the
      supporting node in order to sabotage the layering of an overlay.

   In the "ietf-network-topology" module:

   o  link: A malicious client could attempt to remove a link from a
      topology, add a new link, manipulate the way the link is layered
      over supporting links, or modify the source or destination of the
      link.  In each case, the structure of the topology would be
      sabotaged, and this scenario could, for example, result in an
      overlay topology that is less than optimal.

   o  termination point: A malicious client could attempt to remove
      termination points from a node, add "phantom" termination points
      to a node, or change the layering dependencies of termination
      points, again in an effort to sabotage the integrity of a topology
      and potentially disrupt orderly operations of an overlay.
Top   ToC   RFC8345 - Page 35

9. References

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>. [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>. [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>. [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>. [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Top   ToC   RFC8345 - Page 36
   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8342]  Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
              and R. Wilton, "Network Management Datastore Architecture
              (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
              <https://www.rfc-editor.org/info/rfc8342>.

9.2. Informative References

[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, <https://www.rfc-editor.org/info/rfc1195>. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>. [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, <https://www.rfc-editor.org/info/rfc3444>. [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>. [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC 7952, DOI 10.17487/RFC7952, August 2016, <https://www.rfc-editor.org/info/rfc7952>. [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Management", RFC 8022, DOI 10.17487/RFC8022, November 2016, <https://www.rfc-editor.org/info/rfc8022>. [RFC8242] Haas, J. and S. Hares, "Interface to the Routing System (I2RS) Ephemeral State Requirements", RFC 8242, DOI 10.17487/RFC8242, September 2017, <https://www.rfc-editor.org/info/rfc8242>.
Top   ToC   RFC8345 - Page 37
   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
              <https://www.rfc-editor.org/info/rfc8340>.

   [RFC8343]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
              <https://www.rfc-editor.org/info/rfc8343>.

   [RFC8346]  Clemm, A., Medved, J., Varga, R., Liu, X.,
              Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model
              for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346,
              March 2018, <https://www.rfc-editor.org/info/rfc8346>.

   [USECASE-REQS]
              Hares, S. and M. Chen, "Summary of I2RS Use Case
              Requirements", Work in Progress, draft-ietf-i2rs-usecase-
              reqs-summary-03, November 2016.

   [YANG-Push]
              Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A.,
              Nilsen-Nygaard, E., Bierman, A., and B. Lengyel, "YANG
              Datastore Subscription", Work in Progress,
              draft-ietf-netconf-yang-push-15, February 2018.
Top   ToC   RFC8345 - Page 38

Appendix A. Model Use Cases

A.1. Fetching Topology from a Network Element

In its simplest form, topology is learned by a network element (e.g., a router) through its participation in peering protocols (IS-IS, BGP, etc.). This learned topology can then be exported (e.g., to a Network Management System) for external utilization. Typically, any network element in a domain can be queried for its topology and be expected to return the same result. In a slightly more complex form, the network element may be a controller. It could be a network element with satellite or subtended devices hanging off of it, or it could be a controller in the more classical sense -- that is, a special device designated to orchestrate the activities of a number of other devices (e.g., an Optical Controller). In this case, the controller device is logically a singleton and must be queried distinctly. It is worth noting that controllers can be built on top of other controllers to establish a topology incorporating all of the domains within an entire network. In all of the cases above, the topology learned by the network element is considered to be operational state data. That is, the data is accumulated purely by the network element's interactions with other systems and is subject to change dynamically without input or consent.

A.2. Modifying TE Topology Imported from an Optical Controller

Consider a scenario where an Optical Controller presents its topology, in abstract TE terms, to a client packet controller. This customized topology (which gets merged into the client's native topology) contains sufficient information for the path-computing client to select paths across the optical domain according to its policies. If the client determines (at any given point in time) that this imported topology does not cater exactly to its requirements, it may decide to request modifications to the topology. Such customization requests may include the addition or deletion of topological elements or the modification of attributes associated with existing topological elements. From the perspective of the Optical Controller, these requests translate into configuration changes to the exported abstract topology.
Top   ToC   RFC8345 - Page 39

A.3. Annotating Topology for Local Computation

In certain scenarios, the topology learned by a controller needs to be augmented with additional attributes before running a computation algorithm on it. Consider the case where a path-computation application on the controller needs to take the geographic coordinates of the nodes into account while computing paths on the learned topology. If the learned topology does not contain these coordinates, then these additional attributes must be configured on the corresponding topological elements.

A.4. SDN Controller-Based Configuration of Overlays on Top of Underlays

In this scenario, an SDN Controller (for example, Open Daylight) maintains a view of the topology of the network that it controls based on information that it discovers from the network. In addition, it provides an application in which it configures and maintains an overlay topology. The SDN Controller thus maintains two roles: o It is a client to the network. o It is a server to its own northbound applications and clients, e.g., an Operations Support System (OSS). In other words, one system's client (or controller, in this case) may be another system's server (or managed system). In this scenario, the SDN Controller maintains a consolidated data model of multiple layers of topology. This includes the lower layers of the network topology, built from information that is discovered from the network. It also includes upper layers of topology overlay, configurable by the controller's client, i.e., the OSS. To the OSS, the lower topology layers constitute "read-only" information. The upper topology layers need to be read-writable.


(page 39 continued on part 3)

Next Section