draft-ietf-isis-dyname-02.txt   rfc2763.txt 
Internet Engineering Task Force Naiming Shen
INTERNET-DRAFT Cisco Systems
draft-ietf-isis-dyname-02.txt Henk Smit
Expiration Date: April 2000 Cisco Systems
October 1999
Dynamic Hostname Exchange Mechanism
for IS-IS
Status of this Memo Network Working Group N. Shen
Request for Comments: 2763 Siara Systems
Category: Informational H. Smit
Cisco Systems
February 2000
This document is an Internet-Draft and is in full conformance with Dynamic Hostname Exchange Mechanism
all provisions of Section 10 of RFC2026 except that the right to for IS-IS
produce derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering Status of this Memo
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 This memo provides information for the Internet community. It does
and may be updated, replaced, or obsoleted by other documents at any not specify an Internet standard of any kind. Distribution of this
time. It is inappropriate to use Internet- Drafts as reference memo is unlimited.
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2000). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
Currently there does not exist a simple and dynamic mechanism for Currently, there does not exist a simple and dynamic mechanism for
routers running IS-IS to learn about symbolic hostnames. This routers running IS-IS to learn about symbolic hostnames. This
document defines a new TLV which allows the IS-IS routers to flood 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. their name to system ID mapping information across the IS-IS network.
1. Introduction 1. Introduction
IS-IS uses a 1-8 byte system ID (normally 6 bytes) to represent a 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 node in the network. For management and operation reasons, network
operators need to check the status of IS-IS adjacencies, entries in 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. the routing table and the content of the IS-IS link state database.
It is obvious that, when looking at diagnostics information, It is obvious that, when looking at diagnostics information,
hexadecimal representations of systemIDs and LSP identifiers are hexadecimal representations of systemIDs and LSP identifiers are less
less clear than symbolic names. clear than symbolic names.
One way to overcome this problem is to define a name-to-systemID 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. mapping on a router. This mapping can be used bidirectionally. E.g.,
to find symbolic names for systemIDs, and to find systemIDs for to find symbolic names for systemIDs, and to find systemIDs for
symbolic names. One way to build this table of mappings is by symbolic names. One way to build this table of mappings is by static
static definitions. Among network administrators who use IS-IS as definitions. Among network administrators who use IS-IS as their IGP
their IGP it is current practice to define such static mappings. it is current practice to define such static mappings.
Thus every router has to maintain a table with mappings between Thus every router has to maintain a table with mappings between
router names and systemIDs. These tables need to contain all names router names and systemIDs. These tables need to contain all names
and systemIDs of all routers in the network. and systemIDs of all routers in the network.
There are several ways one could build such a table. One is via There are several ways one could build such a table. One is via
static configurations. Another scheme that could be implemented is static configurations. Another scheme that could be implemented is
via DNS lookups. In this document we propose a third solution. We via DNS lookups. In this document we propose a third solution. We
hope the proposed solution is easier and more manageable than hope the proposed solution is easier and more manageable than static
static mapping or DNS schemes. mapping or DNS schemes.
2. Possible solutions 2. Possible solutions
The obvious drawback of static configuration of mappings is the The obvious drawback of static configuration of mappings is the issue
issue of scalability and maintainability. The network operators of scalability and maintainability. The network operators have to
have to maintain the name tables. They have to maintain an entry maintain the name tables. They have to maintain an entry in the table
in the table for every router in the network. They have to maintain for every router in the network. They have to maintain this table on
this table on each router in the network. The effort to create and each router in the network. The effort to create and maintain these
maintain these static tables grows with the total number of routers static tables grows with the total number of routers on the network.
on the network. Changing the name or systemID of one router, or Changing the name or systemID of one router, or adding one new router
adding one new router introduced will affect the configurations of introduced will affect the configurations of all the other routers on
all the other routers on the network. This will make it very likely the network. This will make it very likely that those static tables
that those static tables are outdated. are outdated.
Having one table that can be updated in a centralized place would Having one table that can be updated in a centralized place would be
be helpful. One could imagine using the DNS system for this. A helpful. One could imagine using the DNS system for this. A drawback
drawback is that during the time of network problems, the response is that during the time of network problems, the response time of DNS
time of DNS services might not be satisfactory or the DNS services services might not be satisfactory or the DNS services might not even
might not even be available. Another possible drawback might be the be available. Another possible drawback might be the added complexity
added complexity of DNS. Also, some DNS implementations might not of DNS. Also, some DNS implementations might not support A and PTR
support A and PTR records for CLNS NSAPs. records for CLNS NSAPs.
A third way to build dynamic mappings would be to use the transport A third way to build dynamic mappings would be to use the transport
mechanism of the routing protocol itself to advertise symbolic names mechanism of the routing protocol itself to advertise symbolic names
in IS-IS link-state PDU. This document defines a new TLV which in IS-IS link-state PDU. This document defines a new TLV which allows
allows the IS-IS routers to include the name to systemID mapping the IS-IS routers to include the name to systemID mapping information
information in their LSPs. This will allow simple and reliable in their LSPs. This will allow simple and reliable transport of name
transport of name mapping information across the IS-IS network. mapping information across the IS-IS network.
3. The Dynamic Hostname TLV 3. The Dynamic Hostname TLV
The Dynamic hostname TLV is defined here as TLV type 137. The Dynamic hostname TLV is defined here as TLV type 137.
LENGTH - total length of the value field. LENGTH - total length of the value field.
VALUE - a string of 1 to 255 bytes. VALUE - a string of 1 to 255 bytes.
The Dynamic hostname TLV is optional. This TLV may be present in any 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 fragment of a non-pseudo node LSP. The value field identifies the
symbolic name of the router originating the LSP. This symbolic name 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 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 string operators want to use for the router. The use of FQDN or a
subset of it is strongly recommended. The content of this value is a 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 domain name, see RFC 2181. The string is not null-terminated. The
systemID of this router can be derived from the LSP identifier. systemID of this router can be derived from the LSP identifier.
If this TLV is present in a pseudo node LSP, then it should not be If this TLV is present in a pseudo node LSP, then it should not be
interpreted as the DNS hostname of the router. interpreted as the DNS hostname of the router.
4. Implementation 4. Implementation
The Dynamic Hostname TLV is optional. When originating an LSP, a 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 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 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 TLV, or to install the symbolic name and systemID in its hostname
mapping table. mapping table.
A router may also optionally insert this TLV in it's pseudo node LSP A router may also optionally insert this TLV in it's pseudo node LSP
for the association of a symbolic name to a local LAN. for the association of a symbolic name to a local LAN.
5. Security Considerations 5. Security Considerations
This document raises no new security issues for IS-IS. However it is This document raises no new security issues for IS-IS. However, it is
encouraged to use authentications for IS-IS routing protocol. The encouraged to use authentications for IS-IS routing protocol. The
authentication mechanism for IS-IS protocol is specified in [1] and authentication mechanism for IS-IS protocol is specified in [1] and
it is being enhanced within IETF in [2]. it is being enhanced within IETF in [2].
6. Acknowledgments 6. Acknowledgments
The authors would like to thank Enke Chen and Yakov Rekhter for The authors would like to thank Enke Chen and Yakov Rekhter for their
their comments on this work. comments on this work.
7. References 7. References
[1] ISO, "Intermediate system to Intermediate system routeing [1] ISO, "Intermediate system to Intermediate system routing
information exchange protocol for use in conjunction with the information exchange protocol for use in conjunction with the
Protocol for providing the Connectionless-mode Network Service Protocol for providing the Connectionless-mode Network Service
(ISO 8473)," ISO/IEC 10589:1992. (ISO 8473)," ISO/IEC 10589:1992.
[2] draft-ietf-isis-hmac-00.txt, "IS-IS HMAC-MD5 Authentication", [2] Li, T., "IS-IS HMAC-MD5 Authentication", Work in Progress.
T. Li, work in progress.
8. Author's Address: 8. Authors' Addresses
Naiming Shen Naiming Shen
Cisco Systems, Inc. Siara Systems, Inc.
170 Tasman Drive 1195 Borregas Avenue
San Jose, CA, 95134 Sunnyvale, CA, 94089
Email: naiming@cisco.com EMail: naiming@siara.com
Henk Smit Henk Smit
Cisco Systems, Inc. Cisco Systems, Inc.
170 Tasman Drive 170 Tasman Drive
San Jose, CA, 95134 San Jose, CA, 95134
Email: hsmit@cisco.com EMail: hsmit@cisco.com
9. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 31 change blocks. 
114 lines changed or deleted 102 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/