draft-ietf-ccamp-gmpls-general-constraints-ospf-te-10.txt   rfc7580.txt 
Network work group Fatai Zhang
Internet Draft Young Lee
Intended status: Standards Track Jianrui Han
Huawei
G. Bernstein
Grotto Networking
Yunbin Xu
CATR
Expires: September 5, 2015 March 6, 2015 Internet Engineering Task Force (IETF) F. Zhang
Request for Comments: 7580 Y. Lee
OSPF-TE Extensions for General Network Element Constraints Category: Standards Track J. Han
ISSN: 2070-1721 Huawei
G. Bernstein
Grotto Networking
Y. Xu
CATR
June 2015
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-10.txt OSPF-TE Extensions for General Network Element Constraints
Abstract Abstract
Generalized Multiprotocol Label Switching (GMPLS) can be used to Generalized Multiprotocol Label Switching (GMPLS) can be used to
control a wide variety of technologies including packet switching control a wide variety of technologies including packet switching
(e.g., MPLS), time-division (e.g., SONET/SDH, Optical Transport (e.g., MPLS), time division (e.g., Synchronous Optical Network /
Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport
Network (OTN)), wavelength (lambdas), and spatial switching (e.g., Network (OTN)), wavelength (lambdas), and spatial switching (e.g.,
incoming port or fiber to outgoing port or fiber). In some of these incoming port or fiber to outgoing port or fiber). In some of these
technologies, network elements and links may impose additional technologies, network elements and links may impose additional
routing constraints such as asymmetric switch connectivity, non- routing constraints such as asymmetric switch connectivity, non-
local label assignment, and label range limitations on links. This local label assignment, and label range limitations on links. This
document describes Open Shortest Path First (OSPF) routing protocol document describes Open Shortest Path First (OSPF) routing protocol
extensions to support these kinds of constraints under the control extensions to support these kinds of constraints under the control of
of GMPLS. GMPLS.
Status of this Memo
This Internet-Draft is submitted to IETF 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 Status of This Memo
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 This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on September 5, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7580.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction ....................................................3
2. Node Information...............................................4 1.1. Conventions Used in This Document ..........................3
2.1. Connectivity Matrix.......................................4 2. Node Information ................................................3
3. Link Information...............................................4 2.1. Connectivity Matrix ........................................4
3.1. Port Label Restrictions...................................5 3. Link Information ................................................4
4. Routing Procedures.............................................5 3.1. Port Label Restrictions ....................................5
5. Scalability and Timeliness.....................................6 4. Routing Procedures ..............................................5
5.1. Different Sub-TLVs into Multiple LSAs.....................6 5. Scalability and Timeliness ......................................6
5.2. Decomposing a Connectivity Matrix into Multiple Matrices..7 5.1. Different Sub-TLVs into Multiple LSAs ......................6
6. Security Considerations........................................7 5.2. Decomposing a Connectivity Matrix into Multiple Matrices ...6
7. Manageability..................................................8 6. Security Considerations .........................................7
8. IANA Considerations............................................8 7. Manageability ...................................................7
8.1. Node Information..........................................8 8. IANA Considerations .............................................8
8.2. Link Information..........................................9 8.1. Node Information ...........................................8
9. References.....................................................9 8.2. Link Information ...........................................8
9.1. Normative References......................................9 9. References ......................................................9
9.2. Informative References...................................10 9.1. Normative References .......................................9
10. Authors' Addresses ..........................................10 9.2. Informative References ....................................10
Acknowledgment...................................................12 Acknowledgments ...................................................11
Contributors ......................................................11
Authors' Addresses ................................................12
1. Introduction 1. Introduction
Some data plane technologies that require the use of a GMPLS control Some data-plane technologies that require the use of a GMPLS control
plane impose additional constraints on switching capability and plane impose additional constraints on switching capability and label
label assignment. In addition, some of these technologies should be assignment. In addition, some of these technologies should be
capable of performing non-local label assignment based on the nature capable of performing non-local label assignment based on the nature
of the technology, e.g., wavelength continuity constraint in of the technology, e.g., wavelength continuity constraint in
Wavelength Switched Optical Network (WSON) [RFC6163]. Such Wavelength Switched Optical Networks (WSONs) [RFC6163]. Such
constraints can lead to the requirement for link by link label constraints can lead to the requirement for link-by-link label
availability in path computation and label assignment. availability in path computation and label assignment.
[GEN-Encode] provides efficient encodings of information needed by [RFC7579] provides efficient encodings of information needed by the
the routing and label assignment process in technologies such as routing and label assignment process in technologies such as WSON.
WSON and are potentially applicable to a wider range of These encodings are potentially applicable to a wider range of
technologies. The encoding provided in [GEN-Encode] is protocol- technologies as well. The encoding provided in [RFC7579] is
neutral and can be used in routing, signaling and/or Path protocol-neutral and can be used in routing, signaling, and/or Path
Computation Element communication protocol extensions. Computation Element communication protocol extensions.
This document defines extensions to the OSPF routing protocol based This document defines extensions to the OSPF routing protocol based
on [GEN-Encode] to enhance the Traffic Engineering (TE) properties on [RFC7579] to enhance the Traffic Engineering (TE) properties of
of GMPLS TE which are defined in [RFC3630], [RFC4202], and [RFC4203]. GMPLS TE that are defined in [RFC3630], [RFC4202], and [RFC4203].
The enhancements to the TE properties of GMPLS TE links can be The enhancements to the TE properties of GMPLS TE links can be
advertised in OSPF TE LSAs. The TE LSA, which is an opaque LSA with advertised in OSPF-TE Link State Advertisements (LSAs). The TE LSA,
area flooding scope [RFC3630], has only one top-level which is an opaque LSA with area flooding scope [RFC3630], has only
Type/Length/Value (TLV) triplet and has one or more nested sub-TLVs one top-level Type-Length-Value (TLV) triplet and has one or more
for extensibility. The top-level TLV can take one of three values (1) nested sub-TLVs for extensibility. The top-level TLV can take one of
Router Address [RFC3630], (2) Link [RFC3630], (3) Node Attribute three values: Router Address [RFC3630], Link [RFC3630], or Node
[RFC5786]. In this document, we enhance the sub-TLVs for the Link Attribute [RFC5786]. In this document, we enhance the sub-TLVs for
TLV in support of the general network element constraints under the the Link TLV in support of the general network element constraints
control of GMPLS. under the control of GMPLS.
The detailed encoding of OSPF extensions are not defined in this The detailed encoding of OSPF extensions is not defined in this
document. [GEN-Encode] provides encoding details. document. [RFC7579] provides encoding details.
2. Node Information 1.1. Conventions Used in This Document
According to [GEN-Encode], the additional node information The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
representing node switching asymmetry constraints includes Node ID "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
and connectivity matrix. Except for the Node ID, which should comply document are to be interpreted as described in RFC 2119 [RFC2119].
with Routing Address described in [RFC3630], the other pieces of
information are defined in this document.
Per [GEN-Encode], this document defines the Connectivity Matrix Sub- 2. Node Information
TLV of the Node Attribute TLV defined in [RFC5786]. The new Sub-TLV
has Type TBD1 (to be assigned by IANA).
In some specific technologies, e.g., WSON networks, the Connectivity According to [RFC7579], the additional node information representing
Matrix sub-TLV may be optional, which depends on the control plane node switching asymmetry constraints includes device type and
implementations. Usually, for example, in WSON networks, connectivity matrix. Except for the device type, which is defined in
Connectivity Matrix sub-TLV may be advertised in the LSAs since WSON [RFC7579], the other pieces of information are defined in this
switches are currently asymmetric. If no Connectivity Matrix sub-TLV document.
is included, it is assumed that the switches support symmetric
switching.
2.1. Connectivity Matrix Per [RFC7579], this document defines the Connectivity Matrix sub-TLV
of the Node Attribute TLV defined in [RFC5786]. The new sub-TLV has
Type 14.
If the switching devices supporting certain data plane technology is Depending on the control-plane implementation being used, the
Connectivity Matrix sub-TLV may be optional in some specific
technologies, e.g., WSON networks. Usually, for example, in WSON
networks, the Connectivity Matrix sub-TLV may be advertised in the
LSAs since WSON switches are currently asymmetric. If no
Connectivity Matrix sub-TLV is included, it is assumed that the
switches support symmetric switching.
2.1. Connectivity Matrix
If the switching devices supporting certain data-plane technology are
asymmetric, it is necessary to identify which input ports and labels asymmetric, it is necessary to identify which input ports and labels
can be switched to some specific labels on a specific output port. can be switched to some specific labels on a specific output port.
The Connectivity Matrix is used to identify these restrictions, The connectivity matrix, which can represent either the potential
which can represent either the potential connectivity matrix for connectivity matrix for asymmetric switches (e.g., Reconfigurable
asymmetric switches (e.g., ROADMs and such) or fixed connectivity Optical Add/Drop Multiplexers (ROADMs) and such) or fixed
for an asymmetric device such as a multiplexer as defined in connectivity for an asymmetric device such as a multiplexer as
[RFC7446]. defined in [RFC7446], is used to identify these restrictions.
The Connectivity Matrix is a sub-TLV of the Node Attribute TLV. The The Connectivity Matrix is a sub-TLV of the Node Attribute TLV. The
length is the length of value field in octets. The meaning and length is the length of the value field in octets. The meaning and
format of this sub-TLV value field are defined in Section 2.1 of format of this sub-TLV value field are defined in Section 2.1 of
[GEN-Encode]. One sub-TLV contains one matrix. The Connectivity [RFC7579]. One sub-TLV contains one matrix. The Connectivity Matrix
Matrix sub-TLV may occur more than once to contain multiple matrices sub-TLV may occur more than once to contain multiple matrices within
within the Node Attribute TLV. In addition a large connectivity the Node Attribute TLV. In addition, a large connectivity matrix can
matrix can be decomposed into smaller sub-matrices for transmission be decomposed into smaller sub-matrices for transmission in multiple
in multiple LSAs as described in Section 5. LSAs as described in Section 5.
3. Link Information 3. Link Information
The most common link sub-TLVs nested in the top-level link TLV are The most common link sub-TLVs nested in the top-level Link TLV are
already defined in [RFC3630], [RFC4203]. For example, Link ID, already defined in [RFC3630] and [RFC4203]. For example, Link ID,
Administrative Group, Interface Switching Capability Descriptor Administrative Group, Interface Switching Capability Descriptor
(ISCD), Link Protection Type, Shared Risk Link Group Information (ISCD), Link Protection Type, Shared Risk Link Group (SRLG), and
(SRLG), and Traffic Engineering Metric are among the typical link Traffic Engineering Metric are among the typical link sub-TLVs.
sub-TLVs.
Per [GEN-Encode], this document defines the Port Label Restrictions Per [RFC7579], this document defines the Port Label Restrictions sub-
Sub-TLV of the Link TLV defined in [RFC3630]. The new Sub-TLV has TLV of the Link TLV defined in [RFC3630]. The new sub-TLV has Type
Type TBD2 (to be assigned by IANA). 34.
Generally all the sub-TLVs above are optional, which depends on the Generally, all the sub-TLVs above are optional, depending on control-
control plane implementations. The Port Label Restrictions sub-TLV plane implementations being used. The Port Label Restrictions sub-
will not be advertised when there are no restrictions on label TLV will not be advertised when there are no restrictions on label
assignment. assignment.
3.1. Port Label Restrictions 3.1. Port Label Restrictions
Port label restrictions describe the label restrictions that the Port label restrictions describe the label restrictions that the
network element (node) and link may impose on a port. These network element (node) and link may impose on a port. These
restrictions represent what labels may or may not be used on a link restrictions represent what labels may or may not be used on a link
and are intended to be relatively static. For increased modeling and are intended to be relatively static. For increased modeling
flexibility, port label restrictions may be specified relative to flexibility, port label restrictions may be specified relative to the
the port in general or to a specific connectivity matrix. port in general or to a specific connectivity matrix.
For example, the Port Label Restrictions describes the wavelength For example, the port label restrictions describe the wavelength
restrictions that the link and various optical devices such as OXCs, restrictions that the link and various optical devices such as
ROADMs, and waveband multiplexers may impose on a port in WSON. Optical Cross-Connects (OXCs), ROADMs, and waveband multiplexers may
These restrictions represent what wavelength may or may not be used impose on a port in WSON. These restrictions represent which
on a link and are relatively static. The detailed information about wavelengths may or may not be used on a link and are relatively
port label restrictions is described in [RFC7446]. static. Detailed information about port label restrictions is
provided in [RFC7446].
The Port Label Restrictions sub-TLV is a sub-TLV of the Link TLV. The Port Label Restrictions sub-TLV is a sub-TLV of the Link TLV.
The length is the length of value field in octets. The meaning and The length is the length of value field in octets. The meaning and
format of this sub-TLV value field are defined in Section 2.2 of format of this sub-TLV value field are defined in Section 2.2 of
[GEN-Encode]. The Port Label Restrictions sub-TLV may occur more [RFC7579]. The Port Label Restrictions sub-TLV may occur more than
than once to specify a complex port constraint within the link TLV. once to specify a complex port constraint within the Link TLV.
4. Routing Procedures 4. Routing Procedures
All the sub-TLVs are nested in top-level TLV(s) and contained in All sub-TLVs are nested in top-level TLV(s) and contained in Opaque
Opaque LSAs. The flooding rules of Opaque LSAs are specified in LSAs. The flooding rules of Opaque LSAs are specified in [RFC2328],
[RFC2328], [RFC5250], [RFC3630], and [RFC4203]. [RFC5250], [RFC3630], and [RFC4203].
Considering the routing scalability issues in some cases, the Considering the routing scalability issues in some cases, the routing
routing protocol should be capable of supporting the separation of protocol should be capable of supporting the separation of dynamic
dynamic information from relatively static information to avoid information from relatively static information to avoid unnecessary
unnecessary updates of static information when dynamic information updates of static information when dynamic information is changed. A
is changed. A standards-compliant approach is to separate the standards-compliant approach is to separate the dynamic information
dynamic information sub-TLVs from the static information sub-TLVs, sub-TLVs from the static information sub-TLVs, each nested in a
each nested in a separate top-level TLV ([RFC3630 and RFC5876]), and separate top-level TLV (see [RFC3630] and [RFC5786]), and advertise
advertise them in the separate OSPF TE LSAs. them in the separate OSPF-TE LSAs.
For node information, since the Connectivity Matrix information is For node information, since the connectivity matrix information is
static, the LSA containing the Node Attribute TLV can be updated static, the LSA containing the Node Attribute TLV can be updated with
with a lower frequency to avoid unnecessary updates. a lower frequency to avoid unnecessary updates.
For link information, a mechanism MAY be applied such that static For link information, a mechanism MAY be applied such that static
information and dynamic information of one TE link are contained in information and dynamic information of one TE link are contained in
separate Opaque LSAs. For example, the Port Label Restrictions separate Opaque LSAs. For example, the Port Label Restrictions sub-
information sub-TLV could be nested in separate top level link TLVs TLV could be nested in separate top-level Link TLVs and advertised in
and advertised in the separate LSAs. the separate LSAs.
As with other TE information, an implementation typically takes As with other TE information, an implementation typically takes
measures to avoid rapid and frequent updates of routing information measures to avoid rapid and frequent updates of routing information
that could cause the routing network to become swamped. See that could cause the routing network to become swamped. See
[RFC3630] Section 3 for related details. Section 3 of [RFC3630] for related details.
5. Scalability and Timeliness 5. Scalability and Timeliness
This document has defined two sub-TLVs for describing generic This document defines two sub-TLVs for describing generic routing
routing contraints. The examples given in [GEN-Encode] show that constraints. The examples given in [RFC7579] show that very large
very large systems, in terms of label count or ports, can be very systems, in terms of label count or ports, can be very efficiently
efficiently encoded. However there has been concern expressed that encoded. However, because there has been concern expressed that some
some possible systems may produce LSAs that exceed the IP Maximum possible systems may produce LSAs that exceed the IP Maximum
Transmission Unit (MTU) and that methods be given to allow for the Transmission Unit (MTU), methods should be given to allow for the
splitting of general constraint LSAs into smaller LSAs that are splitting of general constraint LSAs into smaller LSAs that are under
under the MTU limit. This section presents a set of techniques that the MTU limit. This section presents a set of techniques that can be
can be used for this purpose. used for this purpose.
5.1. Different Sub-TLVs into Multiple LSAs 5.1. Different Sub-TLVs into Multiple LSAs
Two sub-TLVs are defined in this document: Two sub-TLVs are defined in this document:
1. Connectivity Matrix (Node Attribute TLV) 1. Connectivity Matrix (carried in the Node Attribute TLV)
2. Port Label Restrictions (Link TLV)
The Connectivity Matrix can be carried in the Node Attribute TLV as 2. Port Label Restrictions (carried in the Link TLV)
defined in [RFC5786] while the Port Label Restrictions can be
carried in an Link TLV of which there can be at most one in an LSA
as defined in [RFC3630]. Note that the Port Label Restrictions are
relatively static, i.e., only would change with hardware changes or
significant system reconfiguration.
5.2. Decomposing a Connectivity Matrix into Multiple Matrices The Connectivity Matrix sub-TLV can be carried in the Node Attribute
TLV (as defined in [RFC5786]), whereas the Port Label Restrictions
sub-TLV can be carried in a Link TLV, of which there can be at most
one in an LSA (as defined in [RFC3630]). Note that the port label
restrictions are relatively static, i.e., only would change with
hardware changes or significant system reconfiguration.
5.2. Decomposing a Connectivity Matrix into Multiple Matrices
In the highly unlikely event that a Connectivity Matrix sub-TLV by In the highly unlikely event that a Connectivity Matrix sub-TLV by
itself would result in an LSA exceeding the MTU, a single large itself would result in an LSA exceeding the MTU, a single large
matrix can be decomposed into sub-matrices. Per [GEN-Encode] a matrix can be decomposed into sub-matrices. Per [RFC7579], a
connectivity matrix just consists of pairs of input and output ports connectivity matrix just consists of pairs of input and output ports
that can reach each other and hence such this decomposition would be that can reach each other; hence, this decomposition would be
straightforward. Each of these sub-matrices would get a unique straightforward. Each of these sub-matrices would get a unique
matrix identifier per [GEN-Encode]. matrix identifier per [RFC7579].
From the point of view of a path computation process, prior to From the point of view of a path computation process, prior to
receiving an LSA with a Connectivity Matrix sub-TLV, no connectivity receiving an LSA with a Connectivity Matrix sub-TLV, no connectivity
restrictions are assumed, i.e., the standard GMPLS assumption of any restrictions are assumed, i.e., the standard GMPLS assumption of any
port to any port reachability holds. Once a Connectivity Matrix sub- port to any port reachability holds. Once a Connectivity Matrix sub-
TLV is received then path computation would know that connectivity TLV is received, path computation would know that connectivity is
is restricted and use the information from all Connectivity Matrix restricted and use the information from all Connectivity Matrix sub-
sub-TLVs received to understand the complete connectivity potential TLVs received to understand the complete connectivity potential of
of the system. Prior to receiving any Connectivity Matrix sub-TLVs the system. Prior to receiving any Connectivity Matrix sub-TLVs,
path computation may compute a path through the system when in fact path computation may compute a path through the system when, in fact,
no path exists. In between the reception of an additional no path exists. In between the reception of an additional
Connectivity Matrix sub-TLV path computation may not be able to find Connectivity Matrix sub-TLV, path computation may not be able to find
a path through the system when one actually exists. Both cases are a path through the system when one actually exists. Both cases are
currently encountered and handled with existing GMPLS mechanisms. currently encountered and handled with existing GMPLS mechanisms.
Due to the reliability mechanisms in OSPF the phenomena of late or Due to the reliability mechanisms in OSPF, the phenomena of late or
missing Connectivity Matrix sub-TLVs would be relatively rare. missing Connectivity Matrix sub-TLVs would be relatively rare.
In case where the new sub-TLVs or their attendant encodings are In the case where the new sub-TLVs or their attendant encodings are
malformed, the proper action would be to log the problem and ignore malformed, the proper action would be to log the problem and ignore
just the sub-TLVs in GMPLS path computations rather than ignoring just the sub-TLVs in GMPLS path computations rather than ignoring the
the entire LSA. entire LSA.
6. Security Considerations 6. Security Considerations
This document does not introduce any further security issues other This document does not introduce any further security issues other
than those discussed in [RFC3630], [RFC4203], and [RFC5250]. than those discussed in [RFC3630], [RFC4203], and [RFC5250].
For general security aspects relevant to Generalized Multiprotocol For general security aspects relevant to GMPLS-controlled networks,
Label Switching (GMPLS)-controlled networks, please refer to please refer to [RFC5920].
[RFC5920].
7. Manageability 7. Manageability
No existing management tools handle the additional TE parameters as No existing management tools handle the additional TE parameters as
defined in this document and distributed in OSPF-TE. The existing defined in this document and distributed in OSPF-TE. The existing
MIB module contained in [RFC6825] allows the TE information MIB module contained in [RFC6825] allows the TE information
distributed by OSPF-TE to be read from a network node: this MIB distributed by OSPF-TE to be read from a network node; this MIB
module could be augmented (possibly by a sparse augmentation) to module could be augmented (possibly by a sparse augmentation) to
report this new information. report this new information.
The current environment in the IETF favors NETCONF [RFC6241] and The current environment in the IETF favors the Network Configuration
YANG [RFC6020] over SNMP and MIB modules. Work is in progress in Protocol (NETCONF) [RFC6241] and YANG [RFC6020] over SNMP and MIB
the TEAS working group to develop a YANG module to represent the modules. Work is in progress in the TEAS working group to develop a
generic TE information that may be present in a Traffic Engineering YANG module to represent the generic TE information that may be
Database (TED). This model may be extended to handle the additional present in a Traffic Engineering Database (TED). This model may be
information described in this document to allow that information to extended to handle the additional information described in this
be read from network devices or exchanged between consumers of the document to allow that information to be read from network devices or
TED. Furthermore, links state export using BGP [BGP-LS] enables the exchanged between consumers of the TED. Furthermore, links state
export of TE information from a network using BGP. Work could export using BGP [BGP-LS] enables the export of TE information from a
realistically be done to extend BGP-LS to also carry the information network using BGP. Work could realistically be done to extend BGP-LS
defined in this document. to also carry the information defined in this document.
It is not envisaged that the extensions defined in this document It is not envisaged that the extensions defined in this document will
will place substantial additional requirements on Operations, place substantial additional requirements on Operations,
Management, and Administration (OAM) mechanisms currently used to Administration, and Maintenance (OAM) mechanisms currently used to
diagnose and debug OSPF systems. However, tools that examine the diagnose and debug OSPF systems. However, tools that examine the
contents of opaque LSAs will need to be enhanced to handle these new contents of opaque LSAs will need to be enhanced to handle these new
sub-TLVs. sub-TLVs.
8. IANA Considerations 8. IANA Considerations
IANA is requested to allocate new sub-TLVs as defined in Sections 2 IANA has allocated new sub-TLVs as defined in Sections 2 and 3 as
and 3 as follows: follows:
8.1. Node Information 8.1. Node Information
IANA maintains the "Open Shortest Path First (OSPF) Traffic IANA maintains the "Open Shortest Path First (OSPF) Traffic
Engineering TLVs" registry with a sub-registry called "Types for Engineering TLVs" registry with a sub-registry called "Types for sub-
sub-TLVs of TE Node Attribute TLV". IANA is requested to assign a TLVs of TE Node Attribute TLV (Value 5)". IANA has assigned a new
new code point as follows: code point as follows:
Type | Sub-TLV | Reference Type | Sub-TLV | Reference
-------+-------------------------------+------------ -------+-------------------------------+------------
TBD1 | Connectivity Matrix | [This.I-D] 14 | Connectivity Matrix | [RFC7580]
8.2. Link Information 8.2. Link Information
IANA maintains the "Open Shortest Path First (OSPF) Traffic IANA maintains the "Open Shortest Path First (OSPF) Traffic
Engineering TLVs" registry with a sub-registry called "Types for Engineering TLVs" registry with a sub-registry called "Types for sub-
sub-LVs of TE Link TLV". IANA is requested to assign a new code TLVs of TE Link TLV (Value 2)". IANA has assigned a new code point
point as follows: as follows:
Type | Sub-TLV | Reference Type | Sub-TLV | Reference
-------+-----------------------------------+------------ -------+-------------------------------+------------
TBD2 | Port Label Restrictions | [This.I-D] 34 | Port Label Restrictions | [RFC7580]
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.
[RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
Engineering (TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
September 2003. DOI 10.17487/RFC3630, September 2003,
<http://www.rfc-editor.org/info/rfc3630>.
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol Label Extensions in Support of Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4202, October 2005 Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202,
October 2005, <http://www.rfc-editor.org/info/rfc4202>.
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
in Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, October 2005. (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<http://www.rfc-editor.org/info/rfc4203>.
[RFC5250] L. Berger, I. Bryskin, A. Zinin, R. Coltun "The OSPF [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
Opaque LSA Option", RFC 5250, July 2008. OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250,
July 2008, <http://www.rfc-editor.org/info/rfc5250>.
[RFC5786] R. Aggarwal and K. Kompella,"Advertising a Router's Local [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's
Addresses in OSPF Traffic Engineering (TE) Extensions", Local Addresses in OSPF Traffic Engineering (TE)
RFC 5786, March 2010. Extensions", RFC 5786, DOI 10.17487/RFC5786, March 2010,
<http://www.rfc-editor.org/info/rfc5786>.
[GEN-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, " General [RFC7579] Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and
Network Element Constraint Encoding for GMPLS Controlled J. Han, "General Network Element Constraint Encoding for
Networks", work in progress: draft-ietf-ccamp-general- GMPLS-Controlled Networks", RFC 7579,
constraint-encode. DOI 10.17487/RFC7579, June 2015,
<http://www.rfc-editor.org/info/rfc7579>.
9.2. Informative References 9.2. Informative References
[RFC6020] M. Bjorklund, Ed., "YANG - A Data Modeling Language for [BGP-LS] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
the Network Configuration Protocol (NETCONF)", RFC 6020, Ray, "North-Bound Distribution of Link-State and TE
October 2010. Information using BGP", Work in Progress,
draft-ietf-idr-ls-distribution-11, June 2015.
[RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
PCE Control of Wavelength Switched Optical Networks the Network Configuration Protocol (NETCONF)", RFC 6020,
(WSON)", RFC 6163, February 2011. DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>.
[RFC6241] R. Enns, Ed., M. Bjorklund, Ed., Schoenwaelder, Ed., A. [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku,
Bierman, Ed., "Network Configuration Protocol (NETCONF)", "Framework for GMPLS and Path Computation Element (PCE)
RFC 6241, June 2011. Control of Wavelength Switched Optical Networks (WSONs)",
RFC 6163, DOI 10.17487/RFC6163, April 2011,
<http://www.rfc-editor.org/info/rfc6163>.
[RFC6825] M. Miyazawa, T. Otani, K. Kumaki, T. Nadeau, "Traffic [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
Engineering Database Management Information Base in and A. Bierman, Ed., "Network Configuration Protocol
Support of MPLS-TE/GMPLS", RFC 6825, January 2013. (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>.
[RFC7446] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and [RFC6825] Miyazawa, M., Otani, T., Kumaki, K., and T. Nadeau,
Wavelength Assignment Information Model for Wavelength "Traffic Engineering Database Management Information Base
Switched Optical Networks", RFC 7446, February 2015. in Support of MPLS-TE/GMPLS", RFC 6825,
DOI 10.17487/RFC6825, January 2013,
<http://www.rfc-editor.org/info/rfc6825>.
[RFC5920] L. Fang, Ed., "Security Framework for MPLS and GMPLS [RFC7446] Lee, Y., Ed., Bernstein, G., Ed., Li, D., and W. Imajuku,
Networks", RFC 5920, July 2010. "Routing and Wavelength Assignment Information Model for
Wavelength Switched Optical Networks", RFC 7446,
DOI 10.17487/RFC7446, February 2015,
<http://www.rfc-editor.org/info/rfc7446>.
[BGP-LS] H. Gredler, J. Medved, S. Previdi, A. Farrel, S. Ray, [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
"North-Bound Distribution of Link-State and TE Information Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
using BGP", work in progress: draft-ietf-idr-ls- <http://www.rfc-editor.org/info/rfc5920>.
distribution.
10. Contributors Acknowledgments
We thank Ming Chen and Yabin Ye from DICONNET Project who provided
valuable information for this document.
Contributors
Guoying Zhang Guoying Zhang
China Academy of Telecommunication Research of MII China Academy of Telecommunication Research of MII
11 Yue Tan Nan Jie Beijing, P.R.China 11 Yue Tan Nan Jie
Beijing
China
Phone: +86-10-68094272 Phone: +86-10-68094272
Email: zhangguoying@mail.ritt.com.cn EMail: zhangguoying@mail.ritt.com.cn
Dan Li Dan Li
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base F3-5-B R&D Center, Huawei Base
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129
China
Phone: +86-755-28973237 Phone: +86-755-28973237
Email: danli@huawei.com EMail: danli@huawei.com
Ming Chen Ming Chen
European Research Center European Research Center
Huawei Technologies Huawei Technologies
Riesstr. 25, 80992 Munchen, Germany Riesstr. 25, 80992
Munchen
Germany
Phone: 0049-89158834072 Phone: 0049-89158834072
Email: minc@huawei.com EMail: minc@huawei.com
Yabin Ye Yabin Ye
European Research Center European Research Center
Huawei Technologies Huawei Technologies
Riesstr. 25, 80992 Munchen, Germany Riesstr. 25, 80992
Munchen
Germany
Phone: 0049-89158834074 Phone: 0049-89158834074
Email: yabin.ye@huawei.com EMail: yabin.ye@huawei.com
Authors' Addresses Authors' Addresses
Fatai Zhang Fatai Zhang
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Base F3-5-B R&D Center, Huawei Base
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129
China
Phone: +86-755-28972912 Phone: +86-755-28972912
Email: zhangfatai@huawei.com EMail: zhangfatai@huawei.com
Young Lee Young Lee
Huawei Technologies Huawei Technologies
5360 Legacy Drive, Building 3 5360 Legacy Drive, Building 3
Plano, TX 75023 Plano, TX 75023
USA United States
Phone: (469)277-5838 Phone: (469)277-5838
Email: leeyoung@huawei.com EMail: leeyoung@huawei.com
Jianrui Han Jianrui Han
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base F3-5-B R&D Center, Huawei Base
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129
China
Phone: +86-755-28977943 Phone: +86-755-28977943
Email: hanjianrui@huawei.com EMail: hanjianrui@huawei.com
Greg Bernstein Greg Bernstein
Grotto Networking Grotto Networking
Fremont CA, USA Fremont, CA
United States
Phone: (510) 573-2237 Phone: (510) 573-2237
Email: gregb@grotto-networking.com EMail: gregb@grotto-networking.com
Yunbin Xu Yunbin Xu
China Academy of Telecommunication Research of MII China Academy of Telecommunication Research of MII
11 Yue Tan Nan Jie Beijing, P.R.China 11 Yue Tan Nan Jie
Beijing
China
Phone: +86-10-68094134 Phone: +86-10-68094134
Email: xuyunbin@mail.ritt.com.cn EMail: xuyunbin@mail.ritt.com.cn
Acknowledgment
We thank Ming Chen and Yabin Ye from DICONNET Project who provided
valuable information for this document.
 End of changes. 109 change blocks. 
306 lines changed or deleted 329 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/