Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE Use Cases

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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

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."¶

This Internet-Draft will expire on 18 July 2024.¶

Copyright Notice

Copyright (c) 2024 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

There are many network scenarios being discussed in various IETF Working Groups (WGs) that are not classified as "Traffic Engineering" but can be addressed by a sub-set (profile) of the Traffic Engineering (TE) Topology YANG data model, defined in [RFC8795].¶

Traffic Engineering (TE) is defined in [I-D.ietf-teas-rfc3272bis] as aspects of Internet network engineering that deal with the issues of performance evaluation and performance optimization of operational IP networks. TE encompasses the application of technology and scientific principles to the measurement, characterization, modeling, and control of Internet traffic.¶

The TE Topology Model is augmenting the Network Topology Model defined in [RFC8345] with generic and technology-agnostic features that some are strictly applicable to TE networks, while others applicable to both TE and non-TE networks.¶

Examples of such features that are applicable to both TE and non-TE networks are: inter-domain link discovery (plug-id), geo- localization, and admin/operational status.¶

It is also worth noting that the TE Topology Model is quite an extensive and comprehensive model in which most features are optional. Therefore, even though the full model appears to be complex, at the first glance, a sub-set of the model (profile) can be used to address specific scenarios, e.g. suitable also to non-TE use cases.¶

The implementation of such TE Topology profiles can simplify and expedite adoption of the full TE topology YANG data model, and allow for its reuse even for non-TE use case. The key question being whether all or some of the attributes defined in the TE Topology Model are needed to address a given network scenario.¶

Section 2 provides examples where profiles of the TE Topology Model can be used to address some generic use cases applicable to both TE and non-TE technologies.¶

2. Examples of non-TE scenarios

   module: ietf-te-topology
     augment /nw:networks/nw:network/nw:network-types:
       +--rw te-topology!
     augment /nw:networks/nw:network/nw:node/nt:termination-point:
       +--rw te-tp-id?   te-types:te-tp-id
       +--rw te!
          +--rw admin-status?
          |       te-types:te-admin-status
          +--rw inter-domain-plug-id?          binary
          +--ro oper-status?                   te-types:te-oper-status

   module: ietf-te-topology
     augment /nw:networks/nw:network/nw:network-types:
       +--rw te-topology!
     augment /nw:networks/nw:network:
       +--rw te-topology-identifier
       |  +--rw provider-id?   te-global-id
       |  +--rw client-id?     te-global-id
       |  +--rw topology-id?   te-topology-id
       +--rw te!
          +--rw name?                     string
     augment /nw:networks/nw:network/nw:node:
       +--rw te-node-id?   te-types:te-node-id
       +--rw te!
          +--rw te-node-attributes
          |  +--rw admin-status?               te-types:te-admin-status
          |  +--rw name?                       string
          +--ro oper-status?                   te-types:te-oper-status
     augment /nw:networks/nw:network/nt:link:
       +--rw te!
          +--rw te-link-attributes
          |  +--rw name?                       string
          |  +--rw admin-status?               te-types:te-admin-status
          +--ro oper-status?                   te-types:te-oper-status
     augment /nw:networks/nw:network/nw:node/nt:termination-point:
       +--rw te-tp-id?   te-types:te-tp-id
       +--rw te!
          +--rw admin-status?                  te-types:te-admin-status
          +--rw name?                          string
          +--ro oper-status?                   te-types:te-oper-status

   module: ietf-te-topology
     augment /nw:netorks/nw:network/nw:network-types:
       +--rw te-topology!
     augment /nw:networks/nw:network/nw:node:
       +--rw te-node-id?   te-types:te-node-id
       +--rw te!
          +--rw te-node-attributes
             +--rw underlay-topology {te-topology-hierarchy}?
                +--rw network-ref?   -> /nw:networks/network/network-id
     augment /nw:networks/nw:network/nt:link:
       +--rw te!
          +--rw te-link-attributes
             +--rw underlay {te-topology-hierarchy}?
                +--rw enabled?                     boolean
                +--rw primary-path
                   +--rw network-ref?
                   |       -> /nw:networks/network/network-id
                   +--rw path-element* [path-element-id]
                      +--rw path-element-id              uint32
                      +--rw (type)?
                         +--:(numbered-link-hop)
                         |  +--rw numbered-link-hop
                         |     +--rw link-tp-id    te-tp-id
                         |     +--rw hop-type?     te-hop-type
                         |     +--rw direction?    te-link-direction
                         +--:(unnumbered-link-hop)
                            +--rw unnumbered-link-hop
                               +--rw link-tp-id    te-tp-id
                               +--rw node-id       te-node-id
                               +--rw hop-type?     te-hop-type
                               +--rw direction?    te-link-direction

   module: ietf-te-topology
     augment /nw:networks/nw:network/nw:network-types:
       +--rw te-topology!
     augment /nw:networks/nw:network/nw:node:
       +--rw te-node-id?   te-types:te-node-id
       +--rw te!
          +--rw te-node-attributes
             +--rw connectivity-matrices
                +--rw number-of-entries?     uint16
                +--rw is-allowed?            boolean
                +--rw connectivity-matrix* [id]
                   +--rw id                  uint32
                   +--rw from
                   |  +--rw tp-ref?               leafref
                   +--rw to
                   |  +--rw tp-ref?               leafref
                   +--rw is-allowed?              boolean

3. Technology-specific augmentations

There are two main options to define technology-specific Topology Models which can use the attributes defined in the TE Topology Model [RFC8795].¶

Both options are applicable to any possible profile of the TE Topology Model, such as those defined in Section 2.¶

