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/rfc7370.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc7370.txt (limited to 'doc/rfc/rfc7370.txt') diff --git a/doc/rfc/rfc7370.txt b/doc/rfc/rfc7370.txt new file mode 100644 index 0000000..b8e4892 --- /dev/null +++ b/doc/rfc/rfc7370.txt @@ -0,0 +1,395 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Ginsberg +Request for Comments: 7370 Cisco Systems +Category: Standards Track September 2014 +ISSN: 2070-1721 + + + Updates to the IS-IS TLV Codepoints Registry + +Abstract + + This document recommends some editorial changes to the IANA "IS-IS + TLV Codepoints" registry to more accurately document the state of the + protocol. It also sets out new guidelines for Designated Experts to + apply when reviewing allocations from the registry. + +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/rfc7370. + + + + + + + + + + + + + + + + + + + + + + + +Ginsberg Standards Track [Page 1] + +RFC 7370 IS-IS TLV Codepoints September 2014 + + +Copyright Notice + + Copyright (c) 2014 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. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Ginsberg Standards Track [Page 2] + +RFC 7370 IS-IS TLV Codepoints September 2014 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 + 2. IS Neighbor Sub-TLV Registry . . . . . . . . . . . . . . . . 4 + 3. Prefix Reachability Sub-TLV Registry . . . . . . . . . . . . 4 + 4. Guidance for Designated Experts . . . . . . . . . . . . . . . 4 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 + 7.2. Informative References . . . . . . . . . . . . . . . . . 6 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 + +1. Introduction + + The "IS-IS TLV Codepoints" registry was created by [RFC3563] and + extended by [RFC6233]. The assignment policy for the registry is + "Expert Review" as defined in [RFC5226]. As documents related to + IS-IS are developed, the codepoints required for the protocol + extensions are reviewed by the Designated Experts and added to the + IANA-managed registry. As these documents are published as RFCs, the + registries are updated to reference the relevant RFC. + + In the case of TLVs supporting prefix advertisement, currently + separate sub-TLV registries are maintained for each TLV. These + registries need to be combined into a common sub-TLV registry similar + to what has been done for neighbor advertisement TLVs. + + In some cases, there is a need to allocate codepoints defined in + Internet-Drafts (I-Ds) that seem likely to eventually gain Working + Group approval, without waiting for those I-Ds to be published as + RFCs. This can be achieved using Expert Review, and this document + sets out guidance for the Designated Experts to apply when reviewing + allocations from the registry. + +1.1. Requirements Language + + 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 RFC 2119 [RFC2119]. + + + + + + + + + +Ginsberg Standards Track [Page 3] + +RFC 7370 IS-IS TLV Codepoints September 2014 + + +2. IS Neighbor Sub-TLV Registry + + There was an existing common sub-TLV registry named "Sub-TLVs for + TLVs 22, 141, and 222". [RFC5311] defines the IS Neighbor Attribute + TLV (23) and the MT IS Neighbor Attribute TLV (223). The format of + these TLVs is identical to TLVs 22 and 222, respectively. The IS + Neighbor sub-TLV registry has been extended to include these two + TLVs. Settings for inclusion of each sub-TLV are identical to the + settings for TLVs 22 and 222, respectively. + +3. Prefix Reachability Sub-TLV Registry + + Previously, there existed separate sub-TLV registries for TLVs 135, + 235, 236, and 237. As in the case of the IS Neighbor TLVs discussed + in the previous section, assignment of sub-TLVs applicable to one or + more of these TLVs is intended to be common. Therefore, the existing + separate sub-TLV registries have been combined into a single registry + entitled "Sub-TLVs for TLVs 135, 235, 236, and 237". As existing + sub-TLV assignments are common to all the TLVs, this represents no + change to the protocol -- only a clearer representation of the + intended sub-TLV allocation strategy. The format of the registry is + as shown below: + + Type Description 135 235 236 237 Reference + ---- ------------ --- --- --- --- --------- + 0 Unassigned + 1 32-bit Administrative Tag Sub-TLV y y y y [RFC5130] + 2 64-bit Administrative Tag Sub-TLV y y y y [RFC5130] + 3-255 Unassigned + +4. Guidance for Designated Experts + + When new I-Ds are introduced requiring new codepoints, it is + advantageous to be able to allocate codepoints without waiting for + them to progress to RFC. The reasons this is advantageous are + described in [RFC7120]. However, the procedures in [RFC7120] for + early allocation do not apply to registries, such as the "IS-IS TLV + Codepoints" registry, that utilize the "Expert Review" allocation + policy. In such cases, what is required is that a request be made to + the Designated Experts who MAY approve the assignments according to + the guidance that has been established for the registry concerned. + + The following guidance applies specifically to the "IS-IS TLV + Codepoints" registry. + + 1. Application for a codepoint allocation MAY be made to the + Designated Experts at any time. + + + + +Ginsberg Standards Track [Page 4] + +RFC 7370 IS-IS TLV Codepoints September 2014 + + + 2. The Designated Experts SHOULD only consider requests that arise + from I-Ds that have already been accepted as Working Group + documents or that are planned for progression as AD Sponsored + documents in the absence of a suitably chartered Working Group. + + 3. In the case of Working Group documents, the Designated Experts + SHOULD check with the Working Group chairs that there is + consensus within the Working Group to make the allocation at this + time. In the case of AD Sponsored documents, the Designated + Experts SHOULD check with the AD for approval to make the + allocation at this time. + + 4. The Designated Experts SHOULD then review the assignment requests + on their technical merit. The Designated Experts SHOULD NOT seek + to overrule IETF consensus, but they MAY raise issues for further + consideration before the assignments are made. + + 5. Once the Designated Experts have granted approval, IANA will + update the registry by marking the allocated codepoints with a + reference to the associated document as normal. + + 6. In the event that the document fails to progress to RFC, the + Expiry and deallocation process defined in [RFC7120] MUST be + followed for the relevant codepoints -- noting that the + Designated Experts perform the role assigned to Working Group + chairs. + +5. IANA Considerations + + This document provides guidance to the Designated Experts appointed + to manage allocation requests in the "IS-IS TLV Codepoints" registry. + + IANA has updated the registry that was specified as "Sub-TLVs for + TLVs 22, 141, and 222" to be named "Sub-TLVs for TLVs 22, 23, 141, + 222, and 223". + + Per this document, the existing sub-TLV registries for TLVs 135, 235, + 236, and 237 have been combined into a single registry -- the + "Sub-TLVs for TLVs 135, 235, 236, and 237" registry -- as described + in Section 3. + +6. Security Considerations + + This document introduces no new security issues. + + + + + + + +Ginsberg Standards Track [Page 5] + +RFC 7370 IS-IS TLV Codepoints September 2014 + + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997, + . + + [RFC5130] Previdi, S., Shand, M., and C. Martin, "A Policy Control + Mechanism in IS-IS Using Administrative Tags", RFC 5130, + February 2008, . + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008, . + + [RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand, + "Simplified Extension of Link State PDU (LSP) Space for + IS-IS", RFC 5311, February 2009, + . + + [RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for + Purges", RFC 6233, May 2011, + . + + [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code + Points", BCP 100, RFC 7120, January 2014, + . + +7.2. Informative References + + [RFC3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF + and ISO/IEC Joint Technical Committee 1/Sub Committee 6 + (JTC1/SC6) on IS-IS Routing Protocol Development", RFC + 3563, July 2003, . + + + + + + + + + + + + + + + + +Ginsberg Standards Track [Page 6] + +RFC 7370 IS-IS TLV Codepoints September 2014 + + +Acknowledgements + + The author wishes to thank Alia Atlas and Amanda Baber for their + input in defining the correct process to follow to get these changes + implemented. Special thanks to Adrian Farrel for crafting the text + in Section 4. + +Author's Address + + Les Ginsberg + Cisco Systems + 510 McCarthy Blvd. + Milpitas, CA 95035 + United States + + EMail: ginsberg@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ginsberg Standards Track [Page 7] + -- cgit v1.2.3