Modeling the Digital Map based on RFC 8345: Sharing Experience and Perspectives

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Please refer to the "Digital Map: Concept, Requirements, and Use Cases" [I-D.havel-nmop-digital-map-concept] for the definition of the following terms used in this document:¶

• Topology¶

• Multi-layered Topology¶

• Topology layer¶

• Digital Map¶

• Digital Map modelling¶

• Digital Map model¶

• Digital Map data¶

2.1. IETF Network Topology

[RFC8345] provides a simple generic topological model. It defines the abstract /generic /base model for network and service topologies. It provides the mechanism to model networks and services as layered topologies with common relationships at the same layer and underlay/overlay relationships between the layers.¶

[RFC8345] consists of two modules: 'ietf-network' and 'ietf-network-topology'. The 'ietf-network' module defines networks and nodes, while 'ietf-network-topology' module adds definitions for links and termination points.¶

The relationships inside the layer are containment/aggregation (a network has nodes, a network has links, a node has termination points), source (a link has one source termination point) and destination (a link has one destination termination point).¶

The relationships between the layers are modelled via supporting relationship:¶

• network A is supported by network B - this may model overlay/underlay relationship¶

• nodes, links and termination points of network A are supported by nodes, links and termination points of network B.
  Overlay and underlay nodes, links and termination points must match underlay and overlay networks supporting it¶

2.2. IETF Network Topology TE

[RFC8795] defines a YANG model for representing, retrieving and manipulating traffic engineering (TE) topologies. This is a more complex model which augments [RFC8345] with TE topology information as follows:¶

• TE nodes, links, and termination points are defined using the core RFC8345 concepts¶

  • TE topology augments 'ietf-network' with topology identifier (provider, client and topology id), as well as other 'TE' information¶

  • TE node augments 'node' with 'te-node-id' and other 'TE' information¶

  • TE link augments 'link' with 'TE' information¶

  • TE termination point augments termination point with 'te-tp-id' and 'TE' information¶

• Tunnel, tunnel termination point, local link connectivity, node connectivity matrix, and some supporting and underlay relationships are defined outside of the core RFC 8345 entities and relationships¶

2.3. Why RFC8345 is a Good Approach for Digital Map Modelling

The main reason for selecting RFC8345 for modelling is its simplicity and that is supports majority of the core requirements.¶

Please refer to the "Digital Map: Concept, Requirements, and Use Cases" [I-D.havel-nmop-digital-map-concept] for more details of the core Digital Map requirements:¶

The requirements REQ-BASIC-MODEL-SUPPORT, REQ-LAYERED-MODEL, REQ-PROG-OPEN-MODEL, REQ-STD-API-BASED, REQ-COMMON-APP, REQ-SEMANTIC, and REQ-LAYER-NAVIGATE are automatically fulfilled with RFC8345 and extensions:¶

• Basic model with network, node, link and interface entity types¶

• Layered topology¶

• Open and programmable¶

• Standard, multi-vendor¶

• Multi-domain¶

• Semantics for layered topology¶

• Inter-layer and between-layer relationships¶

The requirements REQ-SEMANTIC for semantics and REQ-LAYER-NAVIGATE for layered topology and relationships are partially fulfilled, there may be need for some additional semantics.¶

Other core requirements REQ-EXTENSIBLE, REQ-PLUGG and REQ-GRAPH-TRAVERSAL are not supported by [RFC8345]:¶

• Extensible with metadata¶

• Pluggable to other YANG modules and non-YANG data¶

• Optimized for graph traversal¶

In some cases, for REQ-PLUGG for pluggable to other YANG modules, the links are already done by augmenting 'ietf-network' and 'ietf-network-topology'. For others, we need to add some mechanisms to link the models and data.¶

3.1. What Is Not in The Base Model?

Based on some shared experience, the following are listed as set of candidate extensions to [RFC8345] for Digital Map modelling and APIs:¶

RFC8345-GAP-BIDIR:

