view Side-By-Side changes

Date: Tue, 09 Apr 2002 04:31:51 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Mon, 28 Jun 1999 17:12:00 GMT
ETag: "2e6a2a-47c0-3777ace0"
Accept-Ranges: bytes
Content-Length: 18368
Connection: close
Content-Type: text/plainNetwork Working Group                                               Henk Smit
INTERNET DRAFT                                                  Cisco Systems                                                 Tony Li
                                                             Juniper
INTERNET DRAFT                                               Procket Networks
                                                                    Henk Smit
                                                             Procket Networks
                                                                     May 1999
                                                                    June 2001


                IS-IS extensions for Traffic Engineering

                    <draft-ietf-isis-traffic-01.txt>

                    <draft-ietf-isis-traffic-03.txt>


Status

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 RFC 2026 except that the right to
   produce derivative works is not granted.

   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.


1.0 Abstract

   This document describes extensions to the IS-IS protocol to support
   Traffic Engineering [1].  The IS-IS protocol is specified in [2],
   with extensions for supporting IPv4 specified in [3].

   This document extends the IS-IS protocol by specifying new
   information that a Intermediate System (IS) [router] can place in
   Link State Protocol Data Units (LSPs).  This information describes
   additional information about the state of the network that is useful
   for traffic engineering computations.





Expiration Date December 1999 2001                           [Page 1]





INTERNET DRAFT                                                 June 1999 2001


2.0 Introduction

   An IS-IS LSP 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 TLVs, and are a good way of encoding information in
   a flexible and extensible format.

   The changes in this document include the design of new TLVs to
   replace the existing IS Neighbor TLV, IP Reachability TLV and add
   additional information.  Mechanisms and procedures to migrate to the
   new TLVs are not discussed in this document.

   The primary goal of these extensions is to add more information about
   the characteristics of a particular link to an IS-IS's LSP.
   Secondary goals include increasing the dynamic range of the IS-IS
   metric and improving the encoding of IP prefixes.  The router id is
   useful for traffic engineering purposes because it describes a single
   address that can always be used to reference a 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. 10589 [2].


3.0 Introducing Sub-TLVs


   This document introduces a new way to encode routing information in
   IS-IS. The router ID TLV new object is called a sub-TLV. Sub-TLVs are similar to
   regular TLVs. They use the same concepts as regular TLVs.  The router ID TLV
   difference is TLV type 134. that TLVs exist inside IS-IS packets, while sub-TLVs
   exist inside TLVs.  TLVs are used to add extra information to IS-IS
   packets.  Sub-TLVs are used to add extra information to particular
   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 router ID TLV contains Type
   field indicates the 4-octet router ID type of items in the router
   originating Value field.  The Length
   field indicates the LSP.  This is useful length of the Value field in several regards:

   For traffic engineering, it guarantees that we have a single stable
   address that octets.  Each sub-
   TLV can always be referenced potentially hold multiple items. The number of items in a path that will
   sub-TLV can be
   reachable computed from multiple hops away, regardless of the state length of the
   node's interfaces.

   If OSPF is also active in the domain, traffic engineering can compute
   the mapping between the OSPF and IS-IS topologies.

   Implementations MUST NOT inject a /32 prefix for whole sub-TLV, when
   the router ID into
   their forwarding table, because this can lead length of each item is known.  Unknown sub-TLVs are to forwarding loops
   when interacting with systems that do not support this TLV. be ignored
   and skipped on receipt.










Expiration Date December 1999 2001                           [Page 2]





INTERNET DRAFT                                                 June 1999 2001


