< draft-ietf-isis-traffic-04.txt   draft-ietf-isis-traffic-05.txt >
Network Working Group Henk Smit Network Working Group Henk Smit
INTERNET DRAFT Tony Li INTERNET DRAFT Tony Li
Procket Networks Procket Networks
December 2002 August 2003
IS-IS extensions for Traffic Engineering IS-IS extensions for Traffic Engineering
<draft-ietf-isis-traffic-04.txt> <draft-ietf-isis-traffic-05.txt>
Status Status
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC 2026 except that the right to of Section 10 of RFC2026.
produce derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
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.
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes extensions to the IS-IS protocol to support This document describes extensions to the IS-IS protocol to support
Traffic Engineering. Traffic Engineering.
skipping to change at line 72 skipping to change at page 2, line 30
The primary goal of these extensions is to add more information about The primary goal of these extensions is to add more information about
the characteristics of a particular link to an IS-IS's LSP. The the characteristics of a particular link to an IS-IS's LSP. The
characteristics described in this document are needed for Traffic characteristics described in this document are needed for Traffic
Engineering [4] (TE). Secondary goals include increasing the dynamic Engineering [4] (TE). Secondary goals include increasing the dynamic
range of the IS-IS metric and improving the encoding of IP prefixes. range of the IS-IS metric and improving the 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.
This document is a publication of the IS-IS Working Group within the
IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual
inclusion with ISO 10589 [1].
2.0 Introducing Sub-TLVs 2.0 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
skipping to change at line 350 skipping to change at page 8, line 25
0 0 0 0
1-8 1 1-8 1
9-16 2 9-16 2
17-24 3 17-24 3
25-32 4 25-32 4
The remaining bits of prefix are transmitted as zero and ignored upon The remaining bits of prefix are transmitted as zero and ignored upon
receipt. receipt.
If a prefix is advertised with a metric larger then MAX_PATH_METRIC If a prefix is advertised with a metric larger then MAX_PATH_METRIC
(0xFE000000, see paragraph 4.0), this prefix MUST NOT be considered (0xFE000000, see paragraph 3.0), this prefix MUST NOT be considered
during the normal SPF computation. This allows advertisement of a during the normal SPF computation. This allows advertisement of a
prefix for other purposes than building the normal IP routing table. prefix for other purposes than building the normal IP routing table.
4.1 The up/down bit 4.1 The up/down bit
Without any additional mechanisms, if routers were allowed to Without any additional mechanisms, if routers were allowed to
redistribute IP prefixes freely in both directions between level 1 redistribute IP prefixes freely in both directions between level 1
and level 2, those routers can not determine looping of routing and level 2, those routers can not determine looping of routing
information. A problem occurs when a router learns a prefix via information. A problem occurs when a router learns a prefix via
level 2 routing and advertises that prefix down into a level 1 area, level 2 routing and advertises that prefix down into a level 1 area,
skipping to change at line 440 skipping to change at page 10, line 23
If a router advertises the Traffic Engineering router ID TLV in its If a router advertises the Traffic Engineering router ID TLV in its
LSP, and if it advertises prefixes via the Border Gateway Protocol LSP, and if it advertises prefixes via the Border Gateway Protocol
(BGP) with the BGP next hop attribute set to the BGP router ID, in (BGP) with the BGP next hop attribute set to the BGP router ID, in
that case the Traffic Engineering router ID SHOULD be the same as the that case the Traffic Engineering router ID SHOULD be the same as the
BGP router ID. BGP router 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 their forwarding table, because this can lead to forwarding loops
when interacting with systems that do not support this TLV. when interacting with systems that do not support this TLV.
6. IANA Considerations
6.1 TLV codepoint allocations
This document defines the following new ISIS TLV types that need to
be reflected in the ISIS TLV code-point registry:
Type Description IIH LSP SNP
---- ----------------------------------- --- --- ---
22 The extended IS reachability TLV n y n
134 The Traffic Engineering router ID TLV n y n
135 The extended IP reachability TLV n y n
6.2 New registries
IANA is requested to create the following new registries.
6.2.1 Sub-TLVs for TLV 22
This registry contains codepoints for Sub-TLVs of TLV 22. The range
of values is 0-255. Allocations within the registry require
documentation of the use of the allocated value and approval by the
Designated Expert assigned by the IESG (see [5]).
Taking into consideration allocations specified in this document, the
registry should be initialized as follows:
Type Description
---- -----------------------------------
0-2 unassigned
3 Administrative group (color)
4-5 unassiged
6 IPv4 interface address
7 unassigned
8 IPv4 neighbor address
9 Maximum link bandwidth
10 Reservable link bandwidth
11 Unreserved bandwidth
12-17 unassigned
18 TE Default metric
19-254 unassigned
255 Reserved for future expansion
<IANA-note> To be removed by the RFC editor at the time of publication
At the time of registry creation, please perform the following
allocations in this registry:
Type Description
---- -----------------------------------
250 Reserved for Cisco-proprietary extensions
251 Reserved for Cisco-proprietary extensions
</IANA-note>
6.2.2 Sub-TLVs for TLV 135
This registry contains codepoints for Sub-TLVs of TLV 135. The range
of values is 0-255. Allocations within the registry require
documentation of the use of the allocated value and approval by the
Designated Expert assigned by the IESG (see [5]).
No codepoints are defined in this document.
Normative References Normative References
[1] ISO 10589, "Intermediate System to Intermediate System Intra- [1] ISO, "Intermediate System to Intermediate System Intra-Domain
Domain Routeing Exchange Protocol for use in Conjunction with the Routeing Exchange Protocol for use in Conjunction with the Protocol
Protocol for Providing the Connectionless-mode Network Service (ISO for Providing the Connectionless-mode Network Service (ISO 8473)",
8473)" [Also republished as RFC 1142] International Standard 10589:2002, Second Edition
[2] RFC 2966, "Domain-wide Prefix Distribution with Two-Level IS-IS", [2] RFC 2966, "Domain-wide Prefix Distribution with Two-Level IS-IS",
T. Li, T. Przygienda, H. Smit, October 2000. T. Li, T. Przygienda, H. Smit, October 2000.
Informative References Informative References
[3] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual [3] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual
environments", R.W. Callon, December 1990 environments", R.W. Callon, December 1990
[4] RFC 2702, "Requirements for Traffic Engineering Over MPLS," D. [4] RFC 2702, "Requirements for Traffic Engineering Over MPLS," D.
Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, September Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, September
1999. 1999
[5] RFC 2434, "Guidelines for Writing an IANA Considerations Section
in RFCs", Narten, T., and H. Alvestrand, BCP 26, October 1998
Security Considerations Security Considerations
This document raises no new security issues for IS-IS. This document raises no new security issues for IS-IS.
Acknowledgments Acknowledgments
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. comments on this work.
skipping to change at line 479 skipping to change at page 12, line 40
Tony Li Tony Li
Procket Networks, Inc. Procket Networks, Inc.
1100 Cadillac Court 1100 Cadillac Court
Milpitas, CA 95035 Milpitas, CA 95035
Email: tli@procket.com Email: tli@procket.com
Voice: +1 408 6357900 Voice: +1 408 6357900
Fax: +1 408 6356166 Fax: +1 408 6356166
Henk Smit Henk Smit
Email: hhwsmit@freeler.nl Email: hhwsmit@xs4all.nl
 End of changes. 12 change blocks. 
20 lines changed or deleted 78 lines changed or added

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