Some Refinements to Network Topologies (RFC8345)

3.1. RFC8345 section 4.2 Base Network Topology Data Model

The following text appears in the current RFC.¶

[[RFC8345 TEXT EXTRACT BEGINS]]¶

A link is identified by a link-id that uniquely identifies the link within a given topology. Links are point-to-point and unidirectional. Accordingly, a link contains a source and a destination. Both source and destination reference a corresponding node, as well as a termination point on that node. Similar to a node, a link can map onto one or more links (which are terminated by the corresponding underlay termination points) in an underlay topology. This is captured in the list "supporting-link".¶

[[RFC8345 TEXT EXTRACT ENDS]]¶

The existing RFC8345 makes a number of key points that are extracted and quoted in bullets below. Each point is followed by an observation that leads to the proposal.¶

• "Links are point-to-point and unidirectional."¶

• • Observation: This restriction is the primary focus of this draft. It is proposed here that the breadth of applications can benefit significantly from a multipoint uni/bi definition as described in this draft.¶

• ".. a link contains a source and a destination."¶

• • Observation: But it is clear that, as the properties defined in the current RFC are "require-instance false", a link can be described in valid YANG that has no source and no destination, i.e., no termination points.¶

• "Both source and destination reference a corresponding node, as well as a termination point on that node."¶

• • Observation: But in the YANG the reference can have a node alone. Under some circumstances, this may be a valid choice, although it is not clear whether the specific usages currently defined can tolerate this.¶

3.2. RFC8345 section 4.4.5 Cardinality and Directionality of Links

The following text appears in the current RFC.¶

[[RFC8345 TEXT EXTRACT BEGINS]]¶

The topology data model includes links that are point-to-point and unidirectional. It does not directly support multipoint and bidirectional links. Although this may appear as a limitation, the decision to do so keeps the data model simple and generic, and it allows it to be very easily subjected to applications that make use of graph algorithms. Bidirectional connections can be represented through pairs of unidirectional links. Multipoint networks can be represented through pseudonodes (similar to IS-IS, for example). By introducing hierarchies of nodes with nodes at one level mapping onto a set of other nodes at another level and by introducing new links for nodes at that level, topologies with connections representing non-point-to-point communication patterns can be represented.¶

[[RFC8345 TEXT EXTRACT ENDS]]¶

The existing RFC8345 text above provides an argument for the unidirectional solution and also provides a "work round" for more complex cases.¶

In the existing RFC8345 text, above, there are a number of key points that are extracted and quoted in bullets below. Each point is followed by an observation that leads to the proposal.¶

• "[the model] does not directly support multipoint and bidirectional links. Although this may appear as a limitation, the decision to do so keeps the data model simple and generic"¶

• • Observation: But, as will become apparent, the multipoint uni/bi model is equally generic and arguably as simple whilst covering all cases of link including unidirectional point to point. Hence, this draft considers the restriction of the current RFC, to allow only point to point unidirectional, a limitation, not an efficiency.¶

  • Observation: Multipoint uni/bi supports point to point (only two points declared) unidirectional (directionality selection) and hence can cover all cases covered by RFC8345 today as well as multipoint cases.¶

  • Observation: Existing models could be transformed to the multipoint uni/bi form and, where appropriate, the multipoint uni/bi form could be used to represent multipoint cases as a set of point to point links (as is done using the current model).¶

• "it allows it to be very easily subjected to applications that make use of graph algorithms"¶

• • Observation: The model is targeted at interface transfer. From practical experience it is clearly always necessary to perform some level of graph transformation prior to use by an algorithm in an application. The transformation from multipoint uni/bi has been shown to be straight forward in real solutions.¶

  • Observation: Other transformations that are required include the interface entity becoming one or more transitional links in the topology (so as to produce a flat topology for multilayer routing). These transformation, whilst still quite straight forward are clearly more complex than the multipoint uni/bi transformation.¶

  • Observation: Some graph applications work with bidirectional multipoint models. The multipoint construct, the hyperedge, appears in hypergraph theory which actually better reflect the reality of networking.¶

• "Bidirectional connections can be represented through pairs of unidirectional links."¶

• • Observation: Whilst true, this doubles the number of instances for many applications, which is especially significant considering that bidirectional usages are very common.¶