4.0 The extended IP IS reachability TLV


   The extended IP IS reachability TLV is TLV type 135. 22.
   The existing IP IS reachability TLV is a single TLV that carries IP
   prefixes (TLV type 2, defined in ISO 10589 [2])
   contains information about a format that is analogous to the IS neighbor TLV.  It
   carries four metrics, series of which only the default metric IS neighbors.  For each
   neighbor, there is commonly
   used.  Of this, a structure that contains the default metric has a metric, the
   delay, the monetary cost, the reliability, and the 7-octet ID of the
   adjacent neighbor.  Of this information, the default metric is
   commonly used.  The default metric is currently one octet, with one
   bit used to indicate that the metric is present and one bit used to
   indicate whether the metric is internal or external.  The remaining 6
   bits are used to store the actual metric, resulting a possible metric
   range of 0-63.  This limitation is one of the restrictions that we
   would like to lift.

   In addition, route redistribution (a.k.a. route leaking) is a key
   problem that is

   The remaining three metrics (delay, monetary cost, and reliability)
   are not addressed by commonly implemented and reflect unused overhead in the existing IP reachability TLV.
   This problem occurs when an IP prefix
   The neighbor is injected into a level one
   area, redistributed into level 2, subsequently redistributed into a
   second level one area, and then redistributed from the second level identified by its system Id (typically 6-octets),
   plus one area back into level two.  This problem occurs because octet to indicate the path
   that pseudonode number if the information can take forms a loop.  The likely result neighbor is
   on a
   forwarding loop.

   To address these issues, LAN interface.  Thus, the proposed extended IP reachability existing TLV
   provides consumes 11 octets per
   neighbor, with 4 octets for a 32 bit metric and adds one bit to 7 octets for neighbor
   identification.  To indicate that multiple adjacencies, this structure is
   repeated within the IS reachability TLV.  Because the TLV is limited
   to 255 octets of content, a
   prefix has been redistributed 'down' in single TLV can describe up to 23
   neighbors.  The IS reachability TLV can be repeated within the hierarchy. LSP
   fragments to describe further neighbors.

   The proposed extended IP IS reachability TLV contains a new data
   structure, consisting of:
           4 bytes of metric information
           1 byte
        7 octets of control information, consisting system Id and pseudonode number
        3 octets of default metric
        1 bit octet of up/down information
                   1 bit indicating the existence length of sub-TLVs
                   6 bits
        0-244 octets of prefix length
           0-4 bytes sub-TLVs,
             where each sub-TLV consists of IPv4 prefix
           0-250 optional octets a sequence of sub-TVLs, if present consisting
                  1 octet of sub-type
                  1 octet of length of sub-TLVs
                   0-249
                  0-242 octets of value


   Thus, if no sub-TLVs

   This data structure can be replicated within are used, the TLV, not new encoding requires 11 octets
   and can contain up to exceed 23 neighbors.  Please note that while the maximum length
   encoding allows for 255 octets of sub-TLVs, the maximum value cannot
   fit in the overall IS reachability TLV.  The up/down bit shall be set to 0 when a prefix is first injected
   into IS-IS.  If a prefix practical maximum is redistributed from a higher level to a
   lower level (e.g. level two to level one), the bit shall be set to 1,
   to indicate that the prefix has travelled down 255
   octets minus the hierarchy.
   Prefixes that have 11 octets described above, or 244 octets.  Further,
   there is no defined mechanism for extending the up/down bit set to 1 must not be
   redistributed.  If sub-TLV space for a prefix
   particular neighbor.  Thus, wasting sub-TLV space is redistributed from an area to another
   area at the same level, then the up/down bit shall be set to 1. discouraged.




Expiration Date December 1999 2001                           [Page 3]





