summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7370.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7370.txt')
-rw-r--r--doc/rfc/rfc7370.txt395
1 files changed, 395 insertions, 0 deletions
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,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC5130] Previdi, S., Shand, M., and C. Martin, "A Policy Control
+ Mechanism in IS-IS Using Administrative Tags", RFC 5130,
+ February 2008, <http://www.rfc-editor.org/info/rfc5130>.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008, <http://www.rfc-editor.org/info/rfc5226>.
+
+ [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,
+ <http://www.rfc-editor.org/info/rfc5311>.
+
+ [RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for
+ Purges", RFC 6233, May 2011,
+ <http://www.rfc-editor.org/info/rfc6233>.
+
+ [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
+ Points", BCP 100, RFC 7120, January 2014,
+ <http://www.rfc-editor.org/info/rfc7120>.
+
+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, <http://www.rfc-editor.org/info/rfc3563>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+