Internet Engineering Task Force Naiming Shen INTERNET-DRAFT Cisco Systems draft-ietf-isis-dyname-00.txt Henk Smit Cisco Systems January 1999 Dynamic Hostname Exchange Mechanism for IS-IS Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress``. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract Currently there does not exist a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. This document defines a new TLV which allows the IS-IS routers to flood their name to system ID mapping information across the IS-IS network. 1. Introduction IS-IS uses a 1-8 byte system ID (normally 6 bytes) to represent a node in the network. For management and operation reasons, network operators need to check the status of IS-IS adjacencies, entries in the routing table and the content of the IS-IS link state database. It is obvious that, when looking at diagnostics information, hexadecimal representations of systemIDs and LSP identifiers are less clear than symbolic names. Shen & Smit [Page 1]
Internet Draft Dynamic Hostname November 1998 One way to overcome this problem is to define a name-to-systemID mapping on a router. This mapping can be used bidirectionally. E.g. to find symbolic names for systemIDs, and to find systemIDs for symbolic names. One way to build this table of mappings is by static definitions. Among network administrators who use IS-IS as their IGP it is current practice to define such static mappings. Thus every router has to maintain a table with mappings between router names and systemIDs. These tables need to contain all names and systemIDs of all routers in the network. There are several ways one could build such a table. One is via static configurations. Another scheme that could be implemented is via DNS lookups. In this document we propose a third solution. We hope the proposed solution is easier and more manageable than static mapping or DNS schemes. 2. Possible solutions The obvious drawback of static configuration of mappings is the issue of scalability and maintainability. The network operators have to maintain the name tables. They have to maintain an entry in the table for every router in the network. They have to maintain this table on each router in the network. The effort to create and maintain these static tables grows with the total number of routers on the network. Changing the name or systemID of one router, or adding one new router introduced will affect the configurations of all the other routers on the network. This will make it very likely that those static tables are outdated. Having one table that can be updated in a centralized place would be helpful. One could imagine using the DNS system for this. A drawback is that during the time of network problems, the response time of DNS services might not be satisfactory or the DNS services might not even be available. Another possible drawback might be the added complexity of DNS. Also, some DNS implementations might not support A and PTR records for CLNS NSAPs. A third way to build dynamic mappings would be to use the transport mechanism of the routing protocol itself to advertise symbolic names in IS-IS link-state PDU. This document defines a new TLV which allows the IS-IS routers to include the name to systemID mapping information in their LSPs. This will allow simple and reliable transport of name mapping information across the IS-IS network. Shen & Smit [Page 2]
Internet Draft Dynamic Hostname November 1998 3. The Dynamic Hostname TLV The Dynamic hostname TLV is defined here as TLV type 137. LENGTH - total length of the value field. VALUE - a string of 1 to 255 bytes. The Dynamic hostname TLV is optional. This TLV may be present in any fragment of a non-pseudo node LSP. The value field identifies the symbolic name of the router originating the LSP. This symbolic name can be the FQDN for the router, it can be a subset of the FQDN or any string operators want to use for the router. The use of FQDN or a subset of it is strongly recommended. It is one byte per character, 7-bit ASCII. The string is not null-terminated. The systemID of this router can be derived from the LSP identifier. 4. Implementation The Dynamic Hostname TLV is optional. When originating an LSP, a router may decide to include this TLV in its LSP. Upon receipt of an LSP with the dynamic hostname TLV, a router may decide to ignore this TLV, or to install the symbolic name and systemID in its hostname mapping table. This protocol extension has been implemented by Cisco Systems. 5. Security Considerations Security issues are not discussed in this document. 6. Acknowledgments [TBD] 7. Author's Address: Naiming Shen Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 Email: naiming@cisco.com Henk Smit Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 Email: hsmit@cisco.com Shen & Smit [Page 3]