INTERNET DRAFT                                                 June 1999 2001


   The metric octets are encoded as a 24-bit unsigned integer. Note that
   the metric field in the new extended IP reachability TLV is encoded
   as a 32-bit unsigned integer. These semantics apply even if IS-IS different sizes were chosen so
   that it is extended in very unlikely that the future cost of an intra-area route has to have
   additional levels.  By insuring that prefixes follow only the IS-IS
   hierarchy, we have insured that the information does not loop,
   thereby insuring that there are no persistent forwarding loops.

   If there are no sub-TLVs associated with this IP prefix, the bit
   indicating the presence of sub-TVLs shall
   be set to 0.  If this bit
   is set chopped off to 1, the first octet after the prefix will be interpreted as
   the length of sub-TLVs. Please note that while the encoding allows
   for 255 octets of sub-TLVs, the maximum value cannot fit in the
   overall extended IP reachability TLV. The practical maximum is 255
   octets minus the 5-9 octets described above, or 250 octets.  No sub-
   TLVs for the extended IP reachability TLV have been defined yet.

   The 6 bits metric field of prefix length can an inter-area route.

   To preclude overflow within an SPF implementation, all metrics
   greater than or equal to MAX_PATH_METRIC shall be considered to have the values 0-32 and indicate the
   number
   a metric of significant bits in the prefix.  The prefix MAX_PATH_METRIC.  It is encoded in easiest to select MAX_PATH_METRIC
   such that MAX_PATH_METRIC plus a single link metric does not overflow
   the minimal number of bytes bits for the given number of significant internal metric calculation.  We assume that
   this is 32 bits.
   This implies:

           Significant bits                Bytes
           0                               0
           1-8                             1
           9-16                            2
           17-24                           3
           25-32                           4

   The remaining bits of prefix are transmitted as zero and ignored upon
   receipt.  Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000,
   2^32 - 2^25).

   If an IP prefix a link is advertised with a the maximum link metric larger then
   MAX_PATH_METRIC (0xFE000000, see below), (2^24 - 1), this IP prefix
   link should not be considered during the normal SPF computation.
   This will allow
   advertisment advertisement of an IP prefix a link for other purposes than
   building the normal IP routing table.

5.0 The extended IS reachability TLV

   The extended IS reachability TLV is TLV type 22.

   The existing IS reachability TLV Shortest Path Tree. An example is a single TLV link that contains
   information about a series is
   available for traffic engineering, but not for hop-by-hop routing.

   Certain sub-TLVs are proposed here:
       Sub-TLV type   Length (octets)  Name
           3               4           Administrative group (color)
           6               4           IPv4 interface address
           8               4           IPv4 neighbor address
           9               4           Maximum link bandwidth
           10              4           Reservable link bandwidth
           11              32          Unreserved bandwidth
           18              3           TE Default metric
           250-254                     Reserved for cisco specific extensions
           255                         Reserved for future expansion

   Each of IS neighbors.  For each neighbor, there these sub-TLVs is a structure that contains the default metric, the delay, the
   monetary cost, the reliability, and the 7-octet ID described below.  Unless stated otherwise,
   multiple occurrences of the adjacent
   neighbor.  Of this information, information are supported by multiple
   inclusions of the default metric is commonly used. sub-TLV.


4.1 Sub-TLV 3: Administrative group (color, resource class)


   The default metric is currently one octet, with one administrative group sub-TLV contains a 4-octet bit used mask assigned
   by the network administrator.  Each set bit corresponds to one
   administrative group assigned to
   indicate that the metric interface.

   By convention the least significant bit is present referred to as 'group 0',
   and one the most significant bit used is referred to indicate as 'group 31'.





Expiration Date December 1999 2001                           [Page 4]





INTERNET DRAFT                                                 June 1999

   whether 2001


4.2 Sub-TLV 6: IPv4 interface address


   This sub-TLV contains a 4-octet IPv4 address for the metric is internal or external.  The remaining 6 bits are
   used to store interface
   described by the actual metric, resulting a possible metric range of
   0-63.  This limitation is one of (main) TLV.  This sub-TLV can occur multiple times.

   Implementations MUST NOT inject a /32 prefix for the restrictions that we would like interface
   address into their routing or forwarding table, because this can lead
   to lift.

   The remaining three metrics (delay, monetary cost, and reliability)
   are forwarding loops when interacting with systems that do not commonly implemented and reflect unused overhead in support
   this sub-TLV.

   If a router implements the TLV.
   The neighbor basic TLV extensions in this document, it
   is identified by its system Id (typically 6-octets),
   plus one octet free to add or omit this sub-TLV to indicate the pseudonode number if the description of an
   adjacency.  If a router implements traffic engineering, it must
   include this sub-TLV.