An alternate approach to model bidirectional links¶

RFC8345-GAP-MULTI-POINT:

An alternate approach to multi-point connectivity¶

RFC8345-GAP-MULTI-DOMAIN:

Links between domains/networks¶

RFC8345-GAP-SUBNETWORK:

A network decomposition into sub-networks¶

RFC8345-GAP-MULTI-NETWORK:

Nodes, links, and termination points belonging to different networks¶

RFC8345-GAP-SUPPORTING:

Supporting relationships between different types of entities¶

RFC8345-GAP-SEMANTIC:

More network topology related semantic is needed¶

RFC8345-GAP-PLUGG:

How to connect in a generic way to other YANG modules and data¶

3.2. Plug-in other IETF YANG data models (RFC8345-GAP-PLUGG)

We need a new RFC8345 augmentation for the purpose of connecting IETF topology modules to other IETF YANG modules. In some cases, this are already done by augmenting 'ietf-network'
and 'ietf-network-topology'. For others, we need to add some mechanisms to link the IETF topology to other models and data.¶

The mechanims must specify the following:¶

• What category? What is the category of the external YANG model (e.g. configuration, assurance, performance, ..)¶

• Which protocol? Is the information retrieved via netconf, restconf, ..¶

• Which server? Where the information can be retrieved from (the same controller or some other restconf/netconf server)¶

• Which instance? How to connect IETF topology module instances to other IETF YANG module instances (because we have different keys)¶

• Which path? What yang paths contain external data for network, node, termination-point, link¶

There are two ways how this can be defined:¶

• USER DEFINED: External user defines how to connect topology to external YANG module in a generic way via some Digital Map API. This information is than retrieved from the application via the Digital Map API and application can automatically build the request for retrieval of external data.¶

• CONTROLLER DELEGATED: Delegated to the controller, who gives back info how to connect to external modules for each instance¶

The following are the candidate approaches how we can address this limitation:¶

• BASIC: Dont propose any new mechanism, leave to different augmentations to solve the problem their own way¶

• AUGMENT: Augment RFC8345 with some Digital Map plugin module¶

• NEW-MODULE: Create a new Digital Map plugin module that is used for building relations between the Digital Map model/data and other IETF models/data¶

We implemented the basic approach in IETF120 Hackathon, where we duplicated the properties of IS-IS at the controller API via augmenting the RFC8345 with technology specific module. This was done just to explain the problem, knowing that the more sofisticated solution is needed. We need to implement more advanced option for connecting ietf-l2-isis-topology to ietf-isis. The solution must be generic to support any other augmentation and yang files. We suggest to analyze the second (AUGMENT) and third (NEW-MODULE) approach in the IETF121 hackathon, together with 2 approaches how that information can be defined (USER DEFINED or CONTROLLER DELEGATED) and come back with the reccomendation.¶

3.3. Open Issues (for Further Analysis or Resolved)

The following are the open issues that need further analysis or have been resolved:¶

• Do we need separation of L2 and L3 topologies?¶

  During the PoC/Hackathon we encountered different solutions with separate set of requirements. In one solution, the L2 and L3 topology were the same with separate set of attributes, while in another solution we had difference in L2 and L3 topology (e.g. Links Aggregation, Switches and Routers).¶

  The RFC8944 defines L2 topology and RFC8346 defines the L3 topology. They allow to have either one or two instances of this topology.¶

  The decision if we need separate network instances for L2 and L3 topologies may be based on specific network topology and provider's preferences.¶

  Resolved: the RFC8345 is flexible and it can support both the same network instance with L2 + L3 augmentations or separate network instances with supporting relationship between. The operator should decide what option is needed for their solution.¶

• Do we need sublayers as well? Layers versus sublayers versus layered instances?¶

  Resolved: Layers/sublayers could be implemented via multiple network types. The new data nodes for layer are present only when the network type for the layer is present. The new data nodes for the sublayer are present when the network types for both layer and sublayer are present. The solution could also enable either single or multiple instances, like in the previous point.¶

  Further analysis: In the case that the same technology is used at different layers, we may need some additional information in the model, in the case that it cannot be modelled via network types + supporting relations.¶