• "Multipoint networks can be represented through pseudonodes (similar to IS-IS, for example)."¶

• • Observation: But multipoint link constructs appear from multipoint servers. There are many practical/real cases of multipoint links. Many years of deployment of management/control solutions have exposed both the reality and the benefit of multipoint constructs which is why TM Forum developed the concept and adopted it in interface models and why ONF took the lessons and adopted the same construct pattern both in the core model [ONF TR-512] and in TAPI [ONF TAPI].¶

  • Observation: Adding a pseudo node further increases the number of instances and does not address the challenge of the partial connectability of many constructs such as root-leaf. The multipoint solution is essentially the pseudo node without the need for the links. The connectability restrictions need to be described in associated metadata (specification such as described in [ONF TR-512.7] (in the sections on ForwardingConstruct specification).¶

  • Observation: The relative efficiency of the multipoint uni/bi solution will become clear in later sections.¶

3.3. From the code: "list link {"

The description for link reiterates the source destination definition and notes that the link does not model "multipoint".¶

[[RFC8345 CODE EXTRACT BEGINS]]¶

 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.";
     }

[[RFC8345 CODE EXTRACT ENDS]]¶

3.4. From the code: "container source {"

The code continues with a definition of the source. This definition allows, via "require-instance false;" for either source-node or source-tp or both to be absent. Clearly, considering the definition 'path "../../../nw:node[nw:node-id=current()/../"+"source-node]/termination-point/tp-id";' the source-tp cannot be present without the source-node, but the source-node can be present without the source-tp. This may be useful in some applications, although it is not clear whether particular applications were considered (and if a link end only resolved to a node were not intentional, then it is not clear why a simple TP path was not all that was provided (as that would locate the node as well as the TP)). It is also not clear whether the opportunity to not report a source end was intended to cover a single ended link case where the destination is stated alone as the source is unknown/unresolvable. This approach has been used in other solutions where a string carried the information about the far end (as the point was outside the scope of the controller and hence the identifier was "foreign"). No description of this was found in RFC8345 and a string form of the end has not been provided.¶

The code provides a description for source which is ambiguous and would benefit from some improvement "Source node identifier. Must be in the same topology.". It is assumed that this "same" means must be the "same topology as the link that it is the source of". This could be stated more clearly.¶

[[RFC8345 CODE EXTRACT BEGINS]]¶

     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.";
       }
     }

[[RFC8345 CODE EXTRACT ENDS]]¶

When both source-node and source-tp are not present the structure "container source {" can be omitted from the instance as it is not a "presence container" as described in RFC6020.¶

[[RFC6020 TEXT EXTRACT BEGINS]]¶

7.5.1. Containers with Presence¶

YANG supports two styles of containers, those that exist only for organizing the hierarchy of data nodes, and those whose presence in the configuration has an explicit meaning.¶

In the first style, the container has no meaning of its own, existing only to contain child nodes. This is the default style.¶

For example, the set of scrambling options for Synchronous Optical Network (SONET) interfaces may be placed inside a "scrambling" container to enhance the organization of the configuration hierarchy, and to keep these nodes together. The "scrambling" node itself has no meaning, so removing the node when it becomes empty relieves the user from performing this task.¶

[[RFC6020 TEXT EXTRACT ENDS]]¶

3.5. From the code: "container destination {"

The code continues with a definition of the destination. This is of the same form as the source and can also be absent such that a link with no ends is valid in YANG. It is not clear what case this would apply to (perhaps some transitional state).¶

The destination definition differs from the source in that the description for the node indicates that it must be in the "same network" and not "same topology" as in the source. One is clearly in error (minor).¶

[[RFC8345 CODE EXTRACT BEGINS]]¶

     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.";
       }
     }

[[RFC8345 CODE EXTRACT ENDS]]¶

4.1. Observations

As noted, a link can have no source and no destination. This leads to an opportunity for a simple approach to enhancement by providing an additional optional link end definition in the structure. The addition appears to be YANG backward compatible as existing point-to-point unidirectional solutions can continue to operate unchanged.¶

4.2. Essential Enhancement and usage

The additional optional link end definition is effectively a list of point references where the point reference definition is the same as the point reference definition in the existing source and destination structures. Each list member has, in addition to the point reference, a point-direction and a point-role.¶