4.3 Sub-TLV 8: IPv4 neighbor is
   on address


   This sub-TLV contains a LAN interface.  Thus, the existing TLV consumes 11 octets per
   neighbor, with 4 octets single IPv4 address for metric and 7 octets a neighboring router
   on this link.  This sub-TLV can occur multiple times.

   Implementations MUST NOT inject a /32 prefix for the neighbor
   identification.  To indicate multiple adjacencies, address
   into their routing or forwarding table, because this structure is
   repeated within the IS reachability TLV.  Because can lead to
   forwarding loops when interacting with systems that do not support
   this sub-TLV.

   If a router implements the basic TLV extensions in this document, it
   is limited free to 255 octets add or omit this sub-TLV to the description of content, an
   adjacency.  If a single TLV can describe up to 23
   neighbors.  The IS reachability TLV router implements traffic engineering, it must
   include this sub-TLV on point-to-point adjacencies.


4.4 Sub-TLV 9: Maximum link bandwidth


   This sub-TLV contains the maximum bandwidth that can be repeated within used on this
   link in this direction (from the system originating the LSP
   fragments to describe further neighbors. its
   neighbors). This is useful for traffic engineering.

   The proposed extended IS reachability TLV contains a new data
   structure, consisting of
           7 octets of system Id and pseudonode number
           3 octets of default metric
           1 octet of length of sub-TLVs
           0-244 octets of sub-TLVs

   Thus, if no sub-TLVs maximum link bandwidth is encoded in 32 bits in IEEE floating
   point format. The units are used, bytes (not bits!) per second.








Expiration Date December 2001                           [Page 5]





INTERNET DRAFT                                                 June 2001


4.5 Sub-TLV 10: Maximum reservable link bandwidth


   This sub-TLV contains the new encoding requires 11 octets
   and maximum amount of bandwidth that can contain up to 23 neighbors.  Please note be
   reserved in this direction on this link.  Note that while the
   encoding allows for 255 octets of sub-TLVs,
   oversubscription purposes, this can be greater than the maximum value cannot
   fit in bandwidth of
   the overall IS reachability TLV. link.
   The practical maximum reservable link bandwidth is 255
   octets minus encoded in 32 bits in IEEE
   floating point format. The units are bytes (not bits!) per second.


4.6 Sub-TLV 11: Unreserved bandwidth


   This sub-TLV contains the 11 octets described above, or 244 octets.  Further,
   there is no defined mechanism amount of bandwidth reservable on this
   direction on this link.  Note that for extending oversubscription purposes,
   this can be greater than the sub-TLV space bandwidth of the link.

   Because of the need for a
   particular neighbor.  Thus, wasting sub-TLV space is discouraged.

   The metric octets are encoded as a priority and preemption, each head end needs
   to know the amount of reserved bandwidth at each priority level.
   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 bandwidth that can be reserved with a setup priority 0 through 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.

   For stability reasons, rapid changes in the values in this sub-TLV
   should not cause rapid generation of LSPs.


4.7 Sub-TLV 18: Traffic Engineering Default metric


   This sub-TLV contains a 24-bit unsigned integer.  This metric is
   administratively assigned and can be used to present a differently
   weighted topology to traffic engineering SPF calculations.

   To preclude overflow within an SPF implementation, all metrics
   greater than or equal to MAX_PATH_METRIC shall be considered to have
   a metric of MAX_PATH_METRIC.  It is easiest to select MAX_PATH_METRIC
   such that MAX_PATH_METRIC plus a single link metric does not overflow
   the number of bits for internal metric calculation.  We assume that
   this is 32 bits.  Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000,
   2^32 - 2^25).

   If a link is advertised with without this sub-TLV, traffic engineering SPF
   calculations must use the maximum link normal default metric (2^24 - 1), of this
   link should not be considered during link, which
   is advertised in the normal SPF computation.
   This will allow advertisment fixed part of a link for other purposes than
   building the normal Shortest Path Tree. An example is a link that is
   available for traffic engineering, but not for hop-by-hop routing.

   Certain sub-TLVs are proposed here: extended IS reachability TLV.