• Same technology at service versus underlay? BGP per VPN vs common BGP shared between multiple VPNs. Different layers, same model, relationship define the layer.¶

  Further analysis is needed.¶

• There are potential circular dependencies in layering. For example routing can be underlay for tunnels, but tunnel interface can also be in the routing table.¶

  Further analysis is needed.¶

• Best way to build the connection to other YANG modules for navigation.¶

  Further analysis and prototypes at the future Hackathons¶

4.1. Why Analysis?

During our PoC and Hackathon, we decided to use the RFC8345 model and API for the layered topology from the physical to the top layer, accross the domains, without the need to understand any specific information about specific domain, technologies and details required for specific network management functions / use cases.¶

We took the hat of application developer and used the software architecture guidelines to provide the right level of abstraction for topologies at the controller northbound interfaces. This means that the API client /application must understand and draw the topology from RFC8345 (as originally intended by this draft) without understanding all augmentations that add new topological entities / relations.¶

After determining that the RFC8345 can provide the right level of abstraction for the layered topology (and be improved by addressing gaps via backward compatible way), we wanted to understand if different IETF RFC8345 augmentations add its own topology semantics and if they address any gaps we identified.¶

4.2. What did we Analyse?

Our goal was to do some high level analysis of all the modules that augment the RFC8345 and understand the following 2 high level points:¶

• What is the purpose of augmentation?¶

  • Is it augmenting topology for some identified topology gaps?¶

  • Is it augmenting topology for some specific functionality, like TE. Functional category TE, Technology Generic.¶

  • Is it augmenting topology for some specific technology, like ISIS. Technology L3 ISIS¶

  • Is it augmenting to connect to some other modules, like Inventory, PM?¶

• How it the augmented info added?¶

  • By adding the attributes, events, using the types, new relations (non-topological) no impact on topology. Layered topology can be understood / drawn using the RFC8345.¶

  • By adding the topological entities and topological relations – full impact on topology. Layered topology cannot be understood / drawn using the RFC8345.¶

  • By adding some additional topological semantics – partial impact on topology (e.g. hub / spoke). Layered topology can be understood/drawn but roles will not be understood.¶

4.3. RFC8345 Augmentations that add Topology Semantics

The most important result of our analysis would be extension categories that add new topological entities and new topological relations. This means that we would not be able to use RFC8345 for understand/draw the layered topology. Examples:¶

• RFC8795 [RFC8795]:¶

  • We have TE Topology and TE Nodes, LTPs, TE Links modelled using the abstract RFC8345 topology¶

  • we have tunnels and TTPs + underlay outside of abstract RFC8345 topology¶

• RFC8542 [RFC8542]:¶

  • we have fabric network, fabric and fabric tps modelled using the abstract RFC8345 topology¶

  • we have device nodes, device links, device ports + relations between them modelled outside of the abstract RFC8345 topology¶

This means that the API client /application cannot understand and draw the topology from RFC8345 (as originally intended by this draft) without understanding all augmentations that add new topological entities / relations.¶

4.4. Summary of RFC8345 Augmentation Analysis Results

Our full analysis is on github and is still work in progress, waiting for different authors to confirm our conclusions. The full current analysis results can be found on https://github.com/ietf-wg-nmop/Misc/tree/main/Digital-Map-Analysis.¶

We will present only the current summary of the RFC8345 Augmentation Analysis in this draft:¶

• We started our analysis by identifying the 102 YANG modules, based on the info from the YANG catalog at the moment we started analysis.¶

• We determined that out of those 102 YANG modules, 27 were deprecated¶

• We determined that out of those 102 YANG modules, 23 were expired¶

• We determined that out of those 102 YANG modules, 8 were Non-NMDA compliant¶

