< draft-ietf-isis-ip-interoperable-01.txt   draft-ietf-isis-ip-interoperable-02.txt >
Internet Engineering Task Force J. Parker, Editor Internet Engineering Task Force J. Parker, Editor
INTERNET DRAFT Axiowave Networks Axiowave Networks
Expiration Date: April 2004
September 20, 2003 December 9, 2003
Recommendations for Interoperable IP Networks using IS-IS Recommendations for Interoperable IP Networks using IS-IS
<draft-ietf-isis-ip-interoperable-01.txt> <draft-ietf-isis-ip-interoperable-02.txt>
1. Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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
skipping to change at page 2, line 5 skipping to change at page 2, line 5
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.
Copyright Notice Copyright (C) The Internet Society (2003). All Copyright Notice Copyright (C) The Internet Society (2003). All
Rights Reserved. Rights Reserved.
2. Abstract Abstract
The difference between theory and practice is greater in
practice than it is in theory.
Apologies to Jan L.A. van de Snepscheut
This document discusses a number of differences between the IS-IS This document discusses a number of differences between the
protocol used to route IP traffic as described in RFC 1195 and the IS-IS protocol used to route IP traffic as described in RFC
protocol as it is deployed today. These differences are discussed as 1195 and the protocol as it is deployed today. These
a service to those implementing, testing, and deploying the IS-IS differences are discussed as a service to those implementing,
Protocol to route IP traffic. A companion document describes the testing, and deploying the IS-IS Protocol to route IP traffic.
differences between the protocol described in ISO 10589 and current A companion document describes the differences between the
practice. protocol described in ISO 10589 and current practice.
3. Table of Contents Table of Contents
1. Status of this Memo.................................. 1 1. Introduction......................................... 2
2. Abstract............................................. 2 2. Acknowledgments...................................... 3
3. Table of Contents.................................... 2 3. Unused Features...................................... 3
4. Overview............................................. 2 4. Overload Bit......................................... 4
5. Acknowledgments...................................... 3 5. Migration from Narrow Metrics to Wide................ 5
6. Unused Features...................................... 3 6. Intermediate System Hello (ISH) PDU.................. 7
7. Overload Bit......................................... 4 7. Attached Bit......................................... 8
8. Migration from Narrow Metrics to Wide................ 5 8. Default Route........................................ 8
9. Intermediate System Hello (ISH) PDU.................. 7 9. Non-homogeneous Protocol Networks.................... 9
10. Attached Bit......................................... 8 10. Adjacency Creation and IP Interface Addressing....... 9
11. Default Route........................................ 8 11. Security Considerations............................. 10
12. Non-homogeneous Protocol Networks.................... 9 12. Normative References................................. 10
13. Adjacency Creation and IP Interface Addressing....... 9 13. Informative References............................... 11
14. Security Considerations............................. 10 14. Author's Address.................................... 11
15. Normative References................................. 10 15. Full Copyright Statement............................. 11
16. Informative References............................... 11
17. Author's Address.................................... 11
18. Full Copyright Statement............................. 11
4. Overview 1. Overview
Interior Gateway Protocols such as IS-IS are designed to provide Interior Gateway Protocols such as IS-IS are designed to provide
timely information about the best routes in a routing domain. The timely information about the best routes in a routing domain. The
original design of IS-IS, as described in ISO 10589 [1] has proved to original design of IS-IS, as described in ISO 10589 [1] has proved to
be quite durable. However, a number of original design choices have be quite durable. However, a number of original design choices have
been modified. This document describes some of the differences been modified. This document describes some of the differences
between the protocol as described in RFC 1195 [2] and the protocol between the protocol as described in RFC 1195 [2] and the protocol
that can be observed on the wire today. A companion document that can be observed on the wire today. A companion document
describes the differences between the protocol described in ISO 10589 describes the differences between the protocol described in ISO 10589
and current practice. and current practice.
5. Acknowledgments The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in
this document are to be interpreted as described in RFC 2119 [3].
2. Acknowledgments
This document is the work of many people, and is the distillation of This document is the work of many people, and is the distillation of
over a thousand mail messages. Thanks to Vishwas Manral, who pushed over a thousand mail messages. Thanks to Vishwas Manral, who pushed
to create such a document. Thanks to Danny McPherson, the original to create such a document. Thanks to Danny McPherson, the original
editor, for kicking things off. Thanks to Mike Shand, for his work editor, for kicking things off. Thanks to Mike Shand, for his work
in creating the protocol, and his uncanny ability to remember what in creating the protocol, and his uncanny ability to remember what
everything is for. Thanks to Micah Bartell and Philip Christian, who everything is for. Thanks to Micah Bartell and Philip Christian, who
showed us how to document difference without displaying discord. showed us how to document difference without displaying discord.
Thanks to Les Ginsberg, Neal Castagnoli, Jeff Learman, and Dave Katz, Thanks to Les Ginsberg, Neal Castagnoli, Jeff Learman, and Dave Katz,
who spent many hours educating the editor. Thanks to Radia Perlman, who spent many hours educating the editor. Thanks to Radia Perlman,
skipping to change at page 3, line 30 skipping to change at page 3, line 29
White, whose writing improved the treatment of every topic he White, whose writing improved the treatment of every topic he
touched. Thanks to Shankar Vemulapalli, who read several drafts with touched. Thanks to Shankar Vemulapalli, who read several drafts with
close attention. Thanks to Don Goodspeed, for his close reading of close attention. Thanks to Don Goodspeed, for his close reading of
the text. Thanks to Michael Coyle for identifying the quotation from the text. Thanks to Michael Coyle for identifying the quotation from
Jan L.A. van de Snepscheut. Thanks for Alex Zinin's ministrations Jan L.A. van de Snepscheut. Thanks for Alex Zinin's ministrations
behind the scenes. Thanks to Tony Li and Tony Przygienda, who kept behind the scenes. Thanks to Tony Li and Tony Przygienda, who kept
us on track as the discussions veered into the weeds. And thanks to us on track as the discussions veered into the weeds. And thanks to
all those who have contributed, but whose names I have carelessly all those who have contributed, but whose names I have carelessly
left from this list. left from this list.
6. Unused Features 3. Unused Features
Some features defined in RFC 1195 are not in current use. Some features defined in RFC 1195 are not in current use.
6.1 Inter-Domain Routing Protocol Information TLV, Code 131 3.1 Inter-Domain Routing Protocol Information TLV, Code 131
RFC 1195 defines an Inter-Domain Routing Protocol Information TLV, RFC 1195 defines an Inter-Domain Routing Protocol Information TLV,
with code 131, designed to convey information transparently between with code 131, designed to convey information transparently between
boundary routers. TLV 131 is not used, and MUST be ignored if boundary routers. TLV 131 is not used, and MUST be ignored if
received. received.
6.2 Authentication TLV, Code 133 3.2 Authentication TLV, Code 133
RFC 1195 defines an authentication TLV, code 133, which contains RFC 1195 defines an authentication TLV, code 133, which contains
information used to authenticate the PDU. This TLV has been replaced information used to authenticate the PDU. This TLV has been replaced
by TLV 10, described in "IS-IS Cryptographic Authentication" [3]. by TLV 10, described in "IS-IS Cryptographic Authentication" [4].
TLV 133 is not used, and MUST be ignored. TLV 133 is not used, and MUST be ignored.
7. Overload Bit 4. Overload Bit
To deal with transient problems that prevent an IS from storing all To deal with transient problems that prevent an IS from storing all
the LSPs it receives, ISO 10589 defines an LSP Database Overload the LSPs it receives, ISO 10589 defines an LSP Database Overload
condition in section 7.3.19. When an IS is in Database Overload condition in section 7.3.19. When an IS is in Database Overload
condition, it sets a flag called the Overload Bit in the non- condition, it sets a flag called the Overload Bit in the non-
pseudonode LSP number Zero that it generates. Section 7.2.8.1 of ISO pseudonode LSP number Zero that it generates. Section 7.2.8.1 of ISO
10589 instructs other systems not to use the overloaded IS as a 10589 instructs other systems not to use the overloaded IS as a
transit router. Since the overloaded IS does not have complete transit router. Since the overloaded IS does not have complete
information, it may not be able to compute the right routes, and information, it may not be able to compute the right routes, and
routing loops could develop. However, an overloaded router may be routing loops could develop. However, an overloaded router may be
used to reach End Systems directly attached to the router, as it may used to reach End Systems directly attached to the router, as it may
provide the only path to an End System. provide the only path to an End System.
The ability to signal reduced knowledge is so useful that the meaning The ability to signal reduced knowledge is so useful that the meaning
of this flag has been overloaded. In a Service Provider's network, of this flag has been overloaded. In a Service Provider's network,
when a router running BGP and IS-IS reboots, BGP might take more time when a router running BGP and IS-IS reboots, BGP might take more time
to converge than IS-IS. Thus the router may drop traffic for to converge than IS-IS. Thus the router may drop traffic for
destinations not yet learned via BGP. It is convenient to set the destinations not yet learned via BGP. It is convenient to set the
Overload Bit until BGP has converged, as described in "Intermediate Overload Bit until BGP has converged, as described in "Intermediate
System to Intermediate System (IS-IS) Transient Blackhole Avoidance" System to Intermediate System (IS-IS) Transient Blackhole Avoidance"
[5]. [6].
An implementation SHOULD use the Overload Bit to signal that it is An implementation SHOULD use the Overload Bit to signal that it is
not ready to accept transit traffic. not ready to accept transit traffic.
An implementation SHOULD not set the Overload bit in PseudoNode LSPs An implementation SHOULD not set the Overload bit in PseudoNode LSPs
that it generates, and Overload bits seen in PseudoNode LSPs SHOULD that it generates, and Overload bits seen in PseudoNode LSPs SHOULD
be ignored. This is also discussed in the companion document on ISO be ignored. This is also discussed in the companion document on ISO
interoperability. interoperability.
RFC 1195 makes clear when describing the SPF algorithm for IP routers RFC 1195 makes clear when describing the SPF algorithm for IP routers
skipping to change at page 5, line 5 skipping to change at page 5, line 5
When processing LSPs received from a router which has the Overload When processing LSPs received from a router which has the Overload
bit set in LSP number Zero, the receiving router SHOULD treat all IP bit set in LSP number Zero, the receiving router SHOULD treat all IP
reachability advertisements as directly connected and use them in its reachability advertisements as directly connected and use them in its
SPF computation. SPF computation.
Since the IP prefixes that an overloaded router announces will be Since the IP prefixes that an overloaded router announces will be
treated as directly attached, an overloaded router SHOULD take care treated as directly attached, an overloaded router SHOULD take care
in selecting which routes to advertise in the LSPs it generates. in selecting which routes to advertise in the LSPs it generates.
8. Migration from Narrow Metrics to Wide 5. Migration from Narrow Metrics to Wide
The IS-Neighbors TLV (TLV 2) as defined in ISO 10589 and the IP The IS-Neighbors TLV (TLV 2) as defined in ISO 10589 and the IP
Reachability TLV (TLV 128/TLV 130) as defined in RFC 1195 provide a 6 Reachability TLV (TLV 128/TLV 130) as defined in RFC 1195 provide a 6
bit metric for the default link metric to the listed neighbor. This bit metric for the default link metric to the listed neighbor. This
metric has proved too limited. The Extended IS-Neighbors TLV (TLV metric has proved too limited. The Extended IS-Neighbors TLV (TLV
22) and the Extended IP Reachability TLV (TLV 135) are defined in 22) and the Extended IP Reachability TLV (TLV 135) are defined in
"IS-IS extensions for Traffic Engineering" [4]. The Extended IS- "IS-IS extensions for Traffic Engineering" [5]. The Extended IS-
Neighbors TLV (TLV 22) defines a 24 bit metric, and the Extended IP Neighbors TLV (TLV 22) defines a 24 bit metric, and the Extended IP
Reachability TLV (TLV 135) defines a 32 bit metric for IP Networks Reachability TLV (TLV 135) defines a 32 bit metric for IP Networks
and Hosts. and Hosts.
If not all devices in the IS-IS domain support wide metrics, narrow If not all devices in the IS-IS domain support wide metrics, narrow
metrics MUST continue to be used. Once all devices in the network are metrics MUST continue to be used. Once all devices in the network are
able to support the new TLVs containing wide metrics, the network can able to support the new TLVs containing wide metrics, the network can
be migrated to the new metric style, though care must be taken to be migrated to the new metric style, though care must be taken to
avoid routing loops. avoid routing loops.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
have the same preference. As defined in "Domain-wide Prefix Distri- have the same preference. As defined in "Domain-wide Prefix Distri-
bution with Two-Level IS-IS", the Most Significant Bit on an L1 bution with Two-Level IS-IS", the Most Significant Bit on an L1
metric tells us if the route has been leaked down, but does not metric tells us if the route has been leaked down, but does not
change the distance. Thus we will ignore the MSBit. change the distance. Thus we will ignore the MSBit.
We interpret the default metric as an 7 bit quantity. Metrics with We interpret the default metric as an 7 bit quantity. Metrics with
the external bit set are interpreted as metrics in the range the external bit set are interpreted as metrics in the range
[64..127]. Metrics with the external bit clear are interpreted as [64..127]. Metrics with the external bit clear are interpreted as
metrics in the range [0..63]. metrics in the range [0..63].
8.1 Transition Algorithm 5.1 Transition Algorithm
To facilitate a smooth transition between the use of narrow metrics To facilitate a smooth transition between the use of narrow metrics
exclusively to the use of wide metrics exclusively, the following exclusively to the use of wide metrics exclusively, the following
steps must be taken, in the order below. steps must be taken, in the order below.
(1) All routers advertise Narrow Metrics as defined in ISO 10589, (1) All routers advertise Narrow Metrics as defined in ISO 10589,
and consider narrow metrics only in their SPF computation. and consider narrow metrics only in their SPF computation.
(2) Each system is configured in turn to send wide metrics as well (2) Each system is configured in turn to send wide metrics as well
as narrow metrics. The two metrics for the same link or IP as narrow metrics. The two metrics for the same link or IP
skipping to change at page 6, line 29 skipping to change at page 6, line 29
changes necessary on each system to consider Wide Metrics dur- changes necessary on each system to consider Wide Metrics dur-
ing the SPF, and change MaxPathMetric to 0xFE000000. ing the SPF, and change MaxPathMetric to 0xFE000000.
(4) Each system is configured in turn to stop advertising narrow (4) Each system is configured in turn to stop advertising narrow
metrics. metrics.
(5) When the network is only using wide metrics, metrics on indi- (5) When the network is only using wide metrics, metrics on indi-
vidual links may be rescaled to take advantage of the larger vidual links may be rescaled to take advantage of the larger
metric. metric.
8.2 Dealing with Non-Equal Metrics 5.2 Dealing with Non-Equal Metrics
The algorithm above assumes that the metrics are equal, and thus The algorithm above assumes that the metrics are equal, and thus
needs to make no assumption about which metric the SPF algorithm needs to make no assumption about which metric the SPF algorithm
uses. This section describes the changes that should be made to the uses. This section describes the changes that should be made to the
SPF algorithm when both Narrow and Wide metric styles should be con- SPF algorithm when both Narrow and Wide metric styles should be con-
sidered. Using a common algorithm allows different implementations to sidered. Using a common algorithm allows different implementations to
compute the same distances independently, even if the wide and narrow compute the same distances independently, even if the wide and narrow
metrics do not agree. metrics do not agree.
The standard SPF algorithm proceeds by comparing sums of link costs The standard SPF algorithm proceeds by comparing sums of link costs
skipping to change at page 7, line 29 skipping to change at page 7, line 29
If multiple styles of metric for the link are defined, the If multiple styles of metric for the link are defined, the
cost will be the minimum available cost for the circuit. cost will be the minimum available cost for the circuit.
In C.2.6 Step 1 of the description of the SPF algorithm, section a) In C.2.6 Step 1 of the description of the SPF algorithm, section a)
dist(P,N) = d(P) + metric(P,N) dist(P,N) = d(P) + metric(P,N)
If multiple styles of metric for the neighbor are defined, the If multiple styles of metric for the neighbor are defined, the
cost will be the minimum available cost for the circuit. cost will be the minimum available cost for the circuit.
9. Intermediate System Hello (ISH) PDU 6. Intermediate System Hello (ISH) PDU
The original intent of RFC 1195 was to provide a routing protocol The original intent of RFC 1195 was to provide a routing protocol
capable of handling both CLNS and IPv4 reachability information. To capable of handling both CLNS and IPv4 reachability information. To
allow CLNS Endstations (ES) to know that they are attached to a allow CLNS Endstations (ES) to know that they are attached to a
router, Intermediate Systems are required to send Intermediate System router, Intermediate Systems are required to send Intermediate System
Hello PDUs (ISH) for End Stations when a point-to-point circuit comes Hello PDUs (ISH) for End Stations when a point-to-point circuit comes
up. Furthermore, an IS is not allowed to send Intermediate System to up. Furthermore, an IS is not allowed to send Intermediate System to
Intermediate System Hello PDUs (IIH) before receiving an ISH from a Intermediate System Hello PDUs (IIH) before receiving an ISH from a
peer. This reduces routing protocol traffic on links with a single peer. This reduces routing protocol traffic on links with a single
IS. IS.
skipping to change at page 8, line 28 skipping to change at page 8, line 28
An IP Only implementation may issue an IIH PDU when a point to point An IP Only implementation may issue an IIH PDU when a point to point
circuit transitions into an "Up" state to initiate the formation of circuit transitions into an "Up" state to initiate the formation of
an IS-IS adjacency, without sending an ISH PDU. However, this may an IS-IS adjacency, without sending an ISH PDU. However, this may
not inter-operate with implementations which require an ISH for adja- not inter-operate with implementations which require an ISH for adja-
cency formation. cency formation.
An IS may issue an IIH PDU in response to the receipt of an IIH PDU An IS may issue an IIH PDU in response to the receipt of an IIH PDU
in accordance with section 8.2.5.2 ISO 10589, even though it has not in accordance with section 8.2.5.2 ISO 10589, even though it has not
received an ISH PDU. received an ISH PDU.
10. The Attached Bit 7. The Attached Bit
In section 7.2.9.2 of ISO 10589, an algorithm is described to deter- In section 7.2.9.2 of ISO 10589, an algorithm is described to deter-
mining when the attachedFlag should be set on an intermediate system. mining when the attachedFlag should be set on an intermediate system.
Some implementations also allow the attachedFlag to be set on Inter- Some implementations also allow the attachedFlag to be set on Inter-
mediate Systems routing IP traffic when there is a default route in mediate Systems routing IP traffic when there is a default route in
the local routing table, or when some other state is reached that the local routing table, or when some other state is reached that
implies a connection to the rest of the network. implies a connection to the rest of the network.
11. Default Route 8. Default Route
RFC 1195 states in section 1.3: RFC 1195 states in section 1.3:
Default routes are permitted only at level 2 as external Default routes are permitted only at level 2 as external
routes (i.e., included in the "IP External Reachability Infor- routes (i.e., included in the "IP External Reachability Infor-
mation" field, as explained in sections 3 and 5). Default mation" field, as explained in sections 3 and 5). Default
routes are not permitted at level 1. routes are not permitted at level 1.
Because of the utility of the default route when dealing with other Because of the utility of the default route when dealing with other
routing protocols and the ability to influence the exit point from an routing protocols and the ability to influence the exit point from an
area, an implementation MAY generate default routes in Level 1. area, an implementation MAY generate default routes in Level 1.
12. Non-homogeneous Protocol Networks 9. Non-homogeneous Protocol Networks
RFC 1195 assumes that every deployment of IS-IS routers will sup- RFC 1195 assumes that every deployment of IS-IS routers will sup-
port a homogeneous set of protocols. It anticipates OSI only, IP port a homogeneous set of protocols. It anticipates OSI only, IP
only, or dual OSI and IP routers. While it allows mixed areas with, only, or dual OSI and IP routers. While it allows mixed areas with,
for example, both pure IP and Dual IP and OSI routers, it allows only for example, both pure IP and Dual IP and OSI routers, it allows only
IP traffic in such domains, and OSI traffic only when pure OSI and IP traffic in such domains, and OSI traffic only when pure OSI and
Dual IP and OSI routers are present. Thus it provides only lowest Dual IP and OSI routers are present. Thus it provides only lowest
common denominator routing. common denominator routing.
RFC 1195 also requires the inclusion of the Protocol Supported TLV RFC 1195 also requires the inclusion of the Protocol Supported TLV
skipping to change at page 9, line 37 skipping to change at page 9, line 37
The ITU-T requires that SONET/SDH equipment running the IS-IS proto- The ITU-T requires that SONET/SDH equipment running the IS-IS proto-
col must not form an adjacency with a neighbour unless they share at col must not form an adjacency with a neighbour unless they share at
least one network layer protocol in common. Unless this feature is least one network layer protocol in common. Unless this feature is
present in every IS in the SONET or SDH DCN network the network may present in every IS in the SONET or SDH DCN network the network may
not function correctly. Implementors MAY include this feature if they not function correctly. Implementors MAY include this feature if they
wish to ensure interoperability with SONET and SDH DCN networks. wish to ensure interoperability with SONET and SDH DCN networks.
Definition of an interoperable strategy for resolving the problems Definition of an interoperable strategy for resolving the problems
that arise in non-homogeneous protocol networks remains incomplete. that arise in non-homogeneous protocol networks remains incomplete.
Members of the ITU are actively working on a proposal: see "Architec- Members of the ITU are actively working on a proposal: see "Architec-
ture and Specification of Data Communication Network", [6]. ture and Specification of Data Communication Network", [7].
13. Adjacency Creation and IP Interface Addressing 10. Adjacency Creation and IP Interface Addressing
RFC 1195 states that adjacencies are formed without regard to IP RFC 1195 states that adjacencies are formed without regard to IP
interface addressing. However, many current implementations refuse interface addressing. However, many current implementations refuse
adjacencies based on interface addresses and related issues. adjacencies based on interface addresses and related issues.
In section 4.2, RFC 1195 requires routers with IP interface addresses In section 4.2, RFC 1195 requires routers with IP interface addresses
to advertise the addresses in an IP Interface Address TLV (132) car- to advertise the addresses in an IP Interface Address TLV (132) car-
ried in IIH PDUs. Some implementations will not interoperate with a ried in IIH PDUs. Some implementations will not interoperate with a
neighbor router that does not include the IP Interface Address TLV. neighbor router that does not include the IP Interface Address TLV.
Further, some implementations will not form an adjacency on broadcast Further, some implementations will not form an adjacency on broadcast
skipping to change at page 10, line 29 skipping to change at page 10, line 29
IP subnetwork. This means that care must be taken in assigning IP IP subnetwork. This means that care must be taken in assigning IP
interface addresses in all networks. interface addresses in all networks.
For an implementation to interoperate in a such mixed environment, it For an implementation to interoperate in a such mixed environment, it
MUST include an IP Interface address (TLV 132) in its IIH PDUs. The MUST include an IP Interface address (TLV 132) in its IIH PDUs. The
network administrator should ensure that there is a common IP subnet network administrator should ensure that there is a common IP subnet
assigned to links with numbered interfaces, and that all routers on assigned to links with numbered interfaces, and that all routers on
each link have a IP Interface Addresses belonging to the assigned each link have a IP Interface Addresses belonging to the assigned
subnet. subnet.
14. Security Considerations 11. Security Considerations
The clarifications in this document do not raise any new security The clarifications in this document do not raise any new security
concerns, as there is no change in the underlying protocol described concerns, as there is no change in the underlying protocol described
in ISO 10589 [1] and RFC 1195 [2]. in ISO 10589 [1] and RFC 1195 [2].
The document does make clear that TLV 133 has been deprecated and The document does make clear that TLV 133 has been deprecated and
replaced with TLV 10. replaced with TLV 10.
15. Normative References 12. Normative References
[1] ISO, "Intermediate system to Intermediate system routeing informa- [1] ISO, "Intermediate system to Intermediate system routeing informa-
tion exchange protocol for use in conjunction with the Protocol for tion exchange protocol for use in conjunction with the Protocol for
providing the Connectionless-mode Network Service (ISO 8473)," providing the Connectionless-mode Network Service (ISO 8473),"
ISO/IEC 10589:2002. ISO/IEC 10589:2002.
[2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, [2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195,
December 1990. December 1990.
[3] Li, T., Atkinson, R. J., "IS-IS Cryptographic Authentication", RFC [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Li, T., Atkinson, R. J., "IS-IS Cryptographic Authentication", RFC
3567 July 2003. 3567 July 2003.
[4] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", [5] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering",
draft-ietf-isis-traffic-05.txt, August 2003. draft-ietf-isis-traffic-05.txt, August 2003.
[5] August 2001. McPherson, D., "Intermediate System to Intermediate [6] August 2001. McPherson, D., "Intermediate System to Intermediate
System (IS-IS) Transient Blackhole Avoidance", RFC 3277, April System (IS-IS) Transient Blackhole Avoidance", RFC 3277, April
2002. 2002.
16. Informative References 13. Informative References
[6] ITU, "Architecture and Specification of Data Communication Net- [7] ITU, "Architecture and Specification of Data Communication Net-
work", ITU-T Recommendation G.7712/Y.1703, November 2001 work", ITU-T Recommendation G.7712/Y.1703, November 2001
17. Author's Addresses 14. Author's Address
Jeff Parker Jeff Parker
Axiowave Networks Axiowave Networks
200 Nickerson Road 200 Nickerson Road
Marlborough, Mass 01752 Marlborough, Mass 01752
USA USA
e-mail: jparker@axiowave.com e-mail: jparker@axiowave.com
18. Full Copyright Statement 15. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
 End of changes. 35 change blocks. 
64 lines changed or deleted 61 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/