From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6823.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc6823.txt (limited to 'doc/rfc/rfc6823.txt') 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] + -- cgit v1.2.3