Subject: updated draft of draft-ietf-isis-dyname-01.txt

From: Naiming Shen <[email-masked]>
Date: Fri, 02 Jul 1999 14:07:07 -0700

I missed the submission deadline for ietf draft directory, thus
sending the below updated draft on this mailing list.

Thanks. 

- Naiming

Internet Engineering Task Force                        Naiming Shen
INTERNET-DRAFT                                        Cisco Systems
draft-ietf-isis-dyname-01.txt                             Henk Smit
Expiration Date: December 1999                        Cisco Systems
                                                          June 1999

                 Dynamic Hostname Exchange Mechanism
                            for IS-IS

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 except that the right to
   produce derivative works is not granted.

   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

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                 June 1999

 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                 June 1999

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

 This document raises no new security issues for IS-IS. However it is
 encouraged to use authentications for IS-IS routing protocol.  The
 authentication mechanism for IS-IS protocol is specified in [1] and
 it is being enhanced within IETF in [2].

6. Acknowledgments
 
 The authors would like to thank Enke Chen and Yakov Rekhter for
 their comments on this work.

7. References

 [1] ISO, "Intermediate system to Intermediate system routeing
     information exchange protocol for use in conjunction with the
     Protocol for providing the Connectionless-mode Network Service
     (ISO 8473)," ISO/IEC 10589:1992.

Shen & Smit                                                [Page 3]

Internet Draft           Dynamic Hostname                 June 1999

 [2] draft-ietf-isis-hmac-00.txt, "IS-IS HMAC-MD5 Authentication",
     T. Li, work in progress.

8. Author's Address:
 
 Naiming Shen
 Cisco Systems, Inc.
 170 Tasman Drive
 San Jose, CA, 95134
 
 Email: [email-masked]
 
 Henk Smit
 Cisco Systems, Inc.
 170 Tasman Drive
 San Jose, CA, 95134
 
 Email: [email-masked]

Shen & Smit          Expires December 1999                 [Page 4]