draft-ietf-isis-te-bis-00.txt   rfc5305.txt 
IS-IS for IP Internets Working T. Li Network Working Group T. Li
Group H. Smit Request for Comments: 5305 Redback Networks, Inc.
Internet-Draft Cisco Systems Obsoletes: 3784 H. Smit
Obsoletes: 3784 (if approved) August 2005 Category: Standards Track October 2008
Expires: February 2, 2006
IS-IS extensions for Traffic Engineering
draft-ietf-isis-te-bis-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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.
This Internet-Draft will expire on February 2, 2006. IS-IS Extensions for Traffic Engineering
Copyright Notice Status of This Memo
Copyright (C) The Internet Society (2005). This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract Abstract
This document describes extensions to the Intermediate System to This document describes extensions to the Intermediate System to
Intermediate System (IS-IS) protocol to support Traffic Engineering Intermediate System (IS-IS) protocol to support Traffic Engineering
(TE). This document extends the IS-IS protocol by specifying new (TE). This document extends the IS-IS protocol by specifying new
information that an Intermediate System (router) can place in Link information that an Intermediate System (router) can place in Link
State Protocol (LSP) Data Units. This information describes State Protocol Data Units (LSP). This information describes
additional details regarding the state of the network that are useful additional details regarding the state of the network that are useful
for traffic engineering computations. for traffic engineering computations.
Requirements Language
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 ....................................................2
1.1. Requirements Language ......................................3
2. Introducing Sub-TLVs . . . . . . . . . . . . . . . . . . . . . 4 2. Introducing Sub-TLVs ............................................3
3. The Extended IS Reachability TLV ................................3
3. The Extended IS Reachability TLV . . . . . . . . . . . . . . . 5 3.1. Sub-TLV 3: Administrative Group (color, resource class) ....6
3.1. Sub-TLV 3: Administrative group (color, resource class) . 7 3.2. Sub-TLV 6: IPv4 Interface Address ..........................6
3.2. Sub-TLV 6: IPv4 interface address . . . . . . . . . . . . 7 3.3. Sub-TLV 8: IPv4 Neighbor Address ...........................6
3.3. Sub-TLV 8: IPv4 neighbor address . . . . . . . . . . . . . 8 3.4. Sub-TLV 9: Maximum Link Bandwidth ..........................7
3.4. Sub-TLV 9: Maximum link bandwidth . . . . . . . . . . . . 8 3.5. Sub-TLV 10: Maximum Reservable Link Bandwidth ..............7
3.5. Sub-TLV 10: Maximum reservable link bandwidth . . . . . . 8 3.6. Sub-TLV 11: Unreserved Bandwidth ...........................7
3.6. Sub-TLV 11: Unreserved bandwidth . . . . . . . . . . . . . 9 3.7. Sub-TLV 18: Traffic Engineering Default Metric .............8
3.7. Sub-TLV 18: Traffic Engineering Default Metric . . . . . . 9 4. The Extended IP Reachability TLV ................................8
4.1. The up/down Bit ...........................................10
4. The Extended IP Reachability TLV . . . . . . . . . . . . . . . 10 4.2. Expandability of the Extended IP Reachability TLV
4.1. The up/down Bit . . . . . . . . . . . . . . . . . . . . . 11 with Sub-TLVs .............................................11
4.2. Expandability of the Extended IP Reachability TLV with 4.3. The Traffic Engineering Router ID TLV .....................11
Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations ............................................12
4.3. The Traffic Engineering Router ID TLV . . . . . . . . . . 12 5.1. TLV Codepoint Allocations .................................12
5.2. New Registries ............................................13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5.2.1. Sub-TLVs for the Extended IS Reachability TLV ......13
5.1. TLV Codepoint Allocations . . . . . . . . . . . . . . . . 14 5.2.2. Sub-TLVs for the Extended IP Reachability TLV ......15
5.2. New Registries . . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations ........................................15
5.2.1. Sub-TLVs for the Extended IS Reachability TLV . . . . 14 7. Acknowledgements ...............................................15
5.2.2. Sub-TLVs for the Extended IP Reachability TLV . . . . 15 8. References .....................................................15
8.1. Normative References ......................................15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References ....................................15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
1. Introduction 1. Introduction
The IS-IS protocol is specified in ISO 10589 [ISO-10589], with The IS-IS protocol is specified in ISO 10589 [ISO-10589], with
extensions for supporting IPv4 specified in [RFC1195]. Each extensions for supporting IPv4 specified in [RFC1195]. Each
Intermediate System (IS) (router) advertises one or more IS-IS Link Intermediate System (IS) (router) advertises one or more IS-IS Link
State Protocol Data Units (LSPs) with routing information. Each LSP State Protocol Data Units (LSPs) with routing information. Each LSP
is composed of a fixed header and a number of tuples, each consisting is composed of a fixed header and a number of tuples, each consisting
of a Type, a Length, and a Value. Such tuples are commonly known as of a Type, a Length, and a Value. Such tuples are commonly known as
TLVs, and are a good way of encoding information in a flexible and TLVs, and are a good way of encoding information in a flexible and
extensible format. extensible format.
This document contains the design of new TLVs to replace the existing This document contains the design of new TLVs to replace the existing
IS Neighbor TLV, IP Reachability TLV, and to include additional IS Neighbor TLV and IP Reachability TLV, and to include additional
information about the characteristics of a particular link to an IS- information about the characteristics of a particular link to an IS-
IS LSP. The characteristics described in this document are needed IS LSP. The characteristics described in this document are needed
for Traffic Engineering [RFC2702]. Secondary goals include for traffic engineering [RFC2702]. Secondary goals include
increasing the dynamic range of the IS-IS metric and improving the increasing the dynamic range of the IS-IS metric and improving the
encoding of IP prefixes. encoding of IP prefixes.
The router id is useful for traffic engineering purposes because it The router ID is useful for traffic engineering purposes because it
describes a single address that can always be used to reference a describes a single address that can always be used to reference a
particular router. particular router.
Mechanisms and procedures to migrate to the new TLVs are not Mechanisms and procedures to migrate to the new TLVs are not
discussed in this document. discussed in this document.
A prior version of this document was published as [RFC3784] with A prior version of this document was published as [RFC3784] with
Informational status. This version is on the standards track. Informational status. This version is on the standards track.
1.1. Requirements Language
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].
2. Introducing Sub-TLVs 2. Introducing Sub-TLVs
This document introduces a new way to encode routing information in This document introduces a new way to encode routing information in
IS-IS. The new object is called a sub-TLV. Sub-TLVs are similar to IS-IS. The new object is called a sub-TLV. Sub-TLVs are similar to
regular TLVs. They use the same concepts as regular TLVs. The regular TLVs. They use the same concepts as regular TLVs. The
difference is that TLVs exist inside IS-IS packets, while sub-TLVs difference is that TLVs exist inside IS-IS packets, while sub-TLVs
exist inside TLVs. TLVs are used to add extra information to IS-IS exist inside TLVs. TLVs are used to add extra information to IS-IS
packets. Sub-TLVs are used to add extra information to particular packets. Sub-TLVs are used to add extra information to particular
TLVs. Each sub-TLV consists of three fields, a one-octet Type field, TLVs. Each sub-TLV consists of three fields, a one-octet Type field,
a one-octet Length field, and zero or more octets of Value. The Type a one-octet Length field, and zero or more octets of Value. The Type
field indicates the type of items in the Value field. The Length field indicates the type of items in the Value field. The Length
field indicates the length of the Value field in octets. Each sub- field indicates the length of the Value field in octets. Each sub-
TLV can potentially hold multiple items. The number of items in a TLV can potentially hold multiple items. The number of items in a
sub-TLV can be computed from the length of the whole sub-TLV, when sub-TLV can be computed from the length of the whole sub-TLV, when
the length of each item is known. Unknown sub-TLVs are to be ignored the length of each item is known. Unknown sub-TLVs are to be ignored
and skipped upon receipt. and skipped upon receipt.
The Sub-TLV type space is managed by the IETF IS-IS WG [1]. New type The Sub-TLV type space is managed by the IETF IS-IS WG [ISIS-WG].
values are allocated following review on the IETF IS-IS mailing list. New type values are allocated following review on the IETF IS-IS
This will normally require publication of additional documentation mailing list. This will normally require publication of additional
describing how the new type is used. In the event that the IS-IS documentation describing how the new type is used. In the event that
working group has disbanded the review shall be performed by a the IS-IS working group has disbanded, the review shall be performed
Designated Expert assigned by the responsible Area Director. by a Designated Expert assigned by the responsible Area Director.
3. The Extended IS Reachability TLV 3. The Extended IS Reachability TLV
The extended IS reachability TLV is TLV type 22. The extended IS reachability TLV is TLV type 22.
The existing IS reachability (TLV type 2, defined in ISO 10589 [ISO- The existing IS reachability (TLV type 2, defined in ISO 10589
10589]) contains information about a series of IS neighbors. For [ISO-10589]) contains information about a series of IS neighbors.
each neighbor, there is a structure that contains the default metric, For each neighbor, there is a structure that contains the default
the delay, the monetary cost, the reliability, and the 7-octet ID of metric, the delay, the monetary cost, the reliability, and the
the adjacent neighbor. Of this information, the default metric is 7-octet ID of the adjacent neighbor. Of this information, the
commonly used. The default metric is currently one octet, with one default metric is commonly used. The default metric is currently one
bit used to indicate whether the metric is internal or external, and octet, with one bit used to indicate whether the metric is internal
one bit that was originally unused, but which was later defined by or external, and one bit that was originally unused, but which was
[RFC2966] to be the up/down bit. The remaining 6 bits are used to later defined by [RFC5302] to be the up/down bit. The remaining 6
store the actual metric, resulting in a possible metric range of 0- bits are used to store the actual metric, resulting in a possible
63. This limitation is one of the restrictions that we would like to metric range of 0-63. This limitation is one of the restrictions
lift. that we would like to lift.
The remaining three metrics (delay, monetary cost, and reliability) The remaining three metrics (delay, monetary cost, and reliability)
are not commonly implemented and reflect unused overhead in the TLV. are not commonly implemented and reflect unused overhead in the TLV.
The neighbor is identified by its system ID, typically 6-octets, plus The neighbor is identified by its system ID, typically 6 octets, plus
one octet indicating the pseudonode number. Thus, the existing TLV one octet indicating the pseudonode number. Thus, the existing TLV
consumes 11 octets per neighbor, with 4 octets for metric and 7 consumes 11 octets per neighbor, with 4 octets for metric and 7
octets for neighbor identification. To indicate multiple octets for neighbor identification. To indicate multiple
adjacencies, this structure is repeated within the IS reachability adjacencies, this structure is repeated within the IS reachability
TLV. Because the TLV is limited to 255 octets of content, a single TLV. Because the TLV is limited to 255 octets of content, a single
TLV can describe up to 23 neighbors. The IS reachability TLV can be TLV can describe up to 23 neighbors. The IS reachability TLV can be
repeated within the LSP fragments to describe further neighbors. repeated within the LSP fragments to describe further neighbors.
The proposed extended IS reachability TLV contains a new data The proposed extended IS reachability TLV contains a new data
structure, consisting of: structure, consisting of:
7 octets of system Id and pseudonode number 7 octets of system ID and pseudonode number
3 octets of default metric 3 octets of default metric
1 octet of length of sub-TLVs 1 octet of length of sub-TLVs
0-244 octets of sub-TLVs, where each sub-TLV consists of a 0-244 octets of sub-TLVs, where each sub-TLV consists of a
sequence of sequence of
1 octet of sub-type 1 octet of sub-type
1 octet of length of the value field of the sub-TLV 1 octet of length of the Value field of the sub-TLV
0-242 octets of value 0-242 octets of value
Thus, if no sub-TLVs are used, the new encoding requires 11 octets Thus, if no sub-TLVs are used, the new encoding requires 11 octets
and can contain up to 23 neighbors. Please note that while the and can contain up to 23 neighbors. Please note that while the
encoding allows for 255 octets of sub-TLVs, the maximum value cannot encoding allows for 255 octets of sub-TLVs, the maximum value cannot
fit in the overall IS reachability TLV. The practical maximum is 255 fit in the overall IS reachability TLV. The practical maximum is 255
octets minus the 11 octets described above, or 244 octets. Further, octets minus the 11 octets described above, or 244 octets. There is
there is no defined mechanism for extending the sub-TLV space for a no defined mechanism for extending the sub-TLV space. Thus, wasting
particular neighbor. Thus, wasting sub-TLV space is discouraged. sub-TLV space is discouraged.
The metric octets are encoded as a 24-bit unsigned integer. Note The metric octets are encoded as a 24-bit unsigned integer. Note
that the metric field in the new extended IP reachability TLV is that the Metric field in the new extended IP reachability TLV is
encoded as a 32-bit unsigned integer. These different sizes were encoded as a 32-bit unsigned integer. These different sizes were
chosen so that it is very unlikely that the cost of an intra-area chosen so that it is very unlikely that the cost of an intra-area
route has to be chopped off to fit in the metric field of an inter- route has to be chopped off to fit in the Metric field of an inter-
area route. area route.
To preclude overflow within a traffic engineering SPF implementation, To preclude overflow within a traffic engineering Shortest Path First
all metrics greater than or equal to MAX_PATH_METRIC SHALL be (SPF) implementation, all metrics greater than or equal to
considered to have a metric of MAX_PATH_METRIC. It is easiest to MAX_PATH_METRIC SHALL be considered to have a metric of
select MAX_PATH_METRIC such that MAX_PATH_METRIC plus a single link MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that
metric does not overflow the number of bits for internal metric MAX_PATH_METRIC plus a single link metric does not overflow the
calculation. We assume that this is 32 bits. Therefore, we have number of bits for internal metric calculation. We assume that this
chosen MAX_PATH_METRIC to be 4,261,412,864 (0xFE000000, 2^32 - 2^25). is 32 bits. Therefore, we have chosen MAX_PATH_METRIC to be
4,261,412,864 (0xFE000000, 2^32 - 2^25).
If a link is advertised with the maximum link metric (2^24 - 1), this If a link is advertised with the maximum link metric (2^24 - 1), this
link MUST NOT be considered during the normal SPF computation. This link MUST NOT be considered during the normal SPF computation. This
will allow advertisement of a link for purposes other than building will allow advertisement of a link for purposes other than building
the normal Shortest Path Tree. An example is a link that is the normal Shortest Path Tree. An example is a link that is
available for traffic engineering, but not for hop-by-hop routing. available for traffic engineering, but not for hop-by-hop routing.
Certain sub-TLVs are proposed here: Certain sub-TLVs are established here:
+------------+----------------+-------------------------------------+ +------------+----------------+-------------------------------------+
| Sub-TLV | Length | Name | | Sub-TLV | Length | Name |
| type | (octets) | | | type | (octets) | |
+------------+----------------+-------------------------------------+ +------------+----------------+-------------------------------------+
| 3 | 4 | Administrative group (color) | | 3 | 4 | Administrative group (color) |
| | | | | | | |
| 6 | 4 | IPv4 interface address | | 6 | 4 | IPv4 interface address |
| | | | | | | |
| 8 | 4 | IPv4 neighbor address | | 8 | 4 | IPv4 neighbor address |
| | | | | | | |
| 9 | 4 | Maximum link bandwidth | | 9 | 4 | Maximum link bandwidth |
| | | | | | | |
| 10 | 4 | Reservable link bandwidth | | 10 | 4 | Maximum reservable link bandwidth |
| | | | | | | |
| 11 | 32 | Unreserved bandwidth | | 11 | 32 | Unreserved bandwidth |
| | | | | | | |
| 18 | 3 | TE Default metric | | 18 | 3 | TE Default metric |
| | | | | | | |
| 250-254 | | Reserved for cisco specific | | 250-254 | | Reserved for Cisco specific |
| | | extensions | | | | extensions |
| | | | | | | |
| 255 | | Reserved for future expansion | | 255 | | Reserved for future expansion |
+------------+----------------+-------------------------------------+ +------------+----------------+-------------------------------------+
Each of these sub-TLVs is described below. Unless stated otherwise, Each of these sub-TLVs is described below. Unless stated otherwise,
multiple occurrences of the information are supported by multiple multiple occurrences of the information are supported by multiple
inclusions of the sub-TLV. inclusions of the sub-TLV.
3.1. Sub-TLV 3: Administrative group (color, resource class) 3.1. Sub-TLV 3: Administrative Group (color, resource class)
The administrative group sub-TLV contains a 4-octet bit mask assigned The administrative group sub-TLV contains a 4-octet bit mask assigned
by the network administrator. Each set bit corresponds to one by the network administrator. Each set bit corresponds to one
administrative group assigned to the interface. administrative group assigned to the interface.
By convention, the least significant bit is referred to as 'group 0', By convention, the least significant bit is referred to as 'group 0',
and the most significant bit is referred to as 'group 31'. and the most significant bit is referred to as 'group 31'.
This sub-TLV is OPTIONAL. This sub-TLV SHOULD appear once at most in This sub-TLV is OPTIONAL. This sub-TLV SHOULD appear once at most in
each extended IS reachability TLV. each extended IS reachability TLV.
3.2. Sub-TLV 6: IPv4 interface address 3.2. Sub-TLV 6: IPv4 Interface Address
This sub-TLV contains a 4-octet IPv4 address for the interface This sub-TLV contains a 4-octet IPv4 address for the interface
described by the (main) TLV. This sub-TLV can occur multiple times. described by the (main) TLV. This sub-TLV can occur multiple times.
Implementations MUST NOT inject a /32 prefix for the interface Implementations MUST NOT inject a /32 prefix for the interface
address into their routing or forwarding table because this can lead address into their routing or forwarding table because this can lead
to forwarding loops when interacting with systems that do not support to forwarding loops when interacting with systems that do not support
this sub-TLV. this sub-TLV.
If a router implements the basic TLV extensions in this document, it If a router implements the basic TLV extensions in this document, it
MAY add or omit this sub-TLV from the description of an adjacency. MAY add or omit this sub-TLV from the description of an adjacency.
If a router implements traffic engineering, it MUST include this sub- If a router implements traffic engineering, it MUST include this sub-
TLV. TLV.
3.3. Sub-TLV 8: IPv4 neighbor address 3.3. Sub-TLV 8: IPv4 Neighbor Address
This sub-TLV contains a single IPv4 address for a neighboring router This sub-TLV contains a single IPv4 address for a neighboring router
on this link. This sub-TLV can occur multiple times. on this link. This sub-TLV can occur multiple times.
Implementations MUST NOT inject a /32 prefix for the neighbor address Implementations MUST NOT inject a /32 prefix for the neighbor address
into their routing or forwarding table because this can lead to into their routing or forwarding table because this can lead to
forwarding loops when interacting with systems that do not support forwarding loops when interacting with systems that do not support
this sub-TLV. this sub-TLV.
If a router implements the basic TLV extensions in this document, it If a router implements the basic TLV extensions in this document, it
MAY add or omit this sub-TLV from the description of an adjacency. MAY add or omit this sub-TLV from the description of an adjacency.
If a router implements traffic engineering, it MUST include this sub- If a router implements traffic engineering, it MUST include this sub-
TLV on point-to-point adjacencies. TLV on point-to-point adjacencies.
3.4. Sub-TLV 9: Maximum link bandwidth 3.4. Sub-TLV 9: Maximum Link Bandwidth
This sub-TLV contains the maximum bandwidth that can be used on this This sub-TLV contains the maximum bandwidth that can be used on this
link in this direction (from the system originating the LSP to its link in this direction (from the system originating the LSP to its
neighbors). This is useful for traffic engineering. neighbors). This is useful for traffic engineering.
The maximum link bandwidth is encoded in 32 bits in IEEE floating The maximum link bandwidth is encoded in 32 bits in IEEE floating
point format. The units are bytes (not bits!) per second. point format. The units are bytes (not bits!) per second.
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in This sub-TLV is optional. This sub-TLV SHOULD appear once at most in
each extended IS reachability TLV. each extended IS reachability TLV.
3.5. Sub-TLV 10: Maximum reservable link bandwidth 3.5. Sub-TLV 10: Maximum Reservable Link Bandwidth
This sub-TLV contains the maximum amount of bandwidth that can be This sub-TLV contains the maximum amount of bandwidth that can be
reserved in this direction on this link. Note that for reserved in this direction on this link. Note that for
oversubscription purposes, this can be greater than the bandwidth of oversubscription purposes, this can be greater than the bandwidth of
the link. the link.
The maximum reservable link bandwidth is encoded in 32 bits in IEEE The maximum reservable link bandwidth is encoded in 32 bits in IEEE
floating point format. The units are bytes (not bits!) per second. floating point format. The units are bytes (not bits!) per second.
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in This sub-TLV is optional. This sub-TLV SHOULD appear once at most in
each extended IS reachability TLV. each extended IS reachability TLV.
3.6. Sub-TLV 11: Unreserved bandwidth 3.6. Sub-TLV 11: Unreserved Bandwidth
This sub-TLV contains the amount of bandwidth reservable in this This sub-TLV contains the amount of bandwidth reservable in this
direction on this link. Note that for oversubscription purposes, direction on this link. Note that for oversubscription purposes,
this can be greater than the bandwidth of the link. this can be greater than the bandwidth of the link.
Because of the need for priority and preemption, each head end needs Because of the need for priority and preemption, each head end needs
to know the amount of reserved bandwidth at each priority level. to know the amount of reserved bandwidth at each priority level.
Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers. Thus, this sub-TLV contains eight 32-bit IEEE floating point numbers.
The units are bytes (not bits!) per second. The values correspond to The units are bytes (not bits!) per second. The values correspond to
the bandwidth that can be reserved with a setup priority of 0 through the bandwidth that can be reserved with a setup priority of 0 through
7, arranged in increasing order with priority 0 occurring at the 7, arranged in increasing order with priority 0 occurring at the
start of the sub-TLV, and priority 7 at the end of the sub-TLV. start of the sub-TLV, and priority 7 at the end of the sub-TLV.
For stability reasons, rapid changes in the values in this sub-TLV For stability reasons, rapid changes in the values in this sub-TLV
SHOULD NOT cause rapid generation of LSPs. SHOULD NOT cause rapid generation of LSPs.
This sub-TLV is optional. This sub-TLV SHOULD appear once at most in This sub-TLV is optional. This sub-TLV SHOULD appear once at most in
each extended IS reachability TLV. each extended IS reachability TLV.
skipping to change at page 10, line 19 skipping to change at page 8, line 39
The existing IP reachability TLVs (TLV type 128 and TLV type 130, The existing IP reachability TLVs (TLV type 128 and TLV type 130,
defined in [RFC1195]) carry IP prefixes in a format that is analogous defined in [RFC1195]) carry IP prefixes in a format that is analogous
to the IS neighbor TLV from ISO 10589 [ISO-10589]. They carry four to the IS neighbor TLV from ISO 10589 [ISO-10589]. They carry four
metrics, of which only the default metric is commonly used. The metrics, of which only the default metric is commonly used. The
default metric has a possible range of 0-63. We would like to remove default metric has a possible range of 0-63. We would like to remove
this restriction. this restriction.
In addition, route redistribution (a.k.a. route leaking) has a key In addition, route redistribution (a.k.a. route leaking) has a key
problem that was not fully addressed by the existing IP reachability problem that was not fully addressed by the existing IP reachability
TLVs. [RFC1195] allows a router to advertise prefixes upwards in the TLVs. [RFC1195] allows a router to advertise prefixes upwards in the
level hierarchy. Unfortunately there were no mechanisms defined to level hierarchy. Unfortunately, there were no mechanisms defined to
advertise prefixes downwards in the level hierarchy. advertise prefixes downwards in the level hierarchy.
To address these two issues, the proposed extended IP reachability To address these two issues, the proposed extended IP reachability
TLV provides for a 32 bit metric and adds one bit to indicate that a TLV provides for a 32-bit metric and adds one bit to indicate that a
prefix has been redistributed 'down' in the hierarchy. prefix has been redistributed 'down' in the hierarchy.
The proposed extended IP reachability TLV contains a new data The proposed extended IP reachability TLV contains a new data
structure, consisting of: structure, consisting of:
4 octets of metric information 4 octets of metric information
1 octet of control information, consisting of 1 octet of control information, consisting of
1 bit of up/down information 1 bit of up/down information
1 bit indicating the presence of sub-TLVs 1 bit indicating the presence of sub-TLVs
6 bits of prefix length 6 bits of prefix length
0-4 octet of IPv4 prefix 0-4 octets of IPv4 prefix
0-250 optional octets of sub-TLVs, if present consisting of 0-250 optional octets of sub-TLVs, if present consisting of
1 octet of length of sub-TLVs 1 octet of length of sub-TLVs
0-249 octets of sub-TLVs, where each sub-TLV consists of a 0-249 octets of sub-TLVs, where each sub-TLV consists of a
sequence of sequence of
1 octet of sub-type 1 octet of sub-type
1 octet of length of the value field of the sub-TLV
1 octet of length of the Value field of the sub-TLV
0-247 octets of value 0-247 octets of value
This data structure can be replicated within the TLV, without This data structure can be replicated within the TLV, as long as the
exceeding the maximum length of the TLV. maximum length of the TLV is not exceeded.
The 6 bits of prefix length can have the values 0-32 and indicate the The 6 bits of prefix length can have the values 0-32 and indicate the
number of significant bits in the prefix. The prefix is encoded in number of significant bits in the prefix. The prefix is encoded in
the minimal number of octets for the given number of significant the minimal number of octets for the given number of significant
bits. This implies: bits. This implies:
+------------------+--------+ +------------------+--------+
| Significant bits | Octets | | Significant bits | Octets |
+------------------+--------+ +------------------+--------+
| 0 | 0 | | 0 | 0 |
skipping to change at page 12, line 10 skipping to change at page 10, line 52
loop between them, where part of the looped path is via level 1 loop between them, where part of the looped path is via level 1
routing and the other part of the looped path is via level 2 routing. routing and the other part of the looped path is via level 2 routing.
The solution that [RFC1195] poses is to allow only advertising The solution that [RFC1195] poses is to allow only advertising
prefixes upward in the level hierarchy, and to disallow the prefixes upward in the level hierarchy, and to disallow the
advertising of prefixes downward in the hierarchy. advertising of prefixes downward in the hierarchy.
To prevent this looping of prefixes between levels, a new bit of To prevent this looping of prefixes between levels, a new bit of
information is defined in the new extended IP reachability TLV. This information is defined in the new extended IP reachability TLV. This
bit is called the up/down bit. The up/down bit SHALL be set to 0 bit is called the up/down bit. The up/down bit SHALL be set to 0
when a prefix is first injected into IS-IS. If a prefix is when a prefix is first injected into IS-IS. If a prefix is
advertised from a higher level to a lower level (e.g. level 2 to advertised from a higher level to a lower level (e.g., level 2 to
level 1), the bit MUST be set to 1, indicating that the prefix has level 1), the bit MUST be set to 1, indicating that the prefix has
traveled down the hierarchy. Prefixes that have the up/down bit set traveled down the hierarchy. Prefixes that have the up/down bit set
to 1 may only be advertised down the hierarchy, i.e. to lower levels. to 1 may only be advertised down the hierarchy, i.e., to lower
levels.
These semantics apply even if IS-IS is extended in the future to have These semantics apply even if IS-IS is extended in the future to have
additional levels. By insuring that prefixes follow only the IS-IS additional levels. By ensuring that prefixes follow only the IS-IS
hierarchy, we have insured that the information does not loop, hierarchy, we have ensured that the information does not loop,
thereby insuring that there are no persistent forwarding loops. thereby ensuring that there are no persistent forwarding loops.
If a prefix is advertised from one area to another at the same level, If a prefix is advertised from one area to another at the same level,
then the up/down bit SHALL be set to 1. This situation can arise then the up/down bit SHALL be set to 1. This situation can arise
when a router implements multiple virtual routers at the same level, when a router implements multiple virtual routers at the same level,
but in different areas. but in different areas.
The semantics of the up/down bit in the new extended IP reachability The semantics of the up/down bit in the new extended IP reachability
TLV are identical to the semantics of the up/down bit defined in TLV are identical to the semantics of the up/down bit defined in
[RFC2966]. [RFC5302].
4.2. Expandability of the Extended IP Reachability TLV with Sub-TLVs 4.2. Expandability of the Extended IP Reachability TLV with Sub-TLVs
The extended IP reachability TLV can hold sub-TLVs that apply to a The extended IP reachability TLV can hold sub-TLVs that apply to a
particular prefix. This allows for easy future extensions. If there particular prefix. This allows for easy future extensions. If there
are no sub-TLVs associated with a prefix, the bit indicating the are no sub-TLVs associated with a prefix, the bit indicating the
presence of sub-TLVs SHALL be set to 0. If this bit is set to 1, the presence of sub-TLVs SHALL be set to 0. If this bit is set to 1, the
first octet after the prefix will be interpreted as the length of all first octet after the prefix will be interpreted as the length of all
sub-TLVs associated with this IPv4 prefix. Please note that while sub-TLVs associated with this IPv4 prefix. Please note that while
the encoding allows for 255 octets of sub-TLVs, the maximum value the encoding allows for 255 octets of sub-TLVs, the maximum value
skipping to change at page 14, line 7 skipping to change at page 12, line 25
(BGP) with the BGP next hop attribute set to the BGP router ID, the (BGP) with the BGP next hop attribute set to the BGP router ID, the
Traffic Engineering router ID SHOULD be the same as the BGP router Traffic Engineering router ID SHOULD be the same as the BGP router
ID. ID.
Implementations MUST NOT inject a /32 prefix for the router ID into Implementations MUST NOT inject a /32 prefix for the router ID into
their forwarding table because this can lead to forwarding loops when their forwarding table because this can lead to forwarding loops when
interacting with systems that do not support this TLV. interacting with systems that do not support this TLV.
5. IANA Considerations 5. IANA Considerations
This document makes no new request of IANA. Prior IANA requests for Prior IANA requests for this purpose were covered as part of
this purpose were coverered as part of [RFC3784]. The text of those [RFC3784]. The text of those requests is reproduced here for
requests is reproduced here for completeness and consistency. completeness and consistency.
Note to RFC Editor: this paragraph and the above paragraph may be
removed or edited on publication as an RFC.
5.1. TLV Codepoint Allocations 5.1. TLV Codepoint Allocations
This document defines the following new IS-IS TLV types, which have This document defines the following new IS-IS TLV types, which have
been reflected in the ISIS TLV code-point registry: been reflected in the ISIS TLV codepoint registry:
+------+---------------------------------------+-----+-----+-----+ +------+---------------------------------------+-----+-----+-----+
| Type | Description | IIH | LSP | SNP | | Type | Description | IIH | LSP | SNP |
+------+---------------------------------------+-----+-----+-----+ +------+---------------------------------------+-----+-----+-----+
| 22 | The extended IS reachability TLV | n | y | n | | 22 | The extended IS reachability TLV | n | y | n |
| | | | | | | | | | | |
| 134 | The Traffic Engineering router ID TLV | n | y | n | | 134 | The Traffic Engineering router ID TLV | n | y | n |
| | | | | | | | | | | |
| 135 | The extended IP reachability TLV | n | y | n | | 135 | The extended IP reachability TLV | n | y | n |
+------+---------------------------------------+-----+-----+-----+ +------+---------------------------------------+-----+-----+-----+
5.2. New Registries 5.2. New Registries
IANA has created the following new registries. IANA has created the following new registries.
5.2.1. Sub-TLVs for the Extended IS Reachability TLV 5.2.1. Sub-TLVs for the Extended IS Reachability TLV
This registry contains codepoints for Sub-TLVs of TLV 22. The range This registry contains codepoints for sub-TLVs of TLV 22. The range
of values is 0-255. Allocations within the registry require of values is 0-255. Allocations within the registry require
documentation of the proposed use of the allocated value and approval documentation of the proposed use of the allocated value and approval
by the Designated Expert assigned by the IESG (see [RFC2434]). by the Designated Expert assigned by the IESG (see [RFC5226]).
Taking into consideration allocations specified in this document, the Taking into consideration allocations specified in this document, the
registry has been initialized as follows: registry has been initialized as follows:
+--------+-------------------------------+ +--------+------------------------------------+
| Type | Description | | Type | Description |
+--------+-------------------------------+ +--------+------------------------------------+
| 0-2 | unassigned | | 0-2 | unassigned |
| | | | | |
| 3 | Administrative group (color) | | 3 | Administrative group (color) |
| | | | | |
| 4-5 | unassigned | | 4 | Link Local/Remote Identifiers |
| | |
| 5 | unassigned |
| | | | | |
| 6 | IPv4 interface address | | 6 | IPv4 interface address |
| | | | | |
| 7 | unassigned | | 7 | unassigned |
| | | | | |
| 8 | IPv4 neighbor address | | 8 | IPv4 neighbor address |
| | | | | |
| 9 | Maximum link bandwidth | | 9 | Maximum link bandwidth |
| | | | | |
| 10 | Reservable link bandwidth | | 10 | Maximum Reservable link bandwidth |
| | | | | |
| 11 | Unreserved bandwidth | | 11 | Unreserved bandwidth |
| | | | | |
| 12-17 | unassigned | | 12-17 | unassigned |
| | | | | |
| 18 | TE Default metric | | 18 | TE Default metric |
| | | | | |
| 19-254 | unassigned | | 19 | Link-attributes |
| | |
| 20 | Link Protection Type |
| | |
| 21 | Interface Switching Capability |
| | Descriptor |
| | |
| 22 | Bandwidth Constraints |
| | |
| 23-249 | unassigned |
| | |
| 250-254| Reserved for Cisco specific |
| | extensions |
| | | | | |
| 255 | Reserved for future expansion | | 255 | Reserved for future expansion |
+--------+-------------------------------+ +--------+------------------------------------+
5.2.2. Sub-TLVs for the Extended IP Reachability TLV 5.2.2. Sub-TLVs for the Extended IP Reachability TLV
This registry contains codepoints for Sub-TLVs of TLV 135. The range This registry contains codepoints for sub-TLVs of TLV 135. The range
of values is 0-255. Allocations within the registry require of values is 0-255. Allocations within the registry require
documentation of the use of the allocated value and approval by the documentation of the use of the allocated value and approval by the
Designated Expert assigned by the IESG (see [RFC2434]). No Designated Expert assigned by the IESG (see [RFC5226]). No
codepoints are defined in this document. codepoints are defined in this document.
6. Security Considerations 6. Security Considerations
This document raises no new security issues for IS-IS. This document raises no new security issues for IS-IS; for general
security considerations for IS-IS see [RFC5304].
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Yakov Rekhter and Dave Katz for their The authors would like to thank Yakov Rekhter and Dave Katz for their
comments on this work. This work was funded in part by Procket comments on this work. This work was funded in part by Procket
Networks and Juniper Networks. Networks and Juniper Networks.
8. References 8. References
8.1. Normative References 8.1. Normative References
[ISO-10589] [ISO-10589] ISO, "Intermediate System to Intermediate System intra-
ISO, "Intermediate System to Intermediate System Intra- domain routeing information exchange protocol for use in
Domain Routeing Exchange Protocol for use in Conjunction conjunction with the protocol for providing the
with the Protocol for Providing the Connectionless-mode connectionless-mode network service (ISO 8473)",
Network Service (ISO 8473)", International Standard 10589: International Standard 10589: 2002, Second Edition, 2002.
2002, Second Edition, 2002.
[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, March 1997.
[RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix [RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix
Distribution with Two-Level IS-IS", RFC 2966, Distribution with Two-Level IS-IS", RFC 5302, October
October 2000. 2008.
8.2. Informative References 8.2. Informative References
[ISIS-WG] IS-IS for IP Internets (isis)
<http://www.ietf.org/html.charters/isis-charter.html>
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", McManus, "Requirements for Traffic Engineering Over
RFC 2702, September 1999. MPLS", RFC 2702, September 1999.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)", System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004. RFC 3784, June 2004.
URIs [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[1] <http://www.ietf.org/html.charters/isis-charter.html> [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, October 2008.
Authors' Addresses Authors' Addresses
Tony Li Tony Li
Cisco Systems Redback Networks, Inc.
170 W. Tasman Dr. 300 Holger Way
San Jose, California 95134 San Jose, CA 95134
USA USA
Phone: +1 408 525-0931 Phone: +1 408 750 5160
Fax: +1 408 526-4219 EMail: tony.li@tony.li
Email: tli@cisco.com
Henk Smit Henk Smit
Cisco Systems
170 W. Tasman Dr.
San Jose, California 95134
USA
Phone: +31 20 342 3736 EMail: hhw.smit@xs4all.nl
Email: hsmit@cisco.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 21, line 28 skipping to change at line 684
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 66 change blocks. 
183 lines changed or deleted 176 lines changed or added

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