idnits 2.17.1 draft-ietf-isis-dyname-02.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 (October 1999) is 8961 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 Cisco Systems 3 draft-ietf-isis-dyname-02.txt Henk Smit 4 Expiration Date: April 2000 Cisco Systems 5 October 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 except that the right to 14 produce derivative works is not granted. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 Currently there does not exist a simple and dynamic mechanism for 35 routers running IS-IS to learn about symbolic hostnames. This 36 document defines a new TLV which allows the IS-IS routers to flood 37 their name to system ID mapping information across the IS-IS network. 39 1. Introduction 41 IS-IS uses a 1-8 byte system ID (normally 6 bytes) to represent a 42 node in the network. For management and operation reasons, network 43 operators need to check the status of IS-IS adjacencies, entries in 44 the routing table and the content of the IS-IS link state database. 45 It is obvious that, when looking at diagnostics information, 46 hexadecimal representations of systemIDs and LSP identifiers are 47 less clear than symbolic names. 49 One way to overcome this problem is to define a name-to-systemID 50 mapping on a router. This mapping can be used bidirectionally. E.g. 51 to find symbolic names for systemIDs, and to find systemIDs for 52 symbolic names. One way to build this table of mappings is by 53 static definitions. Among network administrators who use IS-IS as 54 their IGP it is current practice to define such static mappings. 56 Thus every router has to maintain a table with mappings between 57 router names and systemIDs. These tables need to contain all names 58 and systemIDs of all routers in the network. 60 There are several ways one could build such a table. One is via 61 static configurations. Another scheme that could be implemented is 62 via DNS lookups. In this document we propose a third solution. We 63 hope the proposed solution is easier and more manageable than 64 static mapping or DNS schemes. 66 2. Possible solutions 68 The obvious drawback of static configuration of mappings is the 69 issue of scalability and maintainability. The network operators 70 have to maintain the name tables. They have to maintain an entry 71 in the table for every router in the network. They have to maintain 72 this table on each router in the network. The effort to create and 73 maintain these static tables grows with the total number of routers 74 on the network. Changing the name or systemID of one router, or 75 adding one new router introduced will affect the configurations of 76 all the other routers on the network. This will make it very likely 77 that those static tables are outdated. 79 Having one table that can be updated in a centralized place would 80 be helpful. One could imagine using the DNS system for this. A 81 drawback is that during the time of network problems, the response 82 time of DNS services might not be satisfactory or the DNS services 83 might not even be available. Another possible drawback might be the 84 added complexity of DNS. Also, some DNS implementations might not 85 support A and PTR records for CLNS NSAPs. 87 A third way to build dynamic mappings would be to use the transport 88 mechanism of the routing protocol itself to advertise symbolic names 89 in IS-IS link-state PDU. This document defines a new TLV which 90 allows the IS-IS routers to include the name to systemID mapping 91 information in their LSPs. This will allow simple and reliable 92 transport of name mapping information across the IS-IS network. 94 3. The Dynamic Hostname TLV 96 The Dynamic hostname TLV is defined here as TLV type 137. 98 LENGTH - total length of the value field. 100 VALUE - a string of 1 to 255 bytes. 102 The Dynamic hostname TLV is optional. This TLV may be present in any 103 fragment of a non-pseudo node LSP. The value field identifies the 104 symbolic name of the router originating the LSP. This symbolic name 105 can be the FQDN for the router, it can be a subset of the FQDN or any 106 string operators want to use for the router. The use of FQDN or a 107 subset of it is strongly recommended. The content of this value is a 108 domain name, see RFC 2181. The string is not null-terminated. The 109 systemID of this router can be derived from the LSP identifier. 111 If this TLV is present in a pseudo node LSP, then it should not be 112 interpreted as the DNS hostname of the router. 114 4. Implementation 116 The Dynamic Hostname TLV is optional. When originating an LSP, a 117 router may decide to include this TLV in its LSP. Upon receipt of an 118 LSP with the dynamic hostname TLV, a router may decide to ignore this 119 TLV, or to install the symbolic name and systemID in its hostname 120 mapping table. 122 A router may also optionally insert this TLV in it's pseudo node LSP 123 for the association of a symbolic name to a local LAN. 125 5. Security Considerations 127 This document raises no new security issues for IS-IS. However it is 128 encouraged to use authentications for IS-IS routing protocol. The 129 authentication mechanism for IS-IS protocol is specified in [1] and 130 it is being enhanced within IETF in [2]. 132 6. Acknowledgments 134 The authors would like to thank Enke Chen and Yakov Rekhter for 135 their comments on this work. 137 7. References 139 [1] ISO, "Intermediate system to Intermediate system routeing 140 information exchange protocol for use in conjunction with the 141 Protocol for providing the Connectionless-mode Network Service 142 (ISO 8473)," ISO/IEC 10589:1992. 144 [2] draft-ietf-isis-hmac-00.txt, "IS-IS HMAC-MD5 Authentication", 145 T. Li, work in progress. 147 8. Author's Address: 149 Naiming Shen 150 Cisco Systems, Inc. 151 170 Tasman Drive 152 San Jose, CA, 95134 154 Email: naiming@cisco.com 156 Henk Smit 157 Cisco Systems, Inc. 158 170 Tasman Drive 159 San Jose, CA, 95134 161 Email: hsmit@cisco.com