• That left us with 44 modules to analyze, including the 2 RFC8345 modules¶

• We then continued to identify the following about each of the modules, please see the subsequent sections for more details:¶

  • Authors¶

  • Functional Category¶

  • Use Cases (outstanding)¶

  • Technology¶

  • Network Types¶

  • Organization¶

  • Maturity Level¶

  • What modules are imported / augmented¶

  • Extensions Categories¶

  • What topology concepts they use or add¶

• We identified that out of 44 modules analyzed¶

  • 41 are importing ietf-network¶

  • 33 are importing ietf-network-topology¶

  • 12 are importing ietf-te-topology¶

  • there may be others using indirectly ietf-te-topology without importing the module, for example we identified that do it via import of ietf-te and te-types¶

4.5. RFC8345 Augmentations Analysis Conclusion

We determined after the analysis that we need to start working on the guidelines to create a Digital Map. The RFC8345 augmentations are not consistent, which makes it very hard to deploy the multi-layer digital map.¶

5.1. Guidelines for Generic Digital Map Extensions

Generic Digital Map extensions are the RFC8345 extensions required for all technologies and layers in the Digital Map. We already discussed some options for individual limitations in the previous sections, here is the summary:¶

1. Use the current RFC8345 approach, leave to different augmentations
to solve the problem their own way

2. Augment RFC8345 network, node, link and termination point for any
changes needed from a new digital map module

   module: dm-network-topology
           augment /nw:networks/nw:network:
                   .... additions
           augment /nw:networks/nw:network/nw:node:
                   .... additions
           augment /nw:networks/nw:network/nt:link:
                   .... additions
           augment /nw:networks/nw:network/nw:node/nt:termination-point:
                   .... additions


   // This can be a separate draft with describing pros and cons of
   // different approaches and yang model proposal.  Add reference to
   // this draft when submitted

3. Make backward compatible updates to RFC8345, work on RFC8345 bis

The following are some important guidelines mentioned in the RFC8345 that should be taken into account when suggesting the approach:¶

• "The data models allow applications to operate on an inventory or topology of any network at a generic level, where the specifics of particular inventory/topology types are not required. At the same time, where data specific to a network type comes into play and the data model is augmented, the instantiated data still adheres to the same structure and is represented in a consistent fashion.
  This also facilitates the representation of network hierarchies and dependencies between different network components and network types"¶

• “It is possible for links at one level of a hierarchy to map to multiple links at another level of the hierarchy.
  For example, a VPN topology might model VPN tunnels as links. Where a VPN tunnel maps to a path that is composed of a chain of several links, the link will contain a list of those supporting links. Likewise, it is possible for a link at one level of a hierarchy to aggregate a bundle of links at another level of the hierarchy."¶

Our recommendation on how to extend RFC8345 for Digital Map is to stay in spirit of RFC8345 and augment with non-topological info only. Reuse network, node, link, tp for all topological entities, reuse supporting for layering and add new properties/attributes and references to other modules Therefore, we suggest to work on RFC8345 bis to provide the backward compatible way to address all identified limitations.¶

The alternative of having the core topology augmentations in either TE modules or technology specific modules is not generic enough and is not in the spirit of having the core topology model to model topology in the consistent manner between different technologies and TE and non-TE topologies.¶

5.2. Guidelines for New Technologies/Layers Extensions

There are already drafts that support augmentation for specific technologies. These drafts augment network, node, termination point and link, but also add different topological entities inside augmentations. For example, we have examples like this:¶

   module: new-module
           augment /nw:networks/nw:network/nw:network-types:
         +--rw new-topology!
                   augment /nw:networks/nw:network:
                                   ....
                   augment /nw:networks/nw:network/nw:node:
                           .... adding list of tps of other type
                                    (e.g. tunnel TPs in TE draft)
                           ... adding new supporting relationship
                                    supporting-tunnel-termination-point
                                    (te draft)
                   augment /nw:networks/nw:network/nt:link:
                                   .... adding tunnels (te draft)
                   augment /nw:networks/nw:network/nw:node/
                                                 nt:termination-point:
                                   ....

