Dynamic Hostname Exchange Mechanism for IS-IS
RFC 2763

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

Network Working Group                                           N. Shen
Request for Comments: 2763                                Siara Systems
Category: Informational                                         H. Smit
                                                          Cisco Systems
                                                          February 2000

                  Dynamic Hostname Exchange Mechanism
                               for IS-IS

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

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.

   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.

Shen & Smit                  Informational                      [Page 1]
RFC 2763                    Dynamic Hostname               February 2000

   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.

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

Shen & Smit                  Informational                      [Page 2]
RFC 2763                    Dynamic Hostname               February 2000

   subset of it is strongly recommended. The content of this value is a
   domain name, see RFC 2181. The string is not null-terminated. The
   systemID of this router can be derived from the LSP identifier.