The link also gains a link-type property that essentially references a definition of the effective internal structure of the link. The point-role is meaningful with respect to this link-type. For example, a ROOT_AND_LEAF link-type would have point-roles ROOT and LEAF and the definition of ROOT_AND_LEAF would express that information can flow from any LEAF to the ROOT and from the ROOT to any LEAF, but that flow from LEAF to LEAF is not allowed. Ideally the link-type would reference a machine interpretable specification of capability that would express these capabilities and limitations.¶

The point-direction property in each end definition would express the flow with respect to the link boundary so EGRESS_FROM_LINK is flowing out of the link and INGRESS_TO_LINK is flowing into the link. A BIDIRECTIONAL point supports both ingress and egress flows.¶

A point could be augmented with properties where appropriate for a particular application. Where the point is BIDIRECTIONAL there could be unidirectional augments, one for ingress and one for egress. A link-direction property is also added to simplify interpretation of some common cases. This property takes the values BIDIRECTIONAL (where all points are BIDIRECTIONAL), UNIDIRECTIONAL (where each point is either INGRESS_TO_LINK or EGRESS_FROM_LINK) and MIXED_DIRECTION (where there is no restriction on the mix of point-direction such that some points may be BIDIRECTIONAL and others INGRESS_TO_LINK etc.).¶

The machine interpretable specification is not fundamentally necessary as a traditional approach of coding an understanding of each standard link-type would work reasonably well. However, a machine interpretable specification would enable a client to deal with link-types that it had not encountered but through interpretation of the specification could "understand". The specification could take a, somewhat verbose, form of connectivity matrix or could take the, more sophisticated and compact, form of rule system to describe interior arrangement and the effect of the link. An example rule system can be found in [ONF TR-512.7]. A fully generalized solution would need to take advantage of concepts set out in [mobo].¶

8.1. Termination direction

