idnits 2.17.1 draft-venkata-ospf-dynamic-hostname-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 5 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. ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 122: '...mic Hostname LSA MAY ignore sending an...' 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 (February 2003) is 7734 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) ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) ** Obsolete normative reference: RFC 2763 (Obsoleted by RFC 5301) Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF Working Group Venkata Naidu 3 Internet Draft Sanjay Harwani 4 Expiration Date: Marconi Communications 5 File name: draft-venkata-ospf-dynamic-hostname-01.txt February 2003 7 Dynamic Hostname Exchange Mechanism 8 for OSPF 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. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 Currently, there does not exist a simple and dynamic mechanism for 32 routers running OSPF to learn about symbolic hostnames just like 33 ISIS. This document defines a new Area Scope and AS Scope Opaque 34 LSAs which allows the OSPF routers to flood their name to Router 35 ID mapping information across the OSPF network. 37 1. Introduction 39 OSPF uses a 4 byte Router ID to represent a node in the network. For 40 management and operation reasons, network operators need to check the 41 status of OSPF adjacencies, entries in the routing table and the 42 content of the OSPF link state database. It is obvious that, when 43 looking at diagnostics information, (dotted)decimal representations 44 of Router IDs are less clear than symbolic names. 46 One way to overcome this problem is to define a name-to-Router ID 47 mapping on a router. This mapping can be used bidirectionally. E.g., 48 to find symbolic names for Router IDs, and to find Router IDs for 49 symbolic names. One way to build this table of mappings is by static 50 definitions. 52 Thus every router has to maintain a table with mappings between 53 router names and Router IDs. These tables need to contain all names 54 and Router IDs of all routers in the network. 56 2. Possible solutions 58 All possible solutions are described in [RFC2763]. 60 3. Implementation 62 This extension makes use of the Opaque LSA [RFC2370]. Three types 63 of Opaque LSAs exist, each of which has different flooding scope. 64 This proposal uses only Type 10 and Type 11 LSAs, which have area 65 And AS flooding scope respectively. 67 The Dynamic Hostname LSAs are optional. Upon receipt of an LSA with 68 the dynamic hostname TLV, a router may decide to ignore this TLV, 69 or to install the symbolic name and Router ID in its hostname 70 mapping table. 72 3.1 The Area Scope Dynamic Hostname LSA Format 74 Area Scope Opaque LSA is extended to flood the new Dynamic 75 hostname LSA defined here as LSA ID TBD. 77 The Dynamic Hostname LSA starts with the standard LSA header: 79 0 1 2 3 80 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 81 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 82 | LS age | Options | 10 | 83 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 84 | TBD | Reserved | Instance | 85 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 | Advertising Router | 87 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 88 | LS sequence number | 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 | LS checksum | Length | 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 Length - total length of Dynamic Hostname LSA. 95 3.1.1. TLV Header 97 The LSA payload consists of one or more nested Type/Length/Value 98 (TLV) triplets for extensibility. The format of each TLV is: 100 0 1 2 3 101 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | Type | Length | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Value... | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 Type - Dynamic Host Name TLV Type (TBD) 110 Length - total length of the value field. 112 Value - a string of 1 to 255 bytes. 114 The value field identifies the symbolic name of the router originating 115 the LSA. The string is not null-terminated. The Router ID of this 116 router can be derived from the LSA header. 118 3.2 The AS Scope Dynamic Hostname LSA Format 120 AS Scope Opaque LSA is extended to flood the new Dynamic 121 hostname LSA defined here as LSA ID TBD. A Router originating 122 AS scope Dynamic Hostname LSA MAY ignore sending an Area scope 123 Dynamic Hostname LSA, because AS scope LSAs are flooded through 124 out OSPF domain transparently (except stub and NSSA areas). 126 The Dynamic Hostname LSA starts with the standard LSA header: 128 0 1 2 3 129 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | LS age | Options | 10 | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | TBD | Reserved | Instance | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Advertising Router | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | LS sequence number | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | LS checksum | Length | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Length - total length of Dynamic Hostname LSA. 144 3.2.1. TLV Header 146 The LSA payload consists of one or more nested Type/Length/Value 147 (TLV) triplets for extensibility. The format of each TLV is: 149 0 1 2 3 150 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Type | Length | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Value... | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Type - Dynamic Host Name TLV Type (TBD) 159 Length - total length of the value field. 161 Value - a string of 1 to 255 bytes. 163 The value field identifies the symbolic name of the router originating 164 the LSA. The string is not null-terminated. The Router ID of this 165 router can be derived from the LSA header. 167 4. Security Considerations 169 This document raises no new security issues for OSPF. However, it is 170 encouraged to use authentications for OSPF routing protocol. The 171 authentication mechanism for OSPF protocol is specified in [RFC2328]. 173 5. Acknowledgments 175 The authors of this document do not make any claims on the originality 176 of the ideas described. The authors would like to thank authors of 177 similar work done in ISIS RFC 2763. 179 6. References 181 [RFC2328] Moy, J., "OSPF Version 2," RFC 2328, Ascend Communications 182 Corp., April 1998. 184 [RFC2370] Coltun, Rob, "The OSPF Opaque LSA Option," RFC 2370, FORE 185 Systems, July 1998. 187 [RFC2763] Shen, Naiming and Smit, Henk, "Dynamic Hostname Exchange 188 Mechanism for ISIS," RFC 2763, February 2000. 190 7. Authors' Addresses 192 Venkata Naidu 193 Phone: (703) 245-4562 194 EMail: Venkata.Naidu@Marconi.com 196 Sanjay Harwani 197 Phone: (703) 245-4587 198 EMail: Sanjay.Harwani@Marconi.com 200 Marconi Communications 201 1595 Spring Hill Rd, 5th Floor 202 Vienna VA 22031