Dynamic Hostname Exchange Mechanism for IS-IS (RFC2763)
Original Publication Date: 2000-Feb-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
N. Shen: AUTHOR [+2]
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.
Network Working Group N. Shen
Request for Comments: 2763 Siara Systems
Category: Informational H. Smit
Dynamic Hostname Exchange Mechanism
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 (C) The Internet Society (2000). All Rights Reserved.
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.
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.
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