Expiration Date December 1999 2001                           [Page 5] 6]





INTERNET DRAFT                                                 June 1999

           Sub-TLV 2001




5.0 The extended IP reachability TLV


   The extended IP reachability TLV is TLV type    Length (octets) Name
           3               4               Administrative group (color)
           6               4               IPv4 interface address
           8               4               IPv4 135.
   The existing IP reachability TLVs (TLV type 128 and TLV type 130,
   defined in RFC 1195 [3]) carry IP prefixes in a format that is
   analogous to the IS neighbor address
           9               4               Maximum link bandwidth
           10              4               Reservable link bandwidth
           11              32              Unreserved bandwidth
           18              3               TE Default metric
           250-254                         Reserved for cisco specific
extensions
           255                             Reserved for future expansion

   Each TLV from ISO 10589 [2].  They carry four
   metrics, of these sub-TLVs which only the default metric is described below.  Unless stated otherwise,
   multiple occurrences of commonly used.  Of this,
   the information are supported by multiple
   inclusions default metric has a possible range of 0-63.  This limitation is
   one of the sub-TLV.

5.1 Sub-TLV 3: Administrative group (color, resource class)

   The administrative group sub-TLV contains restrictions that we would like to lift.

   In addition, route redistribution (a.k.a. route leaking) has a 4-octet bit mask assigned key
   problem that was not fully addressed by the network administrator.  Each set bit corresponds to one
   administrative group assigned existing IP reachability
   TLVs. RFC 1195 [3] allows a router to advertise prefixes upwards in
   the interface.

   By convention the least significant bit is referred level hierarchy. Unfortunately there were no mechanisms defined
   to as 'group 0',
   and advertise prefixes downwards in the most significant bit is referred to as 'group 31'.

5.2 Sub-TLV 6: IPv4 interface address

   This sub-TLV contains a 4-octet IPv4 level hierarchy.

   To address for the interface
   described by these two issues, the (main) TLV.  This sub-TLV can occur multiple times.

   Implementations MUST NOT inject a /32 prefix proposed extended IP reachability
   TLV provides for the interface
   address into their routing or forwarding table, because this can lead a 32 bit metric and adds one bit to forwarding loops when interacting with systems indicate that do not support
   this sub-TLV.

   If a router implements
   prefix has been redistributed 'down' in the basic hierarchy.

   The proposed extended IP reachability TLV extensions in this document, it
   is free to add or omit this contains a new data
   structure, consisting of:
        4 octets of metric information
        1 octet of control information, consisting of
             1 bit of up/down information
             1 bit indicating the existence of sub-TLVs
             6 bits of prefix length
        0-4 octet of IPv4 prefix
        0-250 optional octets of sub-TVLs, if present consisting of
             1 octet of length of sub-TLVs
             0-249 octets of sub-TLVs,
                  where each sub-TLV consists of a sequence of
                       1 octet of sub-type
                       1 octet of length
                       0-247 octets of value

   This data structure can be replicated within the TLV, not to exceed
   the description maximum length of an
   adjacency.  If a router implements traffic engineering, it must
   include this sub-TLV. the TLV.










Expiration Date December 1999 2001                           [Page 6] 7]





INTERNET DRAFT                                                 June 1999

5.3 Sub-TLV 8: IPv4 neighbor address 2001



   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
   the minimal number of octets for the given number of significant
   bits.  This sub-TLV contains implies:

           Significant bits                Octets
           0                               0
           1-8                             1
           9-16                            2
           17-24                           3
           25-32                           4

   The remaining bits of prefix are transmitted as zero and ignored upon
   receipt.

   If a single IPv4 address for prefix is advertised with a neighboring router
   on metric larger then MAX_PATH_METRIC
   (0xFE000000, see paragraph 4.0), this link. prefix should not be considered
   during the normal SPF computation. This sub-TLV can occur multiple times.

   Implementations MUST NOT inject will allow advertisement of a /32
   prefix for other purposes than building the neighbor address
   into their normal IP routing or forwarding table, because this can lead table.


