summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6823.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6823.txt')
-rw-r--r--doc/rfc/rfc6823.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc6823.txt b/doc/rfc/rfc6823.txt
new file mode 100644
index 0000000..3a3a4c8
--- /dev/null
+++ b/doc/rfc/rfc6823.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) L. Ginsberg
+Request for Comments: 6823 S. Previdi
+Category: Standards Track M. Shand
+ISSN: 2070-1721 Cisco Systems
+ December 2010
+
+
+ Advertising Generic Information in IS-IS
+
+Abstract
+
+ This document describes the manner in which generic application
+ information (i.e., information not directly related to the operation
+ of the Intermediate System to Intermediate System (IS-IS) protocol)
+ should be advertised in IS-IS Link State Protocol Data Units (LSPs)
+ and defines guidelines that should be used when flooding such
+ information.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6823.
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+Ginsberg, et al. Standards Track [Page 1]
+
+RFC 6823 Advertising Generic Information in IS-IS December 2010
+
+
+Table of Contents
+
+ 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
+ 3. Encoding Format for GENINFO . . . . . . . . . . . . . . . . . 3
+ 3.1. GENINFO TLV . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3.2. Use of Sub-TLVs in GENINFO TLV . . . . . . . . . . . . . . 5
+ 4. GENINFO Flooding Procedures . . . . . . . . . . . . . . . . . 5
+ 4.1. Leaking Procedures . . . . . . . . . . . . . . . . . . . . 6
+ 4.2. Minimizing Update Confusion . . . . . . . . . . . . . . . 7
+ 4.3. Interpreting Attribute Information . . . . . . . . . . . . 7
+ 5. Use of a Separate Protocol Instance . . . . . . . . . . . . . 7
+ 6. Applicability of GENINFO TLV . . . . . . . . . . . . . . . . . 8
+ 7. Standardization Requirements . . . . . . . . . . . . . . . . . 8
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
+ 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
+ 11. Normative References . . . . . . . . . . . . . . . . . . . . . 10
+
+1. Overview
+
+ [ISO10589] defines the format of Type-Length-Values (TLVs) that may
+ be sent in IS-IS Protocol Data Units (PDUs). The first octet of a
+ TLV encodes the "type" or "codepoint" that provides a scope for the
+ information and information format that follows. The protocol is
+ therefore limited to 256 different codepoints that may be assigned.
+ This number has proved generous as regards the information required
+ for correct operation of the IS-IS protocol. However, the increasing
+ use of IS-IS Link State Protocol Data Units (LSPs) for advertisement
+ of generic information (GENINFO) not directly related to the
+ operation of the IS-IS protocol places additional demands on the TLV
+ encoding space that have the potential to consume a significant
+ number of TLV codepoints. This document therefore defines an
+ encoding format for GENINFO that minimizes the consumption of TLV
+ codepoints and also maximizes the flexibility of the formats that can
+ be used to represent GENINFO.
+
+ This document also discusses optimal behavior associated with the
+ advertisement and flooding of LSPs containing GENINFO in order to
+ avoid the advertisement of stale information and minimize the
+ presence of duplicate or conflicting information when advertisements
+ are updated.
+
+ The manner in which the information contained in GENINFO TLVs is
+ exchanged between an instance of the IS-IS protocol and the
+ application that generates or consumes the GENINFO is outside the
+ scope of this specification.
+
+
+
+
+Ginsberg, et al. Standards Track [Page 2]
+
+RFC 6823 Advertising Generic Information in IS-IS December 2010
+
+
+ In order to minimize the impact that advertisement of GENINFO may
+ have on the operation of routing, such advertisements MUST occur in
+ the context of a non-zero instance of the IS-IS protocol as defined
+ in [RFC6822] except where the rules for the use of the zero instance
+ set out later in this document are followed.
+
+2. Conventions Used in This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+3. Encoding Format for GENINFO
+
+ The encoding format defined below has the following goals regarding
+ the advertisement of GENINFO in IS-IS LSPs:
+
+ o Minimize the number of IS-IS top level and sub-TLV codepoints
+ required
+
+ o Minimize the depth of sub-TLV levels required
+
+ In order to support these goals, a new IANA registry has been
+ created. This registry manages the assignment of IS-IS GENINFO
+ Application Identifiers. These numbers are unsigned 16-bit numbers
+ ranging in value from 1 to 65535. Application-specific sub-TLV
+ codepoints are unsigned 8-bit numbers ranging in value from 0 to 255.
+ The assignment of the sub-TLV codepoints is scoped by the Application
+ Identifier. Management of the application specific sub-TLV
+ codepoints is outside the scope of this document.
+
+3.1. GENINFO TLV
+
+ The GENINFO TLV supports the advertisement of application-specific
+ information that is not directly related to the operation of the
+ IS-IS protocol.
+
+ Type: 251
+ Length: Number of octets in the value field (3 to 255)
+
+
+
+
+
+
+
+
+
+
+
+
+Ginsberg, et al. Standards Track [Page 3]
+
+RFC 6823 Advertising Generic Information in IS-IS December 2010
+
+
+ Value:
+
+ No. of octets
+ +-----------------------+
+ | Flags | 1
+ +-----------------------+
+ | Application ID | 2
+ +-----------------------+
+ | Application |
+ | IP Address Info | 0 to 20
+ +-----------------------+
+ |Additional Application-| 0 to (252 -
+ | Specific Information | len of IP Address info)
+ +-----------------------+
+
+
+ Flags
+
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | Rsvd |V|I|D|S|
+ +-+-+-+-+-+-+-+-+
+
+ The following bit flags are defined.
+
+ S bit (0x01): If the S bit is set (1), the GENINFO TLV MUST be
+ flooded across the entire routing domain. If the S bit is not set
+ (0), the TLV MUST NOT be leaked between levels. This bit MUST NOT
+ be altered during the TLV leaking.
+
+ D bit (0x02): When the GENINFO TLV is leaked from Level-2 to
+ Level-1, the D bit MUST be set. Otherwise, this bit MUST be
+ clear. GENINFO TLVs with the D bit set MUST NOT be leaked from
+ Level-1 to Level-2. This is to prevent TLV looping.
+
+ I bit (0x04): When the I bit is set, the 4-octet IPv4 address
+ associated with the application immediately follows the
+ Application ID.
+
+ V bit (0x08): When the V bit is set, the 16-octet IPv6 address
+ associated with the application immediately follows either the
+ Application ID (if I bit is clear) or the IPv4 address (if I bit
+ is set).
+
+ Application ID
+ An identifier assigned to this application via the IANA registry
+ defined later in this document.
+
+
+
+
+Ginsberg, et al. Standards Track [Page 4]
+
+RFC 6823 Advertising Generic Information in IS-IS December 2010
+
+
+ Application IPv4 Address Info
+ The IPv4 address associated with the application. This is not
+ necessarily an address of a router running the IS-IS protocol.
+
+ Application IPv6 Address Info
+ The IPv6 address associated with the application. This is not
+ necessarily an address of a router running the IS-IS protocol.
+
+ Additional Application-Specific Information
+ Each application may define additional information to be encoded
+ in a GENINFO TLV following the fixed information. Definition of
+ such information is beyond the scope of this document.
+
+3.2. Use of Sub-TLVs in GENINFO TLV
+
+ [RFC5305] introduced the definition and use of sub-TLVs. One of the
+ advantages of using sub-TLVs rather than fixed encoding of
+ information inside a TLV is to allow for the addition of new
+ information in a backwards compatible manner, i.e., just as with
+ TLVs, implementations are required to ignore sub-TLVs that they do
+ not understand.
+
+ GENINFO TLVs MAY include sub-TLVs in the application specific
+ information as deemed necessary and appropriate for each application.
+ The scope of the codepoints used in such sub-TLVs is defined by the
+ combination of the GENINFO TLV codepoint and the Application ID,
+ i.e., the sub-TLV codepoints are private to the application. Such
+ sub-TLVs are referred to as APPsub-TLVs.
+
+ Additional levels of APPsub-TLVs may be required when there is
+ variable information that is scoped by a specific APPsub-TLV. These
+ "nested" sub-TLVs MUST be encoded in the same manner as sub-TLVs,
+ i.e., with a one-octet Type field, a one-octet Length field, and zero
+ or more octets of Value.
+
+4. GENINFO Flooding Procedures
+
+ This section describes procedures that apply to the propagation of
+ LSPs that contain GENINFO TLVs. These procedures have been
+ previously discussed in [RFC4971]. This section is intended to serve
+ as a reference specification for future documents that define the use
+ of GENINFO TLV(s) for a specific application -- eliminating the need
+ to repeat the definition of these procedures in the application-
+ specific documents.
+
+ Each GENINFO TLV contains information regarding exactly one
+ application instance as identified by the Application ID in the
+ GENINFO TLV. When it is necessary to advertise sets of information
+
+
+
+Ginsberg, et al. Standards Track [Page 5]
+
+RFC 6823 Advertising Generic Information in IS-IS December 2010
+
+
+ with the same Application ID that have different flooding scopes, a
+ router MUST originate a minimum of one GENINFO TLV for each required
+ flooding scope. GENINFO TLVs that contain information having area/
+ level scope will have the S bit clear. These TLVs MUST NOT be leaked
+ into another level. GENINFO TLVs that contain information that has
+ domain scope will have the S bit set. These TLVs MUST be leaked into
+ other IS-IS levels. When a TLV is leaked from Level-2 to Level-1,
+ the D bit MUST be set in the Level-1 LSP advertisement.
+
+4.1. Leaking Procedures
+
+ When leaking GENINFO TLVs downward from Level-2 into Level-1, if the
+ originator of the TLV is a Level-1 router in another area, it is
+ possible that multiple copies of the same TLV may be received from
+ multiple L2 routers in the originating area. A router performing
+ downward leaking MUST check for such duplication by comparing the
+ contents of the TLVs. The set of LSPs generated by a router for a
+ given level MUST NOT contain two or more copies of the same GENINFO
+ TLV.
+
+ In order to prevent the use of stale GENINFO information, a system
+ MUST NOT use a GENINFO TLV present in an LSP of a system that is not
+ currently reachable via Level-x paths, where "x" is the level (1 or
+ 2) associated with the LSP in which the GENINFO TLV appears. Note
+ that leaking a GENINFO TLV is one of the uses that is prohibited
+ under these conditions. The following example illustrates what might
+ occur in the absence of this restriction.
+
+ Example: If Level-1 router A generates a GENINFO TLV and floods it to
+ two L1/L2 routers S and T, they will flood it into the Level-2 sub-
+ domain. Now suppose the Level-1 area partitions, such that A and S
+ are in one partition and T is in another. IP routing will still
+ continue to work, but if A now issues a revised version of the
+ GENINFO TLV, or decides to stop advertising it, S will follow suit,
+ but T will continue to advertise the old version until the LSP times
+ out.
+
+ Routers in other areas have to choose whether to trust T's copy of
+ A's GENINFO TLV or S's copy of A's information and they have no
+ reliable way to choose. By making sure that T stops leaking A's
+ information, this removes the possibility that other routers will use
+ stale information from A.
+
+
+
+
+
+
+
+
+
+Ginsberg, et al. Standards Track [Page 6]
+
+RFC 6823 Advertising Generic Information in IS-IS December 2010
+
+
+4.2. Minimizing Update Confusion
+
+ If an update to a TLV is advertised in an LSP with a different number
+ than the LSP associated with the old advertisement, the possibility
+ exists that other systems can temporarily have either 0 copies of a
+ particular advertisement or 2 copies of a particular advertisement,
+ depending on the order in which new copies of the LSP that had the
+ old advertisement and the LSP that has the new advertisement arrive
+ at other systems.
+
+ Whenever possible, an implementation SHOULD advertise the update to a
+ GENINFO TLV in the LSP with the same number as the advertisement that
+ it replaces. Where this is not possible, the two affected LSPs
+ SHOULD be flooded as an atomic action.
+
+ Systems that receive an update to an existing GENINFO TLV can
+ minimize the potential disruption associated with the update by
+ employing a hold-down time prior to processing the update so as to
+ allow for the receipt of multiple LSPs associated with the same
+ update prior to beginning processing.
+
+4.3. Interpreting Attribute Information
+
+ Where a receiving system has two copies of a GENINFO TLV with the
+ same Application ID, attribute information in the two TLVs that does
+ not conflict MUST be considered additive. When information in the
+ two GENINFO TLVs conflicts, i.e., there are different settings for a
+ given attribute, the procedure used to choose which copy shall be
+ used is undefined.
+
+5. Use of a Separate Protocol Instance
+
+ The use of the IS-IS flooding mechanism as a means of reliably and
+ efficiently propagating information is understandably attractive.
+ However, it is prudent to remember that the primary purpose of that
+ mechanism is to flood information necessary for the correct operation
+ of the IS-IS protocol. Flooding of information not directly related
+ to the use of the IS-IS protocol in support of routing degrades the
+ operation of the protocol. Degradation occurs because the frequency
+ of LSP updates is increased and because the processing of non-routing
+ information in each router consumes resources whose primary
+ responsibility is to efficiently respond to reachability changes in
+ the network.
+
+ Advertisement of GENINFO therefore MUST occur in the context of a
+ non-zero instance of the IS-IS protocol as defined in [RFC6822]
+ except when the use in the zero instance is defined in a Standards
+ Track RFC.
+
+
+
+Ginsberg, et al. Standards Track [Page 7]
+
+RFC 6823 Advertising Generic Information in IS-IS December 2010
+
+
+ The use of a separate instance of the protocol allows both the
+ flooding and the processing of the non-routing information to be
+ decoupled from the information necessary to support correct routing
+ of data in the network. The flooding and processing of non-routing
+ information can then be prioritized appropriately.
+
+ Use of a separate protocol instance to advertise GENINFO does not
+ eliminate the need to use prudence in the frequency with which such
+ information is updated. One of the most egregious oversights is a
+ failure to appropriately dampen changes in the information to be
+ advertised; this can lead to flooding storms. Documents that specify
+ the use of the mechanisms defined here MUST define the expected rate
+ of change of the information to be advertised.
+
+ If desirable, independent control of the flooding scope for
+ information related to two different applications can be achieved by
+ utilizing separate non-zero protocol instances for each application
+ [RFC6822].
+
+6. Applicability of GENINFO TLV
+
+ The GENINFO TLV supports the advertisement of application-specific
+ information in IS-IS LSPs that is not directly related to the
+ operation of the IS-IS protocol. Information advertised in the
+ GENINFO TLV MUST NOT alter basic IS-IS protocol operation including
+ (but not limited to) the establishment of adjacencies, the update
+ process, and the decision process.
+
+7. Standardization Requirements
+
+ GENINFO is intended to advertise information on behalf of
+ applications whose operations have been defined in a public
+ specification as discussed in [RFC5226].
+
+ The public specification MUST include:
+
+ o a description of the sub-TLV allocation policy
+
+ o discussion of security issues
+
+ o discussion of the rate of change of the information being
+ advertised
+
+ o justification for the use of GENINFO
+
+
+
+
+
+
+
+Ginsberg, et al. Standards Track [Page 8]
+
+RFC 6823 Advertising Generic Information in IS-IS December 2010
+
+
+8. Security Considerations
+
+ The introduction and use of the new TLV codepoint for GENINFO in and
+ of itself raises no new security issues for IS-IS.
+
+ It is possible that information advertised in a GENINFO TLV by a
+ given application MAY introduce new security issues. The public
+ specification that defines the use of GENINFO by that application
+ MUST include a discussion of the security issues. Where appropriate,
+ it is recommended that either [RFC5304] or [RFC5310] be used.
+
+9. IANA Considerations
+
+ Per this document, IANA has registered a new IS-IS TLV in the "IS-IS
+ TLV Codepoints" registry:
+
+ Type Description IIH LSP SNP Purge
+ ---- ---------------------------------- --- --- --- -----
+ 251 Generic Information n y n n
+
+ IANA has also created a new registry. The new registry manages the
+ assignment of Application Identifiers that may be used in the Generic
+ Information TLV. These identifiers are unsigned 16-bit numbers
+ ranging in value from 1 to 65535. The value 0 is reserved. The
+ registration procedure is "Expert Review" as defined in [RFC5226].
+ The expert MUST verify that the public specification that defines the
+ use of GENINFO for the application adequately discusses all points
+ mentioned in Section 7 of this document.
+
+ The following information MUST be specified in the registry:
+
+ o ID Value (1-65535)
+
+ o Description
+
+ o Allowed in Instance zero (Y/N)
+
+ o Reference Specification
+
+10. Acknowledgements
+
+ The authors would like to thank JP. Vasseur and David Ward for
+ providing the need to produce this document and Tony Li for making
+ sure it was done with appropriate wisdom and prudence.
+
+
+
+
+
+
+
+Ginsberg, et al. Standards Track [Page 9]
+
+RFC 6823 Advertising Generic Information in IS-IS December 2010
+
+
+11. Normative References
+
+ [ISO10589] International Organization for Standardization,
+ "Intermediate system to Intermediate system intra-domain
+ routeing information exchange protocol for use in
+ conjunction with the protocol for providing the
+ connectionless-mode Network Service (ISO 8473)",
+ ISO/IEC 10589:2002, Second Edition, Nov. 2002.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate
+ System to Intermediate System (IS-IS) Extensions for
+ Advertising Router Information", RFC 4971, July 2007.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+ [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
+ Authentication", RFC 5304, October 2008.
+
+ [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
+ Engineering", RFC 5305, October 2008.
+
+ [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
+ and M. Fanto, "IS-IS Generic Cryptographic
+ Authentication", RFC 5310, February 2009.
+
+ [RFC6822] Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D.
+ Ward, "IS-IS Multi-Instance", RFC 6822, December 2012.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ginsberg, et al. Standards Track [Page 10]
+
+RFC 6823 Advertising Generic Information in IS-IS December 2010
+
+
+Authors' Addresses
+
+ Les Ginsberg
+ Cisco Systems
+ 510 McCarthy Blvd.
+ Milpitas, CA 95035
+ USA
+
+ EMail: ginsberg@cisco.com
+
+
+ Stefano Previdi
+ Cisco Systems
+ Via Del Serafico 200
+ 00142 - Roma
+ Italy
+
+ EMail: sprevidi@cisco.com
+
+
+ Mike Shand
+ Cisco Systems
+ 250, Longwater Avenue.
+ Reading, Berks RG2 6GB
+ UK
+
+ EMail: imc.shand@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ginsberg, et al. Standards Track [Page 11]
+