idnits 2.17.1 draft-ietf-isis-rfc2763bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 212. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 219. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 225. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2763]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 30, 2007) is 6052 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'ISO 8473' is defined on line 177, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 8473' -- Obsolete informational reference (is this intentional?): RFC 2763 (Obsoleted by RFC 5301) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Danny McPherson 2 Arbor Networks 3 Naiming Shen 4 Cisco Systems 5 Expires: March 2008 September 30, 2007 6 Intended Status: Proposed Standard 8 Dynamic Hostname Exchange Mechanism for IS-IS 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 Currently, there does not exist a simple and dynamic mechanism for 41 routers running IS-IS to learn about symbolic hostnames. This 42 document defines a new TLV which allows the IS-IS routers to flood 43 their name-to-systemID mapping information across the IS-IS network. 45 The intention of this document is to provide an update to [RFC 2763]. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 1.1. Specification of Requirements . . . . . . . . . . . . . . . 4 51 2. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Dynamic Hostname TLV . . . . . . . . . . . . . . . . . . . . . 5 53 4. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 6 54 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 6 55 6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 6 56 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 7 57 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 8.1. Normative References. . . . . . . . . . . . . . . . . . . . 8 59 8.2. Informative References. . . . . . . . . . . . . . . . . . . 8 60 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 62 1. Introduction 64 IS-IS uses a variable 1-8 byte system ID (normally 6 bytes) to 65 represent a node in the network. For management and operation 66 reasons, network operators need to check the status of IS-IS 67 adjacencies, entries in the routing table and the content of the IS- 68 IS link state database. It is obvious that, when looking at 69 diagnostics information, hexadecimal representations of systemIDs and 70 LSP identifiers are less clear than symbolic names. 72 One way to overcome this problem is to define a name-to-systemID 73 mapping on a router. This mapping can be used bidirectionally. E.g., 74 to find symbolic names for systemIDs, and to find systemIDs for 75 symbolic names. One way to build this table of mappings is by static 76 definitions. Among network administrators who use IS-IS as their IGP 77 it is current practice to define such static mappings. 79 Thus every router has to maintain a statically configured table with 80 mappings between router names and systemIDs. These tables need to 81 contain all names and systemIDs of all routers in the network, and 82 must be modified each time an addition, deletion or change occurs.. 84 There are several ways one could build such a table. One is via 85 static configurations. Another scheme that could be implemented is 86 via DNS lookups. In this document we propose a third solution. We 87 hope the proposed solution is easier and more manageable than static 88 mapping or DNS schemes, and wide-scale implementation and deployment 89 of this capability has proved this to be the case. 91 1.1. Specification of Requirements 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC 2119]. 97 2. Possible Solutions 99 The obvious drawback of static configuration of mappings is the issue 100 of scalability and maintainability. The network operators have to 101 maintain the name tables. They have to maintain an entry in the table 102 for every router in the network, on every router in the network. The 103 effort to create and maintain these static tables grows with the 104 total number of routers on the network. Changing the name or 105 systemID of one router, or adding one new router introduced will 106 affect the configurations of all the other routers on the network. 107 This will make it very likely that those static tables are outdated. 109 Having one table that can be updated in a centralized place would be 110 helpful. One could imagine using the DNS system for this. A drawback 111 is that during the time of network problems, the response time of DNS 112 services might not be satisfactory or the DNS services might not even 113 be available. Another possible drawback might be the added complexity 114 of DNS. Also, some DNS implementations might not support A and PTR 115 records for CLNS NSAPs. 117 A third way to build dynamic mappings would be to use the transport 118 mechanism of the routing protocol itself to advertise symbolic names 119 in IS-IS link-state PDUs. This document defines a new TLV which 120 allows the IS-IS routers to include the name-to-systemID mapping data 121 in their LSPs. This will allow simple and reliable transport of name 122 mapping information across the IS-IS network. 124 3. Dynamic Hostname TLV 126 The Dynamic hostname TLV is defined here as TLV type 137. 128 LENGTH - total length of the value field. 130 VALUE - a string of 1 to 255 bytes. 132 The Dynamic hostname TLV is optional. This TLV may be present in any 133 fragment of a non-pseudo node LSP. The value field identifies the 134 symbolic name of the router originating the LSP. This symbolic name 135 can be the FQDN for the router, it can be a subset of the FQDN or any 136 string operators want to use for the router. The use of FQDN or a 137 subset of it is strongly recommended. The content of this value is a 138 domain name, see [RFC 2181]. The string is not null-terminated. The 139 systemID of this router can be derived from the LSP identifier. 141 If this TLV is present in a pseudo node LSP, then it SHOULD NOT be 142 interpreted as the DNS hostname of the router. 144 4. Implementation 146 The Dynamic Hostname TLV is optional. When originating an LSP, a 147 router may decide to include this TLV in its LSP. Upon receipt of an 148 LSP with the dynamic hostname TLV, a router may decide to ignore this 149 TLV, or to install the symbolic name and systemID in its hostname 150 mapping table for the IS-IS network. 152 A router may also optionally insert this TLV in it's pseudo node LSP 153 for the association of a symbolic name to a local LAN. 155 5. Security Considerations 157 This document raises no new security issues for IS-IS. 159 6. Acknowledgments 161 The original efforts and corresponding acknowledgements provided in 162 [RFC 2763] have enabled this work. In particular, we'd like to 163 acknowledge Henk Smit as an author of that document. 165 Others to be provided.... 167 7. IANA Considerations 169 This document specificies TLV 137, "Dynamic Name". This TLV has 170 already been allocated and reserved [RFC 2763]. As such, no new 171 actions are required on the part of IANA. 173 8. References 175 8.1. Normative References 177 [ISO 8473] ISO, "Intermediate system to Intermediate system 178 routeing information exchange protocol for use in conjunction 179 with the Protocol for providing the Connectionless-mode Network 180 Service (ISO 8473)," ISO/IEC 10589:1992. 182 8.2. Informative References 184 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 185 Requirement Levels", RFC 2119, March 1997. 187 [RFC 2181] Elz, R., Bush, R., "Clarifications to the DNS 188 Specification", RFC 2181, July 1997. 190 [RFC 2763] Smit, H., Shen, N., "Dynamic Hostname Exchange 191 Mechanism for IS-IS, RFC 2763, February 2000. 193 9. Authors' Addresses 195 Danny McPherson 196 Arbor Networks, Inc. 197 EMail: danny@arbor.net 199 Naiming Shen 200 Cisco Systems, Inc. 201 EMail: naiming@cisco.com 203 Intellectual Property Statement 205 The IETF takes no position regarding the validity or scope of any 206 Intellectual Property Rights or other rights that might be claimed to 207 pertain to the implementation or use of the technology described in 208 this document or the extent to which any license under such rights 209 might or might not be available; nor does it represent that it has 210 made any independent effort to identify any such rights. Information 211 on the procedures with respect to rights in RFC documents can be 212 found in BCP 78 and BCP 79. 214 Copies of IPR disclosures made to the IETF Secretariat and any 215 assurances of licenses to be made available, or the result of an 216 attempt made to obtain a general license or permission for the use of 217 such proprietary rights by implementers or users of this 218 specification can be obtained from the IETF on-line IPR repository at 219 http://www.ietf.org/ipr. 221 The IETF invites any interested party to bring to its attention any 222 copyrights, patents or patent applications, or other proprietary 223 rights that may cover technology that may be required to implement 224 this standard. Please address the information to the IETF at 225 ietf-ipr@ietf.org. 227 Copyright Statement 229 Copyright (C) The IETF Trust (2007). 231 This document is subject to the rights, licenses and restrictions 232 contained in BCP 78, and except as set forth therein, the authors 233 retain all their rights. 235 This document and the information contained herein are provided on an 236 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 237 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 238 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 239 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 240 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 241 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 242 PURPOSE. 244 Acknowledgment 246 Funding for the RFC Editor function is provided by the IETF 247 Administrative Support Activity (IASA).