There is a need to agree some guidelines for augmenting IETF network topology, so that additional topological information is not added in the custom way. There is also need to categorize the current augmentations and the impact of RFC 8345 bis based on what has been added for different technologies:¶

• new properties/attributes (e.g. ietf-l2-topology, ietf-l3-unicast-topology, ietf-isis-topology)¶

• new events (e.g. ietf-l2-topology)¶

• new topological entities (e.g. ietf-te-topology, ietf-dc-fabric-topology)¶

• new topological relations (e.g. ietf-te-topology)¶

• type reuse (e.g. ietf-dots-telemetry, ietf-dc-fabric-types, ietf-dc-fabric-topology)¶

<-- This can be a separate draft. Guidelines with examples? Add reference to this draft when submitted -->¶

5.3. Guidelines for Digital Maps Connections to Other Components

Digital Map must be pluggable:¶

• We must connect to other YANG modules for inventory, configuration, assurance, etc¶

• Not everything can be in YANG, we need to connect digital map YANG model with other modelling mechanisms, both southbound, northbound and internally¶

Also, there are already some modules that connect network topology to other YANG modules. We will investigate different approaches and propose the best practices. The following are some existing approaches proposed in IETF:¶

• How to connect network topology to interface [I-D.draft-ietf-ccamp-if-ref-topo-yang]¶

• How to connect network topology to hardware inventory [I-D.ietf-ccamp-network-inventory-yang]¶

• How to connect network topology to ivy inventory [I-D.draft-wzwb-ivy-network-inventory-topology]¶

• How to connect network topology to performance monitoring [RFC9375]¶

We did the initial implementation during the IETF120 Hackathon that focused on showing the problem via duplicating the attributes of IETF-ISIS in RFC8345 augmentations. We need better solution and will continue analysis and prototype in the future Hackathons.¶

5.4. Digital Map APIs

This will include hierarchical APIs for cross-domain figure, IETF YANG Based API (read and write, change subscription and notify) and Query API¶

5.5. Digital Map Knowledge

The following knowledge was needed to build Digital Map:¶

• Abstract IETF Entities and Relationships as in [RFC8345]¶

• [RFC8345] Augmentations for a)Layers/sublayers b)Entities (services and subservices), c)Properties¶

• Rules for aggregating entities¶

• Rules for instantiating relationships (inter-layer and intra- layer)¶

• Mapping from devices and controllers¶

What can be achieved with existing RFC8345 YANG:¶

• Entities (base class IETF Network, IETF Node, IETF Link, IETF TP)¶

• Properties¶

• Relationships¶

Next steps¶

• How to support temporal¶

• How to support spacial¶

• How to support historical¶

9.1. Normative References

[I-D.havel-nmop-digital-map-concept]

Havel, O., Claise, B., de Dios, O. G., and T. Graf, "Digital Map: Concept, Requirements, and Use Cases", Work in Progress, Internet-Draft, draft-havel-nmop-digital-map-concept-00, 4 July 2024, <https://datatracker.ietf.org/doc/html/draft-havel-nmop-digital-map-concept-00>.

