idnits 2.17.1 draft-ietf-isis-dyname-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 1999) is 8889 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-04) exists of draft-ietf-isis-hmac-00 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-hmac (ref. '2') Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Naiming Shen 2 INTERNET-DRAFT Siara Systems 3 draft-ietf-isis-dyname-03.txt Henk Smit 4 Expiration Date: June 2000 Cisco Systems 5 December 1999 7 Dynamic Hostname Exchange Mechanism 8 for IS-IS 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 Currently there does not exist a simple and dynamic mechanism for 34 routers running IS-IS to learn about symbolic hostnames. This 35 document defines a new TLV which allows the IS-IS routers to flood 36 their name to system ID mapping information across the IS-IS network. 38 1. Introduction 40 IS-IS uses a 1-8 byte system ID (normally 6 bytes) to represent a 41 node in the network. For management and operation reasons, network 42 operators need to check the status of IS-IS adjacencies, entries in 43 the routing table and the content of the IS-IS link state database. 44 It is obvious that, when looking at diagnostics information, 45 hexadecimal representations of systemIDs and LSP identifiers are 46 less clear than symbolic names. 48 One way to overcome this problem is to define a name-to-systemID 49 mapping on a router. This mapping can be used bidirectionally. E.g. 50 to find symbolic names for systemIDs, and to find systemIDs for 51 symbolic names. One way to build this table of mappings is by 52 static definitions. Among network administrators who use IS-IS as 53 their IGP it is current practice to define such static mappings. 55 Thus every router has to maintain a table with mappings between 56 router names and systemIDs. These tables need to contain all names 57 and systemIDs of all routers in the network. 59 There are several ways one could build such a table. One is via 60 static configurations. Another scheme that could be implemented is 61 via DNS lookups. In this document we propose a third solution. We 62 hope the proposed solution is easier and more manageable than 63 static mapping or DNS schemes. 65 2. Possible solutions 67 The obvious drawback of static configuration of mappings is the 68 issue of scalability and maintainability. The network operators 69 have to maintain the name tables. They have to maintain an entry 70 in the table for every router in the network. They have to maintain 71 this table on each router in the network. The effort to create and 72 maintain these static tables grows with the total number of routers 73 on the network. Changing the name or systemID of one router, or 74 adding one new router introduced will affect the configurations of 75 all the other routers on the network. This will make it very likely 76 that those static tables are outdated. 78 Having one table that can be updated in a centralized place would 79 be helpful. One could imagine using the DNS system for this. A 80 drawback is that during the time of network problems, the response 81 time of DNS services might not be satisfactory or the DNS services 82 might not even be available. Another possible drawback might be the 83 added complexity of DNS. Also, some DNS implementations might not 84 support A and PTR records for CLNS NSAPs. 86 A third way to build dynamic mappings would be to use the transport 87 mechanism of the routing protocol itself to advertise symbolic names 88 in IS-IS link-state PDU. This document defines a new TLV which 89 allows the IS-IS routers to include the name to systemID mapping 90 information in their LSPs. This will allow simple and reliable 91 transport of name mapping information across the IS-IS network. 93 3. The Dynamic Hostname TLV 95 The Dynamic hostname TLV is defined here as TLV type 137. 97 LENGTH - total length of the value field. 99 VALUE - a string of 1 to 255 bytes. 101 The Dynamic hostname TLV is optional. This TLV may be present in any 102 fragment of a non-pseudo node LSP. The value field identifies the 103 symbolic name of the router originating the LSP. This symbolic name 104 can be the FQDN for the router, it can be a subset of the FQDN or any 105 string operators want to use for the router. The use of FQDN or a 106 subset of it is strongly recommended. The content of this value is a 107 domain name, see RFC 2181. The string is not null-terminated. The 108 systemID of this router can be derived from the LSP identifier. 110 If this TLV is present in a pseudo node LSP, then it should not be 111 interpreted as the DNS hostname of the router. 113 4. Implementation 115 The Dynamic Hostname TLV is optional. When originating an LSP, a 116 router may decide to include this TLV in its LSP. Upon receipt of an 117 LSP with the dynamic hostname TLV, a router may decide to ignore this 118 TLV, or to install the symbolic name and systemID in its hostname 119 mapping table. 121 A router may also optionally insert this TLV in it's pseudo node LSP 122 for the association of a symbolic name to a local LAN. 124 5. Security Considerations 126 This document raises no new security issues for IS-IS. However it is 127 encouraged to use authentications for IS-IS routing protocol. The 128 authentication mechanism for IS-IS protocol is specified in [1] and 129 it is being enhanced within IETF in [2]. 131 6. Acknowledgments 133 The authors would like to thank Enke Chen and Yakov Rekhter for 134 their comments on this work. 136 7. References 138 [1] ISO, "Intermediate system to Intermediate system routeing 139 information exchange protocol for use in conjunction with the 140 Protocol for providing the Connectionless-mode Network Service 141 (ISO 8473)," ISO/IEC 10589:1992. 143 [2] draft-ietf-isis-hmac-00.txt, "IS-IS HMAC-MD5 Authentication", 144 T. Li, work in progress. 146 8. Author's Address: 148 Naiming Shen 149 Siara Systems, Inc. 150 1195 Borregas Avenue 151 Sunnyvale, CA, 94089 153 Email: naiming@siara.com 155 Henk Smit 156 Cisco Systems, Inc. 157 170 Tasman Drive 158 San Jose, CA, 95134 160 Email: hsmit@cisco.com