Profiles for Traffic Engineering (TE) Topology Data Model
draft-busi-teas-te-topology-profiles-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Italo Busi , Xufeng Liu , Igor Bryskin , Vishnu Pavan Beeram , Tarek Saad , Oscar Gonzalez de Dios | ||
| Last updated | 2021-01-11 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-busi-teas-te-topology-profiles-00
TEAS Working Group Italo Busi
Internet Draft Huawei
Intended status: Informational Xufeng Liu
Volta Networks
Igor Bryskin
Individual
Vishnu Pavan Beeram
Tarek Saad
Juniper Networks
Oscar Gonzalez de Dios
Telefonica
Expires: July 2021 January 11, 2021
Profiles for Traffic Engineering (TE) Topology Data Model
draft-busi-teas-te-topology-profiles-00
Abstract
This document describes how profiles of the Traffic Engineering (TE)
Topology Model, defined in RFC8795, can be used to address
applications beyond "Traffic Engineering".
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Busi, et al. Expires July 11, 2021 [Page 1]
Internet-Draft TE Topology Profiles January 2021
This Internet-Draft will expire on July 11, 2021.
Copyright Notice
Copyright (c) 2021 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
(http://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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction...................................................2
2. Examples of non-TE scenarios...................................3
2.1. UNI Topology Discovery....................................3
2.2. Administrative and Operational status management..........5
2.3. Geolocation...............................................7
2.4. Overlay and Underlay non-TE Topologies....................8
2.5. Nodes with switching limitations.........................10
3. Technology-specific augmentations.............................11
4. Security Considerations.......................................13
5. IANA Considerations...........................................13
6. References....................................................14
6.1. Normative References.....................................14
6.2. Informative References...................................14
Acknowledgments..................................................14
Contributors.....................................................14
Authors' Addresses...............................................15
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 [RFC3272bis] as aspects of
Internet network engineering that deal with the issues of performance
evaluation and performance optimization of operational IP networks.
Busi, et al. Expires July 11, 2021 [Page 2]
Internet-Draft TE Topology Profiles January 2021
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
2.1. UNI Topology Discovery
UNI Topology Discovery is independent from whether the network is TE
or non-TE.
The TE Topology Model supports inter-domain link discovery (including
but not being limited to UNI link discovery) using the plug-id
attribute. This solution is quite generic and does not require the
network to be a TE network.
The following profile of the TE Topology model can be used for the
UNI Topology Discovery:
Busi, et al. Expires July 11, 2021 [Page 3]
Internet-Draft TE Topology Profiles January 2021
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
Figure 1 - UNI Topology
The profile data model shown in Figure 1 can be used to discover TE
and non TE UNIs as well as to discover UNIs for TE or non TE
networks.
Such a UNI TE Topology profile model can also be used with
technology-specific UNI augmentations, as described in section 3.
For example, in [CLIENT-TOPO], the eth-svc container is defined to
represent the capabilities of the Termination Point (TP) to be
configured as an Ethernet client UNI, together with the Ethernet
classification and VLAN operations supported by that TP.
The [OTN-TOPO] provides another example, where:
o the client-svc container is defined to represent the capabilities
of the TP to be configured as an transparent client UNI (e.g.,
STM-N, Fiber Channel or transparent Ethernet);
o the OTN technology-specific Link Termination Point (LTP)
augmentations are defined to represent the capabilities of the TP
to be configured as an OTN UNI, together with the information
about OTN label and bandwidth availability at the OTN UNI.
For example, the UNI TE Topology profile can be used to model
features defined in [UNI-TOPO]:
o The inter-domain-plug-id attribute would provide the same
information as the attachment-id attribute defined in [UNI-TOPO];
Busi, et al. Expires July 11, 2021 [Page 4]
Internet-Draft TE Topology Profiles January 2021
o The admin-status and oper-status that exists in this TE topology
profile can provide the same information as the admin-status and
oper-status attributes defined in [UNI-TOPO].
Following the same approach in [CLIENT-TOPO] and [OTN-TOPO], the type
and encapsulation-type attributes can be defined by technology-
specific UNI augmentations to represent the capability of a TP to be
configured as a L2VPN/L3VPN UNI Service Attachment Point (SAP).
The advantages of using a TE Topology customized profile would be
having common solutions for:
o discovering UNIs as well as inter-domain NNI links, which is
applicable to any technology (TE or non TE) used at the UNI or
within the network;
o modelling non TE UNIs such as Ethernet, and TE UNIs such as OTN,
as well as UNIs which can configured as TE or non-TE (e.g., being
configured as either Ethernet or OTN UNI).
2.2. Administrative and Operational status management
The TE Topology Model supports the management of administrative and
operational state, including also the possibility to associate some
administrative names, for nodes, termination points and links. This
solution is generic and also does not require the network to be a TE
network.
The following profile of the TE Topology Model can be used for
administrative and operational state management:
Busi, et al. Expires July 11, 2021 [Page 5]
Internet-Draft TE Topology Profiles January 2021
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
Figure 2 - Generic Topology with admin and operational state
The TE topology data model profile shown in Figure 2 is applicable to
any technology (TE or non-TE) that requires management of the
administrative and operational state and administrative names for
nodes, termination points and links.
Busi, et al. Expires July 11, 2021 [Page 6]
Internet-Draft TE Topology Profiles January 2021
2.3. Geolocation
The TE Topology model supports the management of geolocation
coordinates for nodes and termination points. This solution is
generic and does not necessarily require the network to be a TE
network.
The TE topology data model profile shown in Figure 3can be used to
model geolocation data for networks.
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!
+--ro geolocation
+--ro altitude? int64
+--ro latitude? geographic-coordinate-degree
+--ro longitude? geographic-coordinate-degree
augment /nw:networks/nw:network/nw:node:
+--rw te-node-id? te-types:te-node-id
+--rw te!
+--ro geolocation
| +--ro altitude? int64
| +--ro latitude? geographic-coordinate-degree
| +--ro longitude? geographic-coordinate-degree
augment /nw:networks/nw:network/nw:node/nt:termination-point:
+--rw te-tp-id? te-types:te-tp-id
+--rw te!
+--ro geolocation
+--ro altitude? int64
+--ro latitude? geographic-coordinate-degree
+--ro longitude? geographic-coordinate-degree
Figure 3 - Generic Topology with geolocation information
Busi, et al. Expires July 11, 2021 [Page 7]
Internet-Draft TE Topology Profiles January 2021
This profile is applicable to any network technology (TE or non-TE)
that requires management of the geolocation information for its nodes
and termination points.
2.4. Overlay and Underlay non-TE Topologies
The TE Topology model supports the management of overlay/underlay
relationship for nodes and links, as described in section 5.8 of
[RFC8795]. This solution is generic and does not require the network
to be a TE network.
The following TE topology data model profile can be used to manage
overlay/underlay network data:
Busi, et al. Expires July 11, 2021 [Page 8]
Internet-Draft TE Topology Profiles January 2021
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 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
Figure 4 - Generic Topology with overlay/underlay information
This profile is applicable to any technology (TE or non-TE) when it
is needed to manage the overlay/underlay information. It is also
allows a TE underlay network to support a non-TE overlay network and,
vice versa, a non-TE underlay network to support a TE overlay
network.
Busi, et al. Expires July 11, 2021 [Page 9]
Internet-Draft TE Topology Profiles January 2021
2.5. Nodes with switching limitations
A node can have some switching limitations where connectivity is not
possible between all its TP pairs, for example when:
o the node represents a physical device with switching limitations;
o the node represents an abstraction of a network topology.
This scenario is generic and applies to both TE and non-TE
technologies.
A connectivity TE Topology profile data model supports the management
of the node connectivity matrix to represent feasible connections
between termination points across the nodes. This solution is generic
and does not necessarily require a TE enabled network.
The following profile of the TE Topology model can be used for nodes
with connectivity constraints:
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
Figure 5 - Generic Topology with connectivity constraints
The TE topology data model profile shown in Figure 5 is applicable to
any technology (TE or non-TE) networks that requires managing nodes
with certain connectivity constraints. When used with TE
Busi, et al. Expires July 11, 2021 [Page 10]
Internet-Draft TE Topology Profiles January 2021
technologies, additional TE attributes, as defined in [RFC8795], can
also be provided.
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 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 6:
+-------------------+
| Network Topology |
+-------------------+
^
|
| Augments
|
+-----------+-----------+
| TE Topology |
+-----------------------+
^
|
| Augments
|
+----------+----------+
| Technology-Specific |
| TE Topology |
+---------------------+
Figure 6 Augmenting the TE Topology Model
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.
This is the approach currently used in [CLIENT TOPO] and [OTN TOPO].
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.
Busi, et al. Expires July 11, 2021 [Page 11]
Internet-Draft TE Topology Profiles January 2021
The second option is to define a technology-specific Topology Model
which augments the Network Topology Model and to rely on the multiple
inheritance capability that is defined in [RFC8345] to allow using
also the attributes defined in the TE Topology model:
+-----------------------+
| Network Topology |
+-----------------------+
^ ^
| |
Augments +---+ +--+ Augments
| |
+---------+---+ +----------+----------+
| TE Topology | | Technology-specific |
| | | Topology |
+-------------+ +---------------------+
Figure 7 Augmenting the Network Topology Model with multi-inheritance
This approach is more suitable in cases where the technology-specific
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, a third option, to define both a technology specific TE
Topology Model which augments the TE Topology Model, and a
technology-specific Topology Model which augments the Network
Topology Model and to rely on the multiple inheritance capability, as
shown in Figure 8, is possible:
Busi, et al. Expires July 11, 2021 [Page 12]
Internet-Draft TE Topology Profiles January 2021
+-----------------------+
| Network Topology |
+-----------------------+
^ ^
| |
Augments +---+ +--+ Augments
| |
+---------+---+ +----------+----------+
| TE Topology | | Technology-specific |
| | | Topology |
+-------------+ +---------------------+
^
|
| Augments
|
+----------+----------+
| Technology-Specific |
| TE Topology |
+---------------------+
Figure 8 Augmenting both the Network and TE Topology Models
This option does not provide any technical advantage with respect to
the first option, shown in Figure 6, but could be useful to add
augmentations to the TE Topology constructs and re-using an already
existing technology-specific Topology Model.
4. 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].
5. IANA Considerations
This document requires no IANA actions.
Busi, et al. Expires July 11, 2021 [Page 13]
Internet-Draft TE Topology Profiles January 2021
6. References
6.1. Normative References
[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>.
[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>.
6.2. Informative References
[RFC3272bis] Farrel A., "Overview and Principles of Internet
Traffic Engineering", draft-dt-teas-rfc3272bis-00, work in
progress.
[UNI-TOPO] Gonzalez de Dios, O. et al., "A YANG Model for User-
Network Interface (UNI) Topologies", draft-ogondio-opsawg-
uni-topology-01, work in progress.
[CLIENT-TOPO] Zheng, H. et al., "A YANG Data Model for Client-layer
Topology", draft-zheng-ccamp-client-topo-yang-09, work in
progress.
[OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical
Transport Network Topology", draft-ietf-ccamp-otn-topo-
yang-11, work in progress.
Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Contributors
Aihua Guo
Futurewei Inc.
Email: aihuaguo.ietf@gmail.com
Busi, et al. Expires July 11, 2021 [Page 14]
Internet-Draft TE Topology Profiles January 2021
Haomian Zheng
Huawei
Email: zhenghaomian@huawei.com
Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com
Authors' Addresses
Italo Busi
Huawei
Email: italo.busi@huawei.com
Xufeng Liu
Volta Networks
Email: xufeng.liu.ietf@gmail.com
Igor Bryskin
Individual
Email: i_bryskin@yahoo.com
Vishnu Pavan Beeram
Juniper Networks
Email: vbeeram@juniper.net
Tarek Saad
Juniper Networks
Email: tsaad@juniper.net
Busi, et al. Expires July 11, 2021 [Page 15]
Internet-Draft TE Topology Profiles January 2021
Oscar Gonzalez de Dios
Telefonica
Email: oscar.gonzalezdedios@telefonica.com
Busi, et al. Expires July 11, 2021 [Page 16]