Internet Engineering Task Force J. Parker, Editor
INTERNET DRAFT Axiowave Networks
Expiration Date: April 2003
Nov. 1, 2002
Recommendations for Interoperable Networks using IS-IS
<draft-ietf-isis-iso-interoperable-00.txt>
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Copyright Notice Copyright (C) The Internet Society (2000). All
Rights Reserved.
Parker Expires April 2003 [Page 1]
Internet Draft - draft-ietf-isis-iso-interoperable Sept. 2002
2. Abstract
In theory, there is no difference between theory and practice.
But in practice, there is.
Jan L.A. van de Snepscheut
This document discusses a number of differences between the IS-IS
protocol as described in ISO 10589 [1] the protocol as it is deployed
today. These differences are discussed as a service to those
implementing, testing, and deploying the IS-IS Protocol. A companion
document discusses differences between the protocol described in RFC
1195 [3] for routing IP traffic.
3. Table of Contents
1. Status of this Memo.................................. 1
2. Abstract............................................. 2
3. Table of Contents.................................... 2
4. Overview............................................. 2
5. Acknowledgments...................................... 3
6. Constants That Are Variable.......................... 3
7. Variables That Are Constant.......................... 5
8. Alternative Metrics.................................. 6
9. ReceiveLSPBufferSize................................. 7
10. Padding Hello PDUs................................... 9
11. Zero Checksum........................................ 10
12. Purging Corrupted LSPs............................... 10
13. Checking System ID in Received point-to-point IIH PDUs 11
14. Doppelganger LSPs.................................... 12
15. Security Implications................................ 12
16. References........................................... 12
17. Author's Address.................................... 13
18. Full Copyright Statement............................. 13
4. Overview
Interior Gateway Protocols such as IS-IS are designed to provide
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
be quite durable. However, a number of original design choices have
been modified. This document addresses differences between the
protocol described in ISO 10589 and the protocol that can be observed
on the wire today. A companion document discusses differences between
the protocol described in RFC 1195 [3] for routing IP traffic and
current practice.
Parker Expires April 2003 [Page 2]
Internet Draft - draft-ietf-isis-iso-interoperable Sept. 2002
5. Acknowledgments
This document is the work of many people, and is the distilation of
over a thousand mail messages. Thanks to Vishwas Manral, who pushed
to create such a document. Thanks to Danny McPherson, the original
editor, for kicking things off. Thanks to Mike Shand, for his work
in creating the protocol, and his uncanny ability to remember what
everything is for. Thanks to Micah Bartell and Philip Christian, who
showed us how to document difference without displaying discord.
Thanks to Les Ginsberg, Neal Castagnoli, Jeff Learman, and Dave Katz,
who spent many hours educating the editor. Thanks to Radia Perlman,
who is always ready to explain anything. Thanks to Satish Dattatri,
who was tenacious in seeing things written up correctly. Thanks to
Russ White, whose writing improved the treatment of every topic he
touched. Thanks to Shankar Vemulapalli, who read several drafts with
close attention. Thanks to Don Goodspeed, for his close reading of
the text. Thanks to Aravind Ravikumar, who pointed out that we should
check Source ID on point-to-point IIH packets. Thanks to Michael
Coyle for identifying the quotation from Jan L.A. van de Snepscheut.
Thanks for Alex Zinin's ministrations 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 all those who have contributed,
but whose names I have carelessly left from this list.
6. Constants That Are Variable
Some parameters that were defined as constant in ISO 10589 are
modified in practice. These include the following
(1) MaxAge - the lifetime of a Link State PDU (LSP)
(2) ISISHoldingMultiplier - a parameter used to describe the
generation of hello packets
(3) ReceiveLSPBufferSize - discussed in a later section
6.1 MaxAge
Each LSP contains a RemainingLifetime field which is initially set to
the MaxAge value on the generating IS. The value stored in this field
is decremented to mark the passage of time and the number of times it
has been forwarded. When the value of a foreign LSP becomes 0, an IS
initiates a aging and purging process which will flush the LSP from
the network. This ensures that that corrupted or otherwise invalid
LSPs do not remain in the network indefinitely. The rate at which
LSPs are regenerated by the originating IS is determined by the value
of maximumLSPGenerationInterval.
Parker Expires April 2003 [Page 3]
Internet Draft - draft-ietf-isis-iso-interoperable Sept. 2002
MaxAge is defined in ISO 10589 as an Architectural constant of 20
minutes, and it is recommended that maximumLSPGenerationInterval be
set to 15 minutes. These times have proven to be too short in some
networks, as they result in a steady flow of LSP updates even when
nothing is changing. To reduce the rate of generation, some implemen-
tations allow these times to be set by the network operator.
The relation between MaxAge and maximumLSPGenerationInterval is dis-
cussed in section 7.3.21 of ISO 10589. If MaxAge is smaller than max-
imumLSPGenerationInterval, then an LSP will expire before it is
replaced. Further, as RemainingLifetime is decremented each time it
is forwarded, an LSP far from it's origin appears older and is
removed sooner. To make sure that an LSP survives long enough to be
replaced, MaxAge should exceed maximumLSPGenerationInterval by at
least ZeroAgeLifetime + minimumLSPTransmissionInterval. The first
term, ZeroAgeLifetime, is an estimate of how long it takes to flood
an LSP through the network. The second term, minimumLSPTransmis-
sionInterval, takes into account how long a router might delay before
sending an LSP. The original recommendation was that MaxAge be at
least 5 minutes larger than maximumLSPGenerationInterval, and that
recommendation is still valid today.
An implementation MAY use a value of MaxAge that is greater than 1200
seconds. MaxAge SHOULD exceed maximumLSPGenerationInterval by at
least 300 seconds. An implementation SHOULD NOT use it's value of
MaxAge to discard LSPs from peers, as discussed below.
An implementation is not required to coordinate the RemainingLifetime
it assigns to LSPs to the RemainingLifetime values it accepts, and
MUST ignore the following sentence from section 7.3.16.3. of ISO
10589.
"If the value of Remaining Lifetime [of the received LSP] is
greater than MaxAge, the LSP shall be processed as if there
were a checksum error."
6.2 ISISHoldingMultiplier
An IS sends IS to IS Hello Protocol Data Units (IIHs) on a periodic
basis over active circuits, allowing other attached routers to moni-
tor their aliveness. The IIH includes a two byte field called the
Holding Time which defines the time to live of an adjacency. If an IS
does not receive a hello from an adjacent IS within this holding
time, the adjacent IS is assumed to be no longer operational, and the
adjacency is removed.
ISO 10589 defines ISISHoldingMultiplier to be 10, and states that the
value of Holding Time should be ISISHoldingMultiplier multiplied by
Parker Expires April 2003 [Page 4]
Internet Draft - draft-ietf-isis-iso-interoperable Sept. 2002
iSISHelloTimer for ordinary systems, and dRISISHelloTimer for a DIS.
This implies that the neighbor must lose 10 IIHs before an adjacency
times out.
In practice, a value of 10 for the ISISHoldingMultiplier has proven
to be too large. DECnet PhaseV defined two related values. The vari-
able holdingMultiplier, with a default value of 3, was used for
point-to-point IIHs, while the variable ISISHoldingMultiplier, with a
default value of 10, was used for LAN IIHs. Most implementations
today set the default ISISHoldingMultiplier to 3 for both circuit
types.
Note that adjacent systems may use different values for Holding Time
and will form an adjacency with non-symmetric hold times.
An implementation MAY allow ISISHoldingMultiplier to be configurable.
Values lower than 3 are unstable, and may cause adjacencies to flap.
7. Variables That Are Constant
Some values that were defined as variables in ISO 10589 do not vary
in practice. These include
(1) ID Length - the length of the SystemID
(2) maximumAreaAddresses
(3) Protocol Version
7.1 ID Length
The ID Length is a field carried in all PDUs. The ID Length defines
the length of the System ID, and is allowed to take values from 0 to
8. A value of 0 is interpreted to define a length of 6 bytes. As
suggested in B.1.1.3 of [1], it is easy to use an Ethernet MAC
address to generate a unique 6 byte System ID. Since the SystemID
only has significance within the IGP Domain, 6 bytes has proved to be
easy to use and ample in practice. Moreover, new IS-IS TLVs such as
the Traffic Engineering TLVs, assume a 6 byte System ID, so choices
other than 6 are difficult to support today. Implementations may
interoperate without being able to deal with System IDs of any length
other than 6.
An implementation MUST use an ID Length of 6, and MUST check the ID
Length defined in the IS-IS PDUs it receives. If a router encounters
a PDU with an ID Length different from 0 or 6, section 7.3.15.a.2
dictates that it MUST discard the PDU, and SHOULD generate an
Parker Expires April 2003 [Page 5]
Internet Draft - draft-ietf-isis-iso-interoperable Sept. 2002
appropriate notification. ISO 10589 defines the notification
iDFieldLengthMismatch, while the IS-IS MIB [5] defines the notifica-
tion isisIDLenMismatch.
7.2 maximumAreaAddresses
The value of maximumAreaAddresses is defined to be an integer between
1 and 254, and defines the number of synonymous Area Addresses that
can be in use in an L1 area. This value is advertised in the header
of each IS-IS PDU.
Most deployed networks use one Area Address for an L1 area. When
merging or splitting areas, a second address is required for seamless
transition. The third area address was originally required to sup-
port DECnet PhaseIV addresses as well as OSI addresses during a tran-
sition.
ISO 10589 requires that all Intermediate Systems in an area or domain
use a consistent value for maximumAreaAddresses. Common practice is
for an implementation to use the value 3. Therefore an implementation
that only supports 3 can expect to interoperate successfully with
other conformant systems.
ISO 10589 specifies that an advertised value of 0 is treated as
equivalent to 3, and that checking the value for consistency may be
omitted if an implementation only supports the value 3.
An implementation SHOULD use the value 3, and it SHOULD check the
value advertised in IS-IS PDUs it receives. If a router receives a
PDU with maximumAreaAddresses that is not 0 or 3, it MUST discard the
PDU, as described in section 7.3.15.a.3, and it SHOULD generate an
appropriate match. ISO 10589 defines the notification maximumAreaAd-
dressMismatch, while the IS-IS MIB [5] defines the notification
isisMaxAreaAddressesMismatch.
7.3 Protocol Version
IS-IS PDUs include two one-byte fields in the headers:
"Version/Protocol ID Extension" and "Version".
An implementation SHOULD set both fields to 1, and it SHOULD check
the values of these fields in IS-IS PDUs it receives. If a router
receives a PDU with a value other than 1 for either field, it MUST
drop the packet, and SHOULD generate a the isisVersionSkew notifica-
tion.
Parker Expires April 2003 [Page 6]
Internet Draft - draft-ietf-isis-iso-interoperable Sept. 2002
8. Alternative Metrics
Section 7.2.2, ISO 10589 describes four metrics: Default Metric,
Delay Metric, Expense Metric, and Error Metric. None but the Default
Metric are used in deployed networks, and most implementations only
consider the Default Metric. In ISO 10589, the most significant bit
of the 8 bit metrics was the field S (Supported), used to define if
the metric was meaningful.
If this IS does not support this metric it shall set bit S to
1 to indicate that the metric is unsupported.
The Supported bit was always 0 for the Default Metric, which must
always be supported. However, RFC 2966 [6] uses this bit in the
Default Metric to mark L1 routes that have been leaked from L1 to L2
and back down into L1 again.
Implementations MUST generate the Default Metric when using narrow
metrics, and SHOULD ignore the other three metrics when using narrow
metrics. Implementations MUST assume that the Default Metric is sup-
ported, even if the S bit is set. RFC 2966 describes restrictions on
leaking such routes learned from L1 into L2.
9. ReceiveLSPBufferSize
Since IS-IS does not allow segmentation of protocol PDUs, Link State
PDUs (LSPs) must be propagated without modification on all IS-IS
enabled links throughout the area/domain. Thus it is essential to
configure a maximum size that all routers can forward, receive, and
store.
This affects three aspects, which we discuss in turn:
(1) The largest LSP we can receive (ReceiveLSPBufferSize)
(2) The size of the largest LSP we can generate
(originatingL1LSPBufferSize and originatingL2LSPBufferSize)
(3) Available Link MTU for supported Circuits (MTU). Note this
often differs from the MTU available to IP clients.
ISO 10589 defines the architectural constant ReceiveLSPBufferSize
with value 1492 bytes, and two private management parameters,
originatingL1LSPBufferSize for level 1 PDUs and
originatingL2LSPBufferSize for level 2 PDUs. The originating buffer
size parameters define the maximum size of an LSP that a router can
generate. ISO 10589 directs the implementor to treat a PDU larger
Parker Expires April 2003 [Page 7]
Internet Draft - draft-ietf-isis-iso-interoperable Sept. 2002
than ReceiveLSPBufferSize as an error.
It is crucial that
originatingL1LSPBufferSize <= ReceiveLSPBufferSize
originatingL2LSPBufferSize <= ReceiveLSPBufferSize
and that for all L1 links in the area
originatingL1LSPBufferSize <= MTU
and for all L2 links in the domain
originatingL2LSPBufferSize <= MTU
The original thought was that operators could decrease the originat-
ing Buffer size when dealing with smaller MTUs, but would not need to
increase ReceiveLSPBufferSize beyond 1492.
With the definition of new information to be advertised in LSPs, such
as the Traffic Engineering TLVs, the limited space of the LSP data-
base which may be generated by each router (256 * 1492 bytes at each
level) has become an issue. Given that modern networks with MTUs
larger than 1492 on all links are not uncommon, one method which can
be used to expand the LSP database size is to allow values of
ReceiveLSPBufferSize greater than 1492.
Allowing ReceiveLSPBUfferSize to become a configurable parameter
rather than an architectural constant must be done with care: if any
system in the network does not support values larger than 1492 or one
or more link MTUs used by IS-IS anywhere in the area/domain is
smaller than the largest LSP which may be generated by any router,
then full propagation of all LSPs may not be possible, resulting in
routing loops and black holes.
The steps below are recommended when changing ReceiveLSPBufferSize.
(1) Set the ReceiveLSPBufferSize to a consistent value throughout
the network.
(2) The implementation MUST not enable IS-IS on circuits which do
not support an MTU at least as large as the originating Buf-
ferSize at the appropriate level.
(3) Include an originatingLSPBufferSize TLV when generating LSPs,
as described in section 9.8 of the 2001 revision of ISO 10589
[2].
(4) When receiving LSPs, check for an originatingLSPBufferSize
TLV, and report the receipt of values larger than the local
value of ReceiveLSPBufferSize through the defined Notifica-
tions and Alarms.
Parker Expires April 2003 [Page 8]
Internet Draft - draft-ietf-isis-iso-interoperable Sept. 2002
(5) Report the receipt of a PDU larger than the local ReceiveL-
SPBufferSize through the defined Notifications and Alarms.
(6) Do not discard large PDUs by default. Storing and processing
them as normal PDUs may help maintain coherence in a miscon-
figured network.
Steps 1 and 2 are enough by themselves, but the consequences of
mismatch are serious enough and difficult enough to detect, that
steps 3-6 are recommended to help track down and correct problems.
10. Padding Hello PDUs
To prevent the establishment of adjacencies between systems which may
not be able to successfully receive and propagate IS-IS PDUs due to
inconsistent settings for originatingLSPBufferSize and ReceiveLSPBuf-
ferSize, section 8.2.3 of [1] requires padding on point-to-point
links.
On point-to-point links, the initial IIH is to be padded to the max-
imum of
(1) Link MTU
(2) originatingL1LSPBufferSize if the link is to be used for L1
traffic
(3) originatingL2LSPBufferSize if the link is to be used for L2
traffic
In section 6.7.2 e) ISO 10589 assumes
Provision that failure to deliver a specific subnetwork SDU
will result in the timely disconnexion of the subnetwork con-
nection in both directions and that this failure will be
reported to both systems
With this service provided by the link layer, the requirement that
only the initial IIH be padded was sufficient to check the con-
sistency of the MTU on the two sides. If the PDU was too big to be
received, the link would be reset. However, link layer protocols in
use on point-to-point circuits today often lack this service, and the
initial padded PDU might be silently dropped without resetting the
circuit. Therefore, the requirement that only the initial IIH be
padded does not provide the guarantees anticipated in ISO 10589.
Parker Expires April 2003 [Page 9]
Internet Draft - draft-ietf-isis-iso-interoperable Sept. 2002
If an implementation is using padding to detect problems, point-to-
point IIH PDUs SHOULD be padded until the sender declares an adja-
cency on the link to be in state Up. If the implementation implements
RFC 3373 [4], "Three-Way Handshake for IS-IS Point-to-Point Adjacen-
cies" then this is when the three-way state is Up: if the implementa-
tion use the "classic" algorithm described in ISO 10589, this is when
adjacencyState is Up. Transmission of padded IIH PDUs SHOULD be
resumed whenever the adjacency is torn down, and SHOULD continue
until the sender declares the adjacency to be in state Up again.
If an implementation is using padding, and originatingL1LSPBUfferSize
or originatingL2LSPBUfferSize is modified, adjacencies SHOULD be
brought down and reestablished so the protection provided by padding
IIH PDUs is performed consistent with the modified values.
Some implementations choose not to pad. Padding does not solve all
problems of misconfigured systems. In particular, it does not pro-
vide a transitive relation. Assume that A, B, and C all pad IIH
PDUs, that A and B can establish an adjacency, and that B and C can
establish an adjacency. We still cannot conclude that A and C could
establish an adjacency, if they were neighbors.
The presence or absence of padding TLVs MUST NOT be one of the accep-
tance tests applied to a received IIH regardless of the state of the
adjacency.
11. Zero Checksum
A checksum of 0 is impossible if the checksum is computed according
to the rules of ISO 8473 [8].
ISO 10589, section 7.3.14.2(i), states:
A Link State PDU received with a zero checksum shall be
treated as if the Remaining Lifetime were zero. The age, if
not zero, shall be overwritten with zero.
That is, ISO 10589 directs the receiver to purge the LSP. This has
proved to be disruptive in practice. An implementation SHOULD treat
all LSPs with a zero checksum and a non-zero remaining lifetime as if
they had as checksum error. Such packets SHOULD be discarded.
12. Purging Corrupted PDUs
While ISO 10589 requires in section 7.3.14.2 e) that any LSP received
with an invalid PDU checksum should be purged, this has been found to
Parker Expires April 2003 [Page 10]
Internet Draft - draft-ietf-isis-iso-interoperable Sept. 2002
be disruptive. Most implementations today follow the revised specif-
ication, and simply drop the LSP.
In ISO 10589:2001 [2], Section 7.3.14.2, it states:
(e) An Intermediate system receiving a Link State PDU with an
incorrect LSP Checksum or with an invalid PDU syntax SHOULD
1) generate a corruptedLSPReceived circuit event,
2) discard the PDU.
13. Checking System ID in Received point-to-point IIH PDUs
In section 8.2.4.2, ISO 10589 does not explicitly require comparison
of the source ID of a received IIH with the neighbourSystemID associ-
ated with an existing adjacency on a point-to-point link.
To address this omission, implementations receiving an IIH PDU on a
point to point circuit with an established adjacency SHOULD check the
Source ID field and compare that with the neighbourSystemID of the
adjacency. If these differ, an implementation SHOULD delete the adja-
cency.
Given that IIH PDUs as specified in ISO 10589 do not include a check-
sum, it is possible that a corrupted IIH may falsely indicate a
change in the neighbor's System ID. The required subnetwork guaran-
tees for point-to-point links, as described in 6.7.2 g) 1) assume
that undetected corrupted PDUs are very rare (one event per four
years). A link with frequent errors that produce corrupted data could
lead to flapping an adjacency. Inclusion of an optional checksum TLV
as specified in "Optional Checksums in ISIS" [7], may be used to
detect such corruption. Hello packets carrying this TLV that are
corrupted PDUs SHOULD be silently dropped, rather than dropping the
adjacency.
Some implementations have chosen to discard received IIHs where the
source ID differs from the neighbourSystemID. This may prevent need-
less flapping caused by undetected PDU corruption. If an actual
administrative change to the neighbor's system ID has occurred, using
this strategy may require the existing adjacency to timeout before an
adjacency with the new neighbor can be established. This is
expedited if the neighbor resets the circuit as anticipated in 10589
after a System ID change, or resets the 3-way adjacency state, as
anticipated in RFC 3373.
Parker Expires April 2003 [Page 11]
Internet Draft - draft-ietf-isis-iso-interoperable Sept. 2002
14. Doppelganger LSPs
When an Intermediate System shuts down, it may leave old LSPs in the
network. In the normal course of events, a rebooting system flushes
out these old LSPs by reissuing those fragments with a higher
sequence number, or by purging fragments that it is not currently
generating.
In the case where a received LSP or SNP entry and an LSP in the local
database have the same LSP ID, same sequence number, non-zero remain-
ing lifetimes, but different non-zero checksums, the rules defined in
[1] cannot determine which of the two is "newer". In this case, an
implementation may opt to perform an additional test as a tie breaker
by comparing the checksums. Implementations that elect to use this
method MUST consider the LSP/SNP entry with the higher checksum as
newer. When comparing the checksums the checksum field is treated as
a 16 bit unsigned integer in network byte order (i.e., most signifi-
cant byte first).
The choice of higher checksum, rather than lower, while arbitrary,
aligns with existing implementations and ensures compatibility.
Note that a purged LSP (i.e. an LSP with remaining lifetime set to 0
and/or a zero checksum) is always considered newer than a non-purged
copy of the same LSP.
15. Security Implications
The clarifications in this document do not raise any new security
concerns, as there is no change in the underlying protocol described
in ISO 10589 [1].
16. References
[1] ISO, "Intermediate system to Intermediate system routeing informa-
tion exchange protocol for use in conjunction with the Protocol for
providing the Connectionless-mode Network Service (ISO 8473),"
ISO/IEC 10589:1992.
[2] ISO, "Intermediate system to Intermediate system routeing informa-
tion exchange protocol for use in conjunction with the Protocol for
providing the Connectionless-mode Network Service (ISO 8473),"
ISO/IEC 10589:2001.
[3] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195,
Parker Expires April 2003 [Page 12]
Internet Draft - draft-ietf-isis-iso-interoperable Sept. 2002
December 1990.
[4] Katz, D. and Saluja, R., " Three-Way Handshake for Intermediate
System to Intermediate System (IS-IS) Point-to-Point Adjacencies"
RFC 3373, September 2002.
[5] Parker, J., "Management Information Base for IS-IS", draft-ietf-
isis-wg-mib-08.txt, May 2002.
[6] Li, T., Przygienda, T., "Domain-wide Prefix Distribution with Two-
Level IS-IS", RFC 2966, October 2000.
[7] Przygienda, T., "Optional Checksums in ISIS", draft-ietf-isis-wg-
snp-checksum-03.txt, April 2002.
[8] ITU, "Information technology - Protocol for providing the
connectionless-mode network service", ISO/IEC 8473-1, 1998
17. Author's Addresses
Jeff Parker
Axiowave Networks
200 Nickerson Road
Marlborough, Mass 01752
USA
e-mail: jparker@axiowave.com
18. Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
Parker Expires April 2003 [Page 13]
Internet Draft - draft-ietf-isis-iso-interoperable Sept. 2002
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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 MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Parker Expires April 2003 [Page 14]