5.1 The up/down bit


   Without any additional mechanisms, if routers were allowed to
   forwarding loops when interacting with systems that do
   redistribute IP prefixes freely in both directions between level 1
   and level 2, those routers can not support
   this sub-TLV.

   If determine looping of routing
   information.  A problem occurs when a router implements learns an prefix via
   level 2 routing and advertises that prefix down into a level 1 area,
   where another router might pick up the basic TLV extensions in this document, it route and advertise the prefix
   back up into the level 2 backbone.  If the original source withdraws
   the prefix, those two routers might end up having a routing 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.  The
   solution that RFC 1195 [3] poses is free to add or omit this sub-TLV allow only advertising
   prefixes upward in the level hierarchy, and to disallow the description
   advertising of an
   adjacency.  If a router implements traffic engineering, it must
   include this sub-TLV on point-to-point adjacencies.

5.4 Sub-TLV 9: Maximum link bandwidth

   This sub-TLV contains prefixes downward in the maximum bandwidth that can be used on hierarchy.

   To prevent this
   link looping of prefixes between levels, a new bit of
   information is defined in this direction (from the system originating the LSP to its
   neighbors). new extended IP reachability TLV.  This
   bit is useful for traffic engineering. called the up/down bit.  The maximum link bandwidth up/down bit shall be set to 0
   when a prefix is encoded in 32 bits in IEEE floating
   point format. The units are bytes (not bits!) per second.

5.5 Sub-TLV 10: Maximum reservable link bandwidth

   This sub-TLV contains first injected into IS-IS.  If a prefix is
   advertised from a higher level to a lower level (e.g. level two to
   level one), the maximum amount of bandwidth that can bit shall be
   reserved in this direction on this link.  Note set to 1, to indicate that for
   oversubscription purposes, this can be greater than the bandwidth of prefix
   has traveled down the link.

   The maximum reservable link bandwidth hierarchy.  Prefixes that have the up/down bit
   set to 1 may only be advertised down the hierarchy, i.e. to lower
   levels.



Expiration Date December 2001                           [Page 8]





INTERNET DRAFT                                                 June 2001


   These semantics apply even if IS-IS is encoded in 32 bits extended in IEEE
   floating point format. The units the future to have
   additional levels.  By insuring that prefixes follow only the IS-IS
   hierarchy, we have insured that the information does not loop,
   thereby insuring that there are bytes (not bits!) per second.

5.6 Sub-TLV 11: Unreserved bandwidth no persistent forwarding loops.

   If a prefix is advertised from an area to another area at the same
   level, then the up/down bit shall be set to 1. This sub-TLV contains situation can
   arise when a router implements multiple virtual routers at the amount same
   level, but in different areas.

   The semantics of bandwidth reservable on this
   direction on this link.  Note that for oversubscription purposes,
   this can be greater than the bandwidth up/down bit in the new extended IP reachability
   TLV are identical to the semantics of the link.

   Because up/down bit defined in
   RFC 2966 [4].


5.2 Expandability of the need for priority and preemption, each head end needs

Expiration Date December 1999                                   [Page 7]

INTERNET DRAFT                                                 June 1999 extended IP reachability TLV with sub-TLVs


   The extended IP reachability TLV can hold sub-TLVs that apply to know a
   particular prefix. This allows for easy future extensions.  If there
   are no sub-TLVs associated with a prefix, the amount bit indicating the
   presence of reserved bandwidth at each priority level.
   Thus, sub-TLVs shall be set to 0.  If this sub-TLV contains eight 32 bit IEEE floating point numbers.
   The units are bytes (not bits!) per second.  The values correspond is set to 1, the bandwidth that can
   first octet after the prefix will be reserved with a holding of priority 0
   through 7, arranged in increasing order with priority 0 occurring at interpreted as the start length of
   sub-TLVs. Please note that while the sub-TLV, and priority 7 at the end encoding allows for 255 octets
   of sub-TLVs, the sub-TLV.

   For stability reasons, rapid changes maximum value cannot fit in the values in this sub-TLV
   should overall extended IP
   reachability TLV. The practical maximum is 255 octets minus the 5-9
   octets described above, or 250 octets.

   This document does not cause rapid generation of LSPs.

