complete set of CSNPs to assure consistent LSP Databases throughout.
Section 7.3.15.3 of [1] defines a complete set of CSNPs to be:
"A complete set of CSNPs is a set whose Start LSPID and End
LSPID ranges cover the complete possible range of LSPIDs.
(i.e., there is no possible LSPID value which does not appear
within the range of one of the CSNPs in the set). "
Strict adherence to this definition is required to ensure the
reliability of the update process. Deviation can lead to subtle and
hard to detect defects. It is not sufficient to send a set of CSNPs
which merely cover the range of LSPIDs which are in the local
database. The set of CSNPs must cover the complete possible range of
LSPIDs.
Consider the following example:
If the current Level 1 LSP database on a router consists of the
following non pseudo-node LSPs:
From system 1111.1111.1111 LSPs numbered 0-89(59H)
From system 2222.2222.2222 LSPs numbered 0-89(59H)
If the maximum size of a CSNP is 1492 bytes, then 90 CSNP entries can
fit into a single CSNP PDU. The following set of CSNP start/end
LSPIDs constitute a correctly formatted complete set:
Start LSPID End LSPID
0000.0000.0000.00-00 1111.1111.1111.00-59
1111.1111.1111.00-5A FFFF.FFFF.FFFF.FF-FF
The following are examples of incomplete sets of CSNPS:
Start LSPID End LSPID
0000.0000.0000.00-00 1111.1111.1111.00-59
1111.1111.1111.00-5A 2222.2222.2222.00-59
The sequence above has a gap after the second entry.
Start LSPID End LSPID
0000.0000.0000.00-00 1111.1111.1111.00-59
2222.2222.2222.00-00 FFFF.FFFF.FFFF.FF-FF
The sequence above has a gap between the first and second entry.
Although it is legal to send a CSNP which contains no actual LSP
entry TLVs, it should never be necessary to do so in order to conform
to the specification.
12. Overload Bit
To deal with transient problems that prevent an IS from storing all
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, 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
10589 instructs other systems not to use the overloaded IS as a
transit router. Since the overloaded IS does not have complete
information, it may not be able to compute the right routes, and
routing loops could develop.
An overloaded router might become the DIS. An implementation SHOULD
not set the Overload bit in PseudoNode LSPs that it generates, and
Overload bits seen in PseudoNode LSPs SHOULD be ignored.
13. Security Considerations
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].
14. References
14.1. Normative References
[1] ISO, "Intermediate system to Intermediate system routeing
information exchange protocol for use in conjunction with the
Protocol for providing the Connectionless-mode Network Service
(ISO 8473)," ISO/IEC 10589:2002.
[2] Callon, R., "OSI IS-IS for IP and Dual Environment", RFC 1195,
December 1990.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[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] Li, T., Przygienda, T. and H. Smit, "Domain-wide Prefix
Distribution with Two-Level IS-IS", RFC 2966, October 2000.
[6] Koodli, R. and R. Ravikanth, "Optional Checksums in Intermediate
System to Intermediate System (ISIS)", RFC 3358, August 2002.
14.2. Informative References
[7] Parker, J., "Management Information Base for IS-IS", Work in
Progress, January 2004.
[8] ITU, "Information technology - Protocol for providing the
connectionless-mode network service", ISO/IEC 8473-1, 1998.
15. Acknowledgments
This document is the work of many people, and is the distillation 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.
16. Author’s Address
Jeff Parker
Axiowave Networks
200 Nickerson Road
Marlborough, Mass 01752
USA
EMail: jparker@axiowave.com
17. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.