The termination point could benefit from a direction statement as some terminations are inherently unidirectional and others bidirectional. Termination direction is a capability statement. Termination state can be different for the ingress/receive direction from the egress/transmit direction. Termination direction is challenging in that a termination has both an upper and a lower side (orientation as per overlay and underlay). Both sides may have both ingress and egress. Work has been done in several external bodies (e.g., ONF in [ONF TR-512] on this challenge and that input should be sought prior to embarking on this addition.¶

8.2. Specification of capability

A termination point represents the presence of a capability to deal with flows. The termination point is silent on the actual capability. The capability of a termination point is dependent upon the underlying functionality supporting it. Functionality tends to be systematically deployed such that each termination point is of a type where there are many instances of that type in a deployment and where each termination point of a type has the same characteristic to each other. For any particular type of termination, its capability is invariant in specific value for some properties, invariant in range of values for some properties and invariant in algorithm to determine value for some properties. The statement of invariants per type is best stated in a single place and referenced by each instance. This statement could be called a type specification (as in [ONF TR-512]). Clear statement of range etc. benefits from work pointed to in [mobo]. It is suggested here that this aspect is vital for other work such as that in the area of digital twin such that it would potentially become part of the [Digital Map].¶

8.3. Links between networks/subnetworks/domains

The current definition in RFC8345 is limited to links within a network. There are many cases where links pass between networks. A challenge, tackled by other bodies in similar work, is the representation of a link, within a controller, that passes from a network that is in the view of that controller to a network that is not (or between two parts of what could be considered as one network by an external observer, where only one part is in the view of the controller). Work should be carried out to develop inter-network link modeling where that modeling accounts for both the case where all ends of the link are in the view of a single controller and the case where some ends are not in the view of a controller that is having to provide the representation.¶

Note that a "foreign" identifier in one or more ends may be the appropriate solution as touched on earlier in this draft.¶

8.4. Richness of navigation

Not all possible navigations through the topology are defined in the model. There is always a dilemma here. Should the model show all possible navigations such that every relationship becomes two way (e.g., termination point relates to link end and link end to termination point), as of course, that may be what is required in an application that navigates the topology, or should the model provide only one direction and leave it to the application to populate the other (obvious) reverse relationship if it needs it. When considering transfer of information on an interface, it is redundant to send both directions of navigation and, if the entities which now refer to each other are propagated non-transactionally, there can be a temporary inconsistency (which, of course, is where eventual consistency comes in). There is a larger loop version of this challenge where there is a minimal set of relationships that sufficiently describes the topology, but where that may differ from the specific incomplete set (necessary for a particular application). As noted earlier, it is "always" the case that an application needs to do some transformation on the representation of semantics received from some other control component. It is important to agree where the intention is to provide a minimal set of relationships from which all others can be derived, a full set of all possible relationships which can then be pruned, or something in between (which is where we normally end up when the music stops).¶

8.5. Clarification of relationship roles

In this draft, it is recognised that there is a role of a point in the link (e.g., root in a root/leaf configuration). Other relationships may also require a similar role clarification. In work in other bodies (e.g., [ONF TR-512]), it was recognised that the fully functional representation of the termination/interface/etc. had potentially complex relationships to other equivalents and to links/connections. This leads to a consideration that all representations of functional entities could benefit from a modeling treatment using the component/system pattern [ONF TR-512.A.2]. This area has not been fully explored and at this stage appears to add significant, potentially opaque, complexity to many model areas. It should be noted however, that this is the underpinning of the "points & roles" model for link proposed here that is clearly highly beneficial and very transparent.¶

8.6. More than just links and termination points

In work in other bodies in this area, it has been recognised that there is a general model of potential for flow consistent with that set out in RFC8345, but that there is also a general model of termination function and flow. Work on this area to improve coherence in modeling would be highly beneficial for the [Digital Map].¶

8.7. Layering and sub-layering

Other bodies have grappled with the challenge of defining what a layer really is. This area requires further consideration to ensure it is clear in RFC8345. As this is clarified, it may become apparent that better indication of layering is required on the specific entities of RFC8345.¶

10.1. Standards driven implementations

Multipoint uni/bi appears in several TMF standards such as MTNM (Multi-Technology Network Management) [TMF MTNM], which defines interfaces for interaction between a network managers and sub-network/element managers, where several entities including TopologicalLink and SubNetworkConnection use a multipoint uni/bi representation. These models date back to the early 2000s and the standards were deployed by many vendors.¶

More recently ONF adopted the model in core work [ONF TR-512] and TAPI [ONF TAPI] and there are implementations available that take advantage of both multipoint uni/bi connections and multipoint uni/bi links. Some implementations have been approved by TIP MUST [TIP MUST]. Major implementations of TAPU are proprietary at this point, but interoperability evaluations are ongoing between products from various vendor using the TAPI standards initially hosted by OIF (as proof-of-concept exercises) [OIF PoC] but more recently as part of operator deployment. Many of these products also take advantage of multipoint uni/bi models internally.¶

10.2. Proving the model

It is anticipated that a PoC activity to exercise the proposal be carried out as part of the digital map work [Digital Map].¶

A.1. Examples of multipoint

There are many examples of multipoint links¶

  +-------------------------+
  | Root              Leaf  |
  |       ------------------<
  |      /   --------------->
  |     /   /               |
  |    /   /                |
  <---+---/----+------------<
  >------+---+--\----------->
  |           \  \          |
  |            \  \         |
  |             \  ---------<
  |              ----------->
  |                         |
  +-------------------------+

  +-------------------------+
  | Protected    Protecting |
  |           --------------<
  |       /o-/    ---------->
  |   ---X       /    main  |
  |  /     o-\  /           |
  <--         -/------      |
  >-----------+       \     |
  |            \       \    |
  |             \       \   |
  |              \       ---<
  |               ---------->
  |                standby  |
  +-------------------------+

A.2. Augmentation pattern

RFC 8345 pruned/adjusted snippet.¶

[[CODE BEGINS]]¶

 augment "/nw:networks/nw:network" {
   list link {
     key "link-id";
     leaf link-id {
       type link-id;
     }
     container source {
       leaf source-node {
         type string;
       }
     }
   }
 }

[[CODE ENDS]]¶

Alternative form:¶

[[CODE BEGINS]]¶

 augment "nw:networks/nw:network/nw:link" {
   container source {
     uses source-properties;
   }
 }

 augment "/nw:networks/nw:network" {
   list link {
     key "link-id";
     leaf link-id {
       type link-id;
     }
   }
 }

     grouping source-properties {
       leaf source-node {
         type string;
       }
     }

[[CODE ENDS]]¶

A JSON instance conformant to the first form above is also conformant to the second, alternative, form.¶