5.7 Sub-TLV 18: define any sub-TLVs yet for the extended IP
   reachability TLV.


6.0 The Traffic Engineering Default metric

   This sub-TLV router ID TLV


   The Traffic Engineering router ID TLV is TLV type 134.

   The router ID TLV contains the 4-octet router ID of the router
   originating the LSP.  This is useful in several regards:

   For traffic engineering, it guarantees that we have a 24-bit unsigned integer.  This metric is
   administratively assigned and single stable
   address that can always be used to present referenced in a differently
   weighted topology to traffic engineering SPF calculations.

   To preclude overflow within an SPF implementation, all metrics
   greater than or equal to MAX_PATH_METRIC shall path that will be considered to have
   a metric
   reachable from multiple hops away, regardless of MAX_PATH_METRIC.  It is easiest to select MAX_PATH_METRIC
   such that MAX_PATH_METRIC plus a single link metric does not overflow the number state of bits for internal metric calculation.  We assume that
   this is 32 bits.  Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000,
   2^32 - 2^25). the
   node's interfaces.

   If a link OSPF is advertised without this sub-TLV, also active in the domain, traffic engineering SPF
   calculations must use can compute
   the normal default metric of this link, which
   is advertised in mapping between the fixed part of OSPF and IS-IS topologies.




Expiration Date December 2001                           [Page 9]





INTERNET DRAFT                                                 June 2001


   If a router advertises the Traffic Engineering router ID TLV 22.

6.0 in its
   LSP, and if it advertises BGP routes 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 BGP router ID.

   Implementations MUST NOT inject a /32 prefix for the router ID into
   their forwarding table, because this can lead to forwarding loops
   when interacting with systems that do not support this TLV.


7.0 Security Considerations

   This document raises no new security issues for IS-IS.

7.0


8.0 Acknowledgments

   The authors would like to thank Yakov Rekhter and Dave Katz for their
   comments on this work.

8.0


9.0 References

   [1] draft-ietf-mpls-traffic-eng-00.txt, RFC 2702, "Requirements for Traffic Engineering Over MPLS", MPLS," D.
   Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, work in progress.

Expiration Date December 1999                                   [Page 8]

INTERNET DRAFT                                                 June 1999 September
   1999.

   [2] ISO 10589, "Intermediate System to Intermediate System Intra-
   Domain Routeing Exchange Protocol for use in Conjunction with the
   Protocol for Providing the Connectionless-mode Network Service (ISO
   8473)" [Also republished as RFC 1142]

   [3] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual
   environments", R.W. Callon, Dec. December 1990

9.0

   [4] RFC 2966, "Domain-wide Prefix Distribution with Two-Level IS-IS",
   T. Li, T. Przygienda, H. Smit, October 2000.














Expiration Date December 2001                           [Page 10]





INTERNET DRAFT                                                 June 2001


10.0 Authors' Addresses

   Henk Smit
   Cisco Systems, Inc.
   210 West Tasman Drive
   San Jose, CA 95134
   Email: hsmit@cisco.com
   Voice: +31 20 342 3736

   Tony Li
   Juniper
   Procket Networks, Inc.
   385 Ravendale Dr.
   Mountain View,
   1100 Cadillac Court
   Milpitas, CA 94043 95035
   Email: tli@juniper.net tli@procket.com
   Voice: +1 408 6357900
   Fax: +1 650 526 8001 408 6356166

   Henk Smit
   Procket Networks, Inc.
   1100 Cadillac Court
   Milpitas, CA 95035
   Email: henk@procket.com
   Voice: +1 650 526 8006 408 6357900
   Fax: +1 408 6356166


































Expiration Date December 1999 2001                          [Page 9] 11]


----