Internet DRAFT - draft-busizheng-teas-yang-te-mpls-topology
draft-busizheng-teas-yang-te-mpls-topology
TEAS Working Group I. Busi
Internet-Draft Huawei Technologies
Intended status: Standards Track A. Guo
Expires: 24 April 2024 Futurewei Inc.
X. Liu
Alef Edge
T. Saad
R. Gandhi
Cisco Systems, Inc.
22 October 2023
A YANG Data Model for MPLS-TE Topology
draft-busizheng-teas-yang-te-mpls-topology-06
Abstract
This document defines a YANG data model for representing, retrieving,
and manipulating MPLS-TE network topologies. It is based on and
augments existing YANG models that describe network and traffic
engineering packet network topologies.
This document also defines a collection of common YANG data types and
groupings specific to MPLS-TE. These common types and groupings are
intended to be imported by modules that model MPLS-TE technology-
specific configuration and state capabilities.
The YANG models defined in this document can also be used for MPLS
Transport Profile (MPLS-TP) network topologies.
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 24 April 2024.
Busi, et al. Expires 24 April 2024 [Page 1]
Internet-Draft MPLS-TE Topology YANG Model October 2023
Copyright Notice
Copyright (c) 2023 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 3
2. MPLS-TE Types Overview . . . . . . . . . . . . . . . . . . . 4
3. MPLS-TE Topology Model Overview . . . . . . . . . . . . . . . 4
3.1. TE Label Augmentations . . . . . . . . . . . . . . . . . 5
3.2. MPLS-TP Topology . . . . . . . . . . . . . . . . . . . . 6
4. YANG model for common MPLS-TE Types . . . . . . . . . . . . . 7
5. YANG Model for MPLS-TE Topology . . . . . . . . . . . . . . . 9
5.1. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. YANG Code . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
This document defines a YANG data model for representing, retrieving,
and manipulating MPLS-TE network topologies. It is based on and
augments existing YANG models that describe network and traffic
engineering packet network topologies.
Busi, et al. Expires 24 April 2024 [Page 2]
Internet-Draft MPLS-TE Topology YANG Model October 2023
This document also defines a collection of common YANG data types and
groupings specific to MPLS-TE. These common types and groupings are
intended to be imported by modules that model MPLS-TE technology-
specific configuration and state capabilities, such as the MPLS-TE
topology model, defined in this document, and the MPLS-TE tunnel
model, defined in [I-D.ietf-teas-yang-te-mpls].
MPLS Transport Profile (MPLS-TP) is a profile of the MPLS protocol
that is used in packet switched transport networks and operated in a
similar manner to other existing transport technologies (e.g., OTN),
as described in [RFC5921].
The YANG models defined in this document can also be used for MPLS-TP
network topologies.
The YANG models defined in this document conform to the Network
Management Datastore Architecture defined in [RFC8342].
1.1. Tree Diagram
A simplified graphical representation of the data model is used in
Section 5.1 of this this document. The meaning of the symbols in
these diagrams is defined in [RFC8340].
1.2. Prefixes in Data Node Names
In this document, names of data nodes and other data model objects
are prefixed using the standard prefix associated with the
corresponding YANG imported modules, as shown in Table 1.
Busi, et al. Expires 24 April 2024 [Page 3]
Internet-Draft MPLS-TE Topology YANG Model October 2023
+===============+=========================+===========+
| Prefix | YANG Module | Reference |
+===============+=========================+===========+
| rt-types | ietf-routing-types | [RFC8294] |
+---------------+-------------------------+-----------+
| mpls-te-types | ietf-mpls-te-types | RFC XXXX |
+---------------+-------------------------+-----------+
| nw | ietf-network | [RFC8345] |
+---------------+-------------------------+-----------+
| nt | ietf-network-topology | [RFC8345] |
+---------------+-------------------------+-----------+
| tet | ietf-te-topology | [RFC8795] |
+---------------+-------------------------+-----------+
| tet-pkt | ietf-te-topology-packet | [RFCYYYY] |
+---------------+-------------------------+-----------+
| tet-mpls | ietf-te-mpls-topology | RFC XXXX |
+---------------+-------------------------+-----------+
Table 1: Prefixes and corresponding YANG modules
RFC Editor Note: Please replace XXXX with the RFC number assigned to
the RFC once this draft becomes an RFC. Please replace YYYY with the
RFC numbers assigned to [I-D.ietf-teas-yang-l3-te-topo]. Please
remove this note.
2. MPLS-TE Types Overview
The module ietf-mpls-te-types contains the following YANG types and
groupings which can be used by other MPLS-TE YANG models:
load-balancing-type:
This identity defines the types of load-balancing algorithms used
on a bundled MPLS-TE link.
te-mpls-label-hop:
This grouping is used for augmentation of the TE label for MPLS-TE
paths.
3. MPLS-TE Topology Model Overview
The MPLS-TE technology-specific topology model augments the ietf-te-
topology-packet YANG module, defined in
[I-D.ietf-teas-yang-l3-te-topo], which in turn augments the generic
ietf-te-topology YANG module, defined in [RFC8795], as shown in
Figure 1.
Busi, et al. Expires 24 April 2024 [Page 4]
Internet-Draft MPLS-TE Topology YANG Model October 2023
+------------------+
TE generic | ietf-te-topology |
+---------+--------+
^
|
| Augments
|
+------------+------------+
Packet TE | ietf-te-topology-packet |
+------------+------------+
^
|
| Augments
|
+-----------+-----------+
MPLS-TE | ietf-te-mpls-topology |
+-----------------------+
Figure 1: Relationship between MPLS-TE, Packet-TE and TE Topology
Models
Given the guidance for augmentation in [RFC8795], the following
technology-specific augmentations need are provided:
* A network-type to indicate that the TE topology is an MPLS-TE
topology, as follow:
augment /nw:networks/nw:network/nw:network-types
/tet:te-topology/tet-pkt:packet:
+--rw mpls-topology!
* TE Label augmentations as described in Section 3.1.
Note: TE bandwidth augmentations for paths, LSPs, and links are
provided by the ietf-te-topology-packet module, defined in
[I-D.ietf-teas-yang-l3-te-topo].
3.1. TE Label Augmentations
In MPLS-TE, label allocation is done by the network element.
Information about the availability of label values does not need to
be provided to the controller. Moreover, MPLS-TE tunnels are
currently mainly only established within a single domain.
Therefore this document does not define any MPLS-TE technology-
specific augmentations, of the TE Topology model specific to the TE
label because no TE label-related attributes are instantiated for
MPLS-TE Topologies.
Busi, et al. Expires 24 April 2024 [Page 5]
Internet-Draft MPLS-TE Topology YANG Model October 2023
Furthermore, because the primary use cases are for single domain
MPLS-TE tunnels, this document does not define objects that
facilitate the setup of multi-domain MPLS-TE tunnels. It is an item
for future study to understand how a management system would
coordinate YANG configuration of a tunnel that crosses a domain
boundary, and it is expected that that would be defined in a separate
document.
3.2. MPLS-TP Topology
Multiprotocol Label Switching - Transport Profile (MPLS-TP) is a
profile of the MPLS protocol that is used in packet switched
transport networks and operated in a similar manner to other existing
transport technologies (e.g., OTN), as described in [RFC5921].
Therefore, the YANG models defined in this document can also be
applied to MPLS-TP network topologies.
However, as described in [RFC5921], MPLS-TP networks support
bidirectional LSPs and require no equal cost multipath (ECMP) and no
previous hop popping (PHP). When reporting the topology for an MPLS-
TP network, additional information is required to indicate whether
the network components (links and nodes) support these MPLS-TP
characteristics.
It is worth noting that [RFC8795] is already capable of modeling TE
topologies supporting either unidirectional or bidirectional LSPs:
all bidirectional TE links can support bidirectional LSPs, and all
links can support unidirectional LSPs. Further, it is always
possible to associate two unidirectional LSPs to compose a
bidirecitonal service as long as they belong to the same tunnel.
When setting up bidirectional LSPs (e.g., MPLS-TP LSPs) only
bidirectional TE Links are selected by path computation.
In order to allow reporting that ECMP is not affecting forwarding the
packets of a given LSP, the model defined in this documents provides
the load-balancing-type attribute which reports whether a link
aggregation group (LAG) or TE Bundled Link performs load-balancing,
and if so, whether it is on a per-flow or per-top-label basis:
augment /nw:networks/nw:network/nt:link/tet:te:
+--rw load-balancing-type? mte-types:load-balancing-type
When setting up LSPs which require the non-use of ECMP (e.g., MPLS-TP
LSPs) only links that are not part of a LAG or TE Bundle, or that
perform per-top-label load balancing are selected by path
computation.
Busi, et al. Expires 24 April 2024 [Page 6]
Internet-Draft MPLS-TE Topology YANG Model October 2023
It is assumed that almost all the MPLS-TE nodes are capable of
supporting Ultimate Hop Popping (UHP) (i.e., they do not require the
previous node on the path to perform PHP). However, if some
interfaces are not able to support UHP, they can report it in the
MPLS-TE topology:
augment /nw:networks/nw:network/nw:node/nt:termination-point
/tet:te:
+--ro uhp-incapable? empty
When setting up LSPs which require the non-use of PHP (e.g., MPLS-TP
LSPs) only the destination node interfaces (link termination points -
LTPs) that are capable of supporting UHP are selected by path
computation.
4. YANG model for common MPLS-TE Types
<CODE BEGINS> file "ietf-mpls-te-types@2023-10-13.yang"
module ietf-mpls-te-types {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-mpls-te-types";
prefix mpls-te-types;
import ietf-routing-types {
prefix rt-types;
reference
"RFC 8294: Common YANG Data Types for the Routing Area";
}
organization
"Internet Engineering Task Force (IETF) TEAS WG";
contact
"WG Web: <https://datatracker.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org>
Editor: Italo Busi
<mailto:italo.busi@huawei.com>
Editor: Aihua Guo
<mailto:aihuaguo.ietf@gmail.com>
Editor: Xufeng Liu
<mailto:xufeng.liu.ietf@gmail.com>
Editor: Tarek Saad
<mailto:tsaad.net@gmail.com>
Editor: Rakesh Gandhi
Busi, et al. Expires 24 April 2024 [Page 7]
Internet-Draft MPLS-TE Topology YANG Model October 2023
<mailto:rgandhi@cisco.com>";
description
"This module defines a collection of common YANG data type
and grouping definitions specific to MPLS-TE.
Copyright (c) 2023 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 Revised 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 XXXX; see
the RFC itself for full legal notices.";
revision 2023-10-13 {
description
"Initial Version";
reference
"RFC XXXX: A YANG Data Model for MPLS-TE Topology";
}
// RFC Editor: replace XXXX with the actual RFC number assigned
// to the RFC once this draft
// becomes an RFC, update date information and remove this note.
/*
* Typedefs
*/
typedef load-balancing-type {
type enumeration {
enum per-flow {
description
"The load-balancing algorithm ensures that packets
characterized as the same flow (e.g. based on IP 5-tuple)
that egress on a LAG or a bundled TE link are forwarded
on the same component link.
Packets for different flows within the same LSP can be
forwarded on different component links.";
}
enum per-top-label {
description
"The load-balancing algorithm ensures incoming MPLS
Busi, et al. Expires 24 April 2024 [Page 8]
Internet-Draft MPLS-TE Topology YANG Model October 2023
packets with the same top MPLS label and that egress on
on a LAG or bundled TE link are forwarded on the same
component link.
Packets for different flows within the same LSP are
forwarded on the same component link.";
}
}
description
"The type of load balancing used on bundled links.";
} // typedef load-balancing-type
/*
* Groupings
*/
grouping te-mpls-label-hop {
description
"MPLS-TE Label Hop.";
leaf mpls-label {
type rt-types:mpls-label;
description
"MPLS Label.";
}
} // grouping te-mpls-label-hop
}
<CODE ENDS>
Figure 2: MPLS-TE Types YANG model
5. YANG Model for MPLS-TE Topology
5.1. YANG Tree
Figure 3 shows the tree diagram of the YANG model defined in module
ietf-te-mpls-topology.yang.
module: ietf-te-mpls-topology
augment /nw:networks/nw:network/nw:network-types/tet:te-topology
/tet-pkt:packet:
+--rw mpls-topology!
augment /nw:networks/nw:network/nt:link/tet:te:
+--rw load-balancing-type? mpls-te-types:load-balancing-type
augment /nw:networks/nw:network/nw:node/nt:termination-point
/tet:te:
+--ro uhp-incapable? empty
Busi, et al. Expires 24 April 2024 [Page 9]
Internet-Draft MPLS-TE Topology YANG Model October 2023
Figure 3: MPLS-TE topology YANG tree
5.2. YANG Code
<CODE BEGINS> file "ietf-te-mpls-topology@2023-10-13.yang"
module ietf-te-mpls-topology {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-te-mpls-topology";
prefix tet-mpls;
import ietf-network {
prefix nw;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-network-topology {
prefix nt;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-te-topology {
prefix tet;
reference
"RFC 8795: YANG Data Model for Traffic Engineering
(TE) Topologies";
}
import ietf-te-topology-packet {
prefix tet-pkt;
reference
"RFC YYYY: YANG Data Model for Layer 3 TE Topologies";
}
// RFC Editor: replace YYYY with the actual RFC number assigned
// to the RFC once draft-ietf-teas-yang-l3-te-topo
// becomes an RFC and remove this note.
import ietf-mpls-te-types {
prefix mpls-te-types;
reference
"RFC XXXX: A YANG Data Model for MPLS-TE Topology";
}
// RFC Editor: replace XXXX with the actual RFC number assigned
// to the RFC once this draft
// becomes an RFC and remove this note.
organization
Busi, et al. Expires 24 April 2024 [Page 10]
Internet-Draft MPLS-TE Topology YANG Model October 2023
"Internet Engineering Task Force (IETF) TEAS WG";
contact
"WG Web: <https://datatracker.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org>
Editor: Italo Busi
<mailto:italo.busi@huawei.com>
Editor: Aihua Guo
<mailto:aihuaguo.ietf@gmail.com>
Editor: Xufeng Liu
<mailto:xufeng.liu.ietf@gmail.com>
Editor: Tarek Saad
<mailto:tsaad.net@gmail.com>
Editor: Rakesh Gandhi
<mailto:rgandhi@cisco.com>";
description
"This module defines a YANG data model for representing,
retrieving, and manipulating MPLS-TE network topologies.
This module defines MPLS-TE technology-specific augmentations
to the generic Packet TE topology module
(ietf-te-topology-packet).
Copyright (c) 2022 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 Revised
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 XXXX; see
the RFC itself for full legal notices.";
revision 2023-10-13 {
description
"Initial Version";
reference
"RFC XXXX: A YANG Data Model for MPLS-TE Topology";
}
// RFC Editor: replace XXXX with the actual RFC number assigned
Busi, et al. Expires 24 April 2024 [Page 11]
Internet-Draft MPLS-TE Topology YANG Model October 2023
// to the RFC once this draft
// becomes an RFC, update date information and remove this note.
/*
* Augmentations
*/
augment "/nw:networks/nw:network/nw:network-types/"
+ "tet:te-topology/tet-pkt:packet" {
description
"Augment network types to include MPLS-TE Topology Type";
container mpls-topology {
presence
"Indicates an MPLS-TE Topology Type.";
description
"Its presence indicates an MPLS-TE Topology";
}
}
augment "/nw:networks/nw:network/nt:link/tet:te" {
when "../../nw:network-types/tet:te-topology/"
+ "tet-pkt:packet/tet-mpls:mpls-topology" {
description
"Augment MPLS-TE Topology.";
}
description
"Augment TE Link.";
leaf load-balancing-type {
type mpls-te-types:load-balancing-type;
default 'per-flow';
description
"Indicates the type of load-balancing (per-flow or per-LSP)
performed by the bundled TE Link.
This leaf is not present when the TE Link is not bundled.";
} // leaf load-balancing-type
}
augment "/nw:networks/nw:network/nw:node/nt:termination-point/"
+ "tet:te" {
when "../../../nw:network-types/tet:te-topology/"
+ "tet-pkt:packet/tet-mpls:mpls-topology" {
description "Augment MPLS-TE Topology.";
}
description "Augment LTP.";
leaf uhp-incapable {
Busi, et al. Expires 24 April 2024 [Page 12]
Internet-Draft MPLS-TE Topology YANG Model October 2023
type empty;
config false;
description
"When present, indicates that the LTP is not capable to
support Ultimate Hop Popping (UHP).";
} // leaf uhp-incapable
}
}
<CODE ENDS>
Figure 4: MPLS-TE topology YANG module
6. Security Considerations
The configuration, state, and action data defined in this document
are designed to be accessed via a management protocol with a secure
transport layer, 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 [RFC8446].
The NETCONF access control model [RFC8341] provides the means to
restrict access for particular NETCONF users to a preconfigured
subset of all available NETCONF protocol operations and content.
The ietf-mpls-te-types model presented in this document defines
common types intended to be used as imports by other YANG models.
Those other models are responsible for considering the security of
the objects they define using those imports. Writers of those other
models should consider the vulnerabilities created by exposing
information about link characteristics and behaviors (such as how
packets may be steered onto parallel links), and should be aware of
the risks of enabling configuration of which labels are used on hops
within an LSP.
The ietf-te-mpls-topology model presented in this document defines
technology-specific objects to describe an MPLS-TE topology. It is
intended as an aumentation of the te-topology model [RFC8795] and so
the core security considerations for that model also apply. In
addition, this model defines objects that could expose information
about the network behavior or which, if modified by an attacker could
disrupt the delivery of services in the network.
The leaf objects defined in ietf-te-mpls-topology are read-only so
the risk is from unauthorized access to the information, or from
misrepresenting the information reported from the network elements.
The objects are:
Busi, et al. Expires 24 April 2024 [Page 13]
Internet-Draft MPLS-TE Topology YANG Model October 2023
"tet:te-topology/tet-pkt:packet": Unauthorized read access to this
simply indicates that the network topology is MPLS-TE packet-capable:
that information is not very valuable to an attacker. Modification
of this information might cause a path computation element to
incorrectly presume that a network is capable or incapable of
supporting MPLS-TE services.
"tet-pkt:packet/tet-mpls:mpls-topology/load-balancing-type":
Unauthorized read access to this indicates the mechanism used by a
nework node to share traffic across members of a LAG or bundled MPLS-
TE link. Such knowledge might help an attacker predict which
component link is carrying specific traffic making a physical attack
slightly easier. Modification of this information might cause a path
computation element to incorrectly presume that a link is suitable or
unsuitable for use to provide an MPLS-TP service.
"tet-pkt:packet/tet-mpls:mpls-topology/uhp-incapable": Unauthorized
read access to this will give an attacker knowledge about whether PHP
is being applied on the final hop of all LSPs to a particular node on
the associated link: that information is of little use to an attacker
except it may help them to parse an inflight packet. Modification of
this information would cause a path computation element to
incorrectly consider the associated link as suitable or unsuitable
for inclusion in the path of an MPLS-TP service.
7. IANA Considerations
This document requests IANA to register the following URIs in the
"ns" subregistry within the "IETF XML Registry" [RFC3688]. Following
the format in [RFC3688], the following registrations are requested.
URI: urn:ietf:params:xml:ns:yang:ietf-mpls-te-types
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-te-mpls-topology
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG modules in
the "IANA Module Names" [RFC6020]. Following the format in
[RFC6020], the following registrations are requested:
Busi, et al. Expires 24 April 2024 [Page 14]
Internet-Draft MPLS-TE Topology YANG Model October 2023
name: ietf-mpls-te-types
namespace: urn:ietf:params:xml:ns:yang:ietf-mpls-te-types
prefix: mpls-te-types
reference: RFC XXXX
name: ietf-te-mpls-topology
namespace: urn:ietf:params:xml:ns:yang:ietf-te-mpls-topology
prefix: tet-mpls
reference: RFC XXXX
RFC Editor: Please replace XXXX with the RFC number assigned to this
document.
8. References
8.1. Normative References
[I-D.ietf-teas-yang-l3-te-topo]
Liu, X., Bryskin, I., Beeram, V. P., Saad, T., Shah, H.
C., and O. G. de Dios, "YANG Data Model for Layer 3 TE
Topologies", Work in Progress, Internet-Draft, draft-ietf-
teas-yang-l3-te-topo-15, 21 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
yang-l3-te-topo-15>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[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>.
[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>.
Busi, et al. Expires 24 April 2024 [Page 15]
Internet-Draft MPLS-TE Topology YANG Model October 2023
[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
"Common YANG Data Types for the Routing Area", RFC 8294,
DOI 10.17487/RFC8294, December 2017,
<https://www.rfc-editor.org/info/rfc8294>.
[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>.
[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>.
[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/info/rfc8345>.
[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/info/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/info/rfc8795>.
8.2. Informative References
[I-D.ietf-teas-yang-te-mpls]
Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.
Bryskin, "A YANG Data Model for MPLS Traffic Engineering
Tunnels", Work in Progress, Internet-Draft, draft-ietf-
teas-yang-te-mpls-04, 26 May 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
yang-te-mpls-04>.
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
<https://www.rfc-editor.org/info/rfc5921>.
Busi, et al. Expires 24 April 2024 [Page 16]
Internet-Draft MPLS-TE Topology YANG Model October 2023
Acknowledgments
We thank Loa Andersson 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
Haomian Zheng
Huawei Technologies
Email: zhenghaomian@huawei.com
Vishnu Pavan Beeram
Juniper Networks
Email: vbeeram@juniper.net
Igor Bryskin
Individual
Email: i_bryskin@yahoo.com
Adrian Farrel
Old Dog Consulting
Email: adrian@olddog.co.uk
Authors' Addresses
Italo Busi
Huawei Technologies
Email: italo.busi@huawei.com
Aihua Guo
Futurewei Inc.
Email: aihuaguo.ietf@gmail.com
Xufeng Liu
Alef Edge
Email: xufeng.liu.ietf@gmail.com
Busi, et al. Expires 24 April 2024 [Page 17]
Internet-Draft MPLS-TE Topology YANG Model October 2023
Tarek Saad
Cisco Systems, Inc.
Email: tsaad.net@gmail.com
Rakesh Gandhi
Cisco Systems, Inc.
Email: rgandhi@cisco.com
Busi, et al. Expires 24 April 2024 [Page 18]