The first option is to define a technology-specific TE Topology Model which augments the TE Topology Model, as shown in Figure 5:¶

                           +-------------------+
                           | Network Topology  |
                           +-------------------+
                                     ^
                                     |
                                     | Augments
                                     |
                         +-----------+-----------+
                         |      TE Topology      |
                         |       (profile)       |
                         +-----------------------+
                                     ^
                                     |
                                     | Augments
                                     |
                          +----------+----------+
                          | Technology-Specific |
                          |     TE Topology     |
                          +---------------------+

This approach is more suitable for cases when the technology-specific TE topology model provides augmentations to the TE Topology constructs, such as bandwidth information (e.g., link bandwidth), tunnel termination points (TTPs) or connectivity matrices. It also allows providing augmentations to the Network Topology constructs, such as nodes, links, and termination points (TPs).¶

This is the approach currently used in [I-D.ietf-ccamp-eth-client-te-topo-yang] and [I-D.ietf-ccamp-otn-topo-yang].¶

It is worth noting that a profile of the technology-specific TE Topology model not using any TE topology attribute or constructs can be used to address any use case that do not require these attributes. In this case, only the te-topology presence container of the TE Topology Model needs to be implemented.¶

The second option is to define a technology-specific Network Topology Model which augments the Network Topology Model and to rely on the multiple inheritance capability, which is implicit in the network- types definition of [RFC8345], to allow using also the generic attributes defined in the TE Topology model:¶

                    +-----------------------+
                    |    Network Topology   |
                    +-----------------------+
                        ^               ^
                        |               |
           Augments +---+               +--+ Augments
                    |                      |
          +---------+---+       +----------+----------+
          | TE Topology |       | Technology-specific |
          |  (profile)  |       |  Network Topology   |
          +-------------+       +---------------------+

This approach is more suitable in cases where the technology-specific Network Topology Model provides augmentation only to the constructs defined in the Network Topology Model, such as nodes, links, and termination points (TPs). Therefore, with this approach, only the generic attributes defined in the TE Topology Model could be used.¶

It is also worth noting that in this case, technology-specific augmentations for the bandwidth information could not be defined.¶

In principle, it would be also possible to define both a technology specific TE Topology Model which augments the TE Topology Model, and a technology-specific Network Topology Model which augments the Network Topology Model and to rely on the multiple inheritance capability, as shown in Figure 7:¶

                    +-----------------------+
                    |    Network Topology   |
                    +-----------------------+
                        ^               ^
                        |               |
           Augments +---+               +--+ Augments
                    |                      |
          +---------+---+       +----------+----------+
          | TE Topology |       | Technology-specific |
          |  (profile)  |       |  Network Topology   |
          +-------------+       +---------------------+
                 ^                         ^
                 |                         |
                 | Augments                | References
                 |                         |
      +----------+----------+              |
      | Technology-Specific +--------------+
      |     TE Topology     |
      +---------------------+

This option does not provide any technical advantage with respect to the first option, shown in Figure 5, but could be useful to add augmentations to the TE Topology constructs and to re-use an already existing technology-specific Network Topology Model.¶

It is worth noting that the technology-specific TE Topology model can reference constructs defined by the technology-specific Network Topology model but it could not augment constructs defined by the technology-specific Network Topology model.¶

{
  "ietf-network:ietf-network": {
    "ietf-te-topology:te-topology": {
      "example-te-topology": {}
    }
  }
}

{
  "ietf-network:ietf-network": {
    "ietf-te-topology:te-topology": {}
    "example-network-topology": {}
  }
}

{
  "ietf-network:ietf-network": {
    "ietf-te-topology:te-topology": {
      "example-te-topology": {}
    }
    "example-network-topology": {}
  }
}

      +--rw link* [link-id]
         +--rw link-id            link-id
         +--rw source
         |  +--rw source-node?   -> ../../../nw:node/node-id
         |  +--rw source-tp?     leafref
         +--rw destination
         |  +--rw dest-node?   -> ../../../nw:node/node-id
         |  +--rw dest-tp?     leafref
         +--rw supporting-link* [network-ref link-ref]
         |  +--rw network-ref
         |  |       -> ../../../nw:supporting-network/network-ref
         |  +--rw link-ref       leafref
         +--rw example-link-attributes
         |   <...>
         +--rw te!
            +--rw te-link-attributes
               +--rw name?                             string
               +--rw example-te-link-attributes
               |   <...>
               +--rw max-link-bandwidth
                  +--rw te-bandwidth
                     +--rw (technology)?
                        +--:(generic)
                        |  +--rw generic?   te-bandwidth
                        +--:(example)
                           +--rw example?   example-bandwidth

4. Implemented profiles

When a server implements a profile of the TE topology model, it is not clear how the server can report to the client the subset of the model being implemented.¶

It is also worth noting that the supported profile may also depend on other attributes (for example the network type).¶

In case the TE topology profile is reported by the server to the client, the server will report in the operational datastore only the leaves which have been implemented, as described in section 5.3 of [RFC8342].¶

More investigation is required in case the TE topology profile is configured by the client.¶

5. Security Considerations

This document provides only information about how the TE Topology Model, as defined in [RFC8795], can be profiled to address some scenarios which are not considered as TE.¶

As such, this document does not introduce any additional security considerations besides those already defined in [RFC8795].¶

6. IANA Considerations

This document requires no IANA actions.¶

Acknowledgments

The authors would like to thank Daniele Ceccarelli, Jonas Ahlberg and Scott Mansfield for providing useful suggestions for this draft.¶

This document was prepared using kramdown.¶

Previous versions of this document was prepared using 2-Word-v2.0.template.dot.¶

Contributors

Authors' Addresses