idnits 2.17.1 draft-ietf-isis-dyname-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (January 1999) is 9232 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) -- Missing reference section? 'TBD' on line 125 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Naiming Shen 2 INTERNET-DRAFT Cisco Systems 3 draft-ietf-isis-dyname-00.txt Henk Smit 4 Cisco Systems 5 January 1999 7 Dynamic Hostname Exchange Mechanism 8 for IS-IS 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a 21 ``working draft'' or ``work in progress``. 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nic.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 Abstract 32 Currently there does not exist a simple and dynamic mechanism for 33 routers running IS-IS to learn about symbolic hostnames. This 34 document defines a new TLV which allows the IS-IS routers to flood 35 their name to system ID mapping information across the IS-IS network. 37 1. Introduction 39 IS-IS uses a 1-8 byte system ID (normally 6 bytes) to represent a 40 node in the network. For management and operation reasons, network 41 operators need to check the status of IS-IS adjacencies, entries in 42 the routing table and the content of the IS-IS link state database. 43 It is obvious that, when looking at diagnostics information, 44 hexadecimal representations of systemIDs and LSP identifiers are 45 less clear than symbolic names. 47 One way to overcome this problem is to define a name-to-systemID 48 mapping on a router. This mapping can be used bidirectionally. E.g. 49 to find symbolic names for systemIDs, and to find systemIDs for 50 symbolic names. One way to build this table of mappings is by 51 static definitions. Among network administrators who use IS-IS as 52 their IGP it is current practice to define such static mappings. 54 Thus every router has to maintain a table with mappings between 55 router names and systemIDs. These tables need to contain all names 56 and systemIDs of all routers in the network. 58 There are several ways one could build such a table. One is via 59 static configurations. Another scheme that could be implemented is 60 via DNS lookups. In this document we propose a third solution. We 61 hope the proposed solution is easier and more manageable than 62 static mapping or DNS schemes. 64 2. Possible solutions 66 The obvious drawback of static configuration of mappings is the 67 issue of scalability and maintainability. The network operators 68 have to maintain the name tables. They have to maintain an entry 69 in the table for every router in the network. They have to maintain 70 this table on each router in the network. The effort to create and 71 maintain these static tables grows with the total number of routers 72 on the network. Changing the name or systemID of one router, or 73 adding one new router introduced will affect the configurations of 74 all the other routers on the network. This will make it very likely 75 that those static tables are outdated. 77 Having one table that can be updated in a centralized place would 78 be helpful. One could imagine using the DNS system for this. A 79 drawback is that during the time of network problems, the response 80 time of DNS services might not be satisfactory or the DNS services 81 might not even be available. Another possible drawback might be the 82 added complexity of DNS. Also, some DNS implementations might not 83 support A and PTR records for CLNS NSAPs. 85 A third way to build dynamic mappings would be to use the transport 86 mechanism of the routing protocol itself to advertise symbolic names 87 in IS-IS link-state PDU. This document defines a new TLV which 88 allows the IS-IS routers to include the name to systemID mapping 89 information in their LSPs. This will allow simple and reliable 90 transport of name mapping information across the IS-IS network. 92 3. The Dynamic Hostname TLV 94 The Dynamic hostname TLV is defined here as TLV type 137. 96 LENGTH - total length of the value field. 98 VALUE - a string of 1 to 255 bytes. 100 The Dynamic hostname TLV is optional. This TLV may be present in any 101 fragment of a non-pseudo node LSP. The value field identifies the 102 symbolic name of the router originating the LSP. This symbolic name 103 can be the FQDN for the router, it can be a subset of the FQDN or any 104 string operators want to use for the router. The use of FQDN or a 105 subset of it is strongly recommended. It is one byte per character, 106 7-bit ASCII. The string is not null-terminated. The 107 systemID of this router can be derived from the LSP identifier. 109 4. Implementation 111 The Dynamic Hostname TLV is optional. When originating an LSP, a 112 router may decide to include this TLV in its LSP. Upon receipt of an 113 LSP with the dynamic hostname TLV, a router may decide to ignore this 114 TLV, or to install the symbolic name and systemID in its hostname 115 mapping table. 117 This protocol extension has been implemented by Cisco Systems. 119 5. Security Considerations 121 Security issues are not discussed in this document. 123 6. Acknowledgments 125 [TBD] 127 7. Author's Address: 129 Naiming Shen 130 Cisco Systems, Inc. 131 170 Tasman Drive 132 San Jose, CA, 95134 134 Email: naiming@cisco.com 136 Henk Smit 137 Cisco Systems, Inc. 138 170 Tasman Drive 139 San Jose, CA, 95134 141 Email: hsmit@cisco.com