[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/rfc/rfc2119>.

[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/rfc/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/rfc/rfc6242>.

[RFC8040]

Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/rfc/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/rfc/rfc8174>.

[RFC8345]

Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, <https://www.rfc-editor.org/rfc/rfc8345>.

[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/rfc/rfc8346>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

[RFC8795]

Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Gonzalez de Dios, "YANG Data Model for Traffic Engineering (TE) Topologies", RFC 8795, DOI 10.17487/RFC8795, August 2020, <https://www.rfc-editor.org/rfc/rfc8795>.

[RFC8944]

Dong, J., Wei, X., Wu, Q., Boucadair, M., and A. Liu, "A YANG Data Model for Layer 2 Network Topologies", RFC 8944, DOI 10.17487/RFC8944, November 2020, <https://www.rfc-editor.org/rfc/rfc8944>.

[RFC9130]

Litkowski, S., Ed., Yeung, D., Lindem, A., Zhang, J., and L. Lhotka, "YANG Data Model for the IS-IS Protocol", RFC 9130, DOI 10.17487/RFC9130, October 2022, <https://www.rfc-editor.org/rfc/rfc9130>.

9.2. Informative References

[Catalog]

YANG Catalog, "YANG Impact Analysis", n.d., <https://yangcatalog.org/yang-search/impact_analysis/ietf-network-topology@2018-02-26>.

[Digital_Map_Hackathon]

NMOP, "Digital Map Hackathon IETF 120 Presentation", n.d., <https://datatracker.ietf.org/meeting/120/materials/slides-120-hackathon-sessd-digital-map-hackathon-00>.

[Digital_Map_Hackathon_Code]

NMOP, "Digital Map Hackathon IETF 120 Code", n.d., <https://github.com/digital-map-exp/digital-map-public>.

[I-D.davis-opsawg-some-refinements-to-rfc8345]

Davis, N., Havel, O., and B. Claise, "Some Refinements to Network Topologies (RFC8345)", Work in Progress, Internet-Draft, draft-davis-opsawg-some-refinements-to-rfc8345-01, 10 January 2024, <https://datatracker.ietf.org/doc/html/draft-davis-opsawg-some-refinements-to-rfc8345-01>.

[I-D.draft-ietf-ccamp-if-ref-topo-yang]

Ahlberg, J., Mansfield, S., Ye, M., Busi, I., Li, X., and D. Spreafico, "A YANG Data Model for Interface Reference Topology", Work in Progress, Internet-Draft, draft-ietf-ccamp-if-ref-topo-yang-01, 18 October 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-if-ref-topo-yang-01>.

[I-D.draft-wzwb-ivy-network-inventory-topology]

Wu, B., Zhou, C., Wu, Q., and M. Boucadair, "A Network Inventory Topology Model", Work in Progress, Internet-Draft, draft-wzwb-ivy-network-inventory-topology-01, 29 April 2024, <https://datatracker.ietf.org/doc/html/draft-wzwb-ivy-network-inventory-topology-01>.

[I-D.ietf-ccamp-network-inventory-yang]

Yu, C., Belotti, S., Bouquier, J., Peruzzini, F., and P. Bedard, "A YANG Data Model for Network Hardware Inventory", Work in Progress, Internet-Draft, draft-ietf-ccamp-network-inventory-yang-02, 9 July 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-network-inventory-yang-02>.

[I-D.ietf-netmod-rfc8407bis]

Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", Work in Progress, Internet-Draft, draft-ietf-netmod-rfc8407bis-19, 21 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-19>.

[I-D.ogondio-nmop-isis-topology]

de Dios, O. G., Barguil, S., Lopez, V., Ceccarelli, D., and B. Claise, "A YANG Data Model for Intermediate System to intermediate System (IS-IS) Topology", Work in Progress, Internet-Draft, draft-ogondio-nmop-isis-topology-00, 4 March 2024, <https://datatracker.ietf.org/doc/html/draft-ogondio-nmop-isis-topology-00>.

[RFC8542]

Zhuang, Y., Shi, D., Gu, R., and H. Ananthakrishnan, "A YANG Data Model for Fabric Topology in Data-Center Networks", RFC 8542, DOI 10.17487/RFC8542, March 2019, <https://www.rfc-editor.org/rfc/rfc8542>.

[RFC9375]

Wu, B., Ed., Wu, Q., Ed., Boucadair, M., Ed., Gonzalez de Dios, O., and B. Wen, "A YANG Data Model for Network and VPN Service Performance Monitoring", RFC 9375, DOI 10.17487/RFC9375, April 2023, <https://www.rfc-editor.org/rfc/rfc9375>.