idnits 2.17.1 draft-liu-isis-auto-conf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character 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 104: '... o IS-IS SHOULD be enabled on all in...' RFC 2119 keyword, line 105: '...tions, interface MAY be excluded if it...' RFC 2119 keyword, line 108: '...IS-IS interfaces MUST be auto-configur...' RFC 2119 keyword, line 125: '...ring, this field MUST be 0 in 13 octet...' RFC 2119 keyword, line 130: '...figuring, this field SHOULD be the MAC...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3839 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. 'OSPFv3AC' Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group B. Liu 2 Internet Draft Huawei Technologies Co., Ltd 3 Intended status: Proposed Standard October 21, 2013 4 Expires: April 24, 2014 6 ISIS Auto-Configuration 7 draft-liu-isis-auto-conf-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF). Note that other groups may also distribute working 16 documents as Internet-Drafts. The list of current Internet-Drafts is 17 at http://datatracker.ietf.org/drafts/current/. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 This Internet-Draft will expire on April 24, 2014. 26 Copyright Notice0 28 Copyright (c) 2012 IETF Trust and the persons identified as the 29 document authors. All rights reserved. 31 This document is subject to BCP 78 and the IETF Trust's Legal 32 Provisions Relating to IETF Documents 33 (http://trustee.ietf.org/license-info) in effect on the date of 34 publication of this document. Please review these documents 35 carefully, as they describe your rights and restrictions with respect 36 to this document. Code Components extracted from this document must 37 include Simplified BSD License text as described in Section 4.e of 38 the Trust Legal Provisions and are provided without warranty as 39 described in the Simplified BSD License. 41 Abstract 43 This document describes mechanisms for IS-IS to be self-configuring. 44 Such mechanisms could reduce the management burden to configure a 45 network. One obvious environment that could benefit from these 46 mechanisms is IPv6 home network where plug-and-play would be expected. 47 Besides home network, some simple enterprise/ISP networks might also 48 potentially benefit from the self-configuring mechanisms. 50 Table of Contents 52 1. Introduction ................................................. 3 53 2. IS-IS Default Configuration .................................. 3 54 3. IS-IS NET Generation.......................................... 4 55 4. IS-IS NET Duplication Detection and Resolution ............... 4 56 4.1. Router-Hardware-Fingerprint TLV ......................... 4 57 4.2. NET Duplication Detection and Resolution ................ 5 58 5. Security Considerations ...................................... 5 59 6. IANA Considerations .......................................... 5 60 7. Acknowledgments .............................................. 5 61 8. References ................................................... 6 62 8.1. Normative References .................................... 6 64 1. Introduction 66 This memo describes mechanisms for IS-IS [RFC1195][RFC5308] to be 67 auto-configuring. Such mechanisms could reduce the management burden 68 to configure a network. One example is home network where plug-and- 69 play would be expected. Besides home network, some simple 70 enterprise/ISP networks might also potentially benefit from the auto- 71 configuring mechanisms. 73 The auto-configuring mechanisms are designed based on IPv6-only 74 environment. Some IPv4 environments might also applicable, but they 75 are not specifically considered. 77 The following aspects of IS-IS auto-configuration are described: 79 1. IS-IS Default Configuration 81 2. IS-IS NET self-generation 83 3. IS-IS Adjacency Formation 85 However, this draft does not provide a completely configuration-free 86 alternative to the IS-IS protocol, since some plan work by human so 87 far is very difficult to be achieved through algorithm. The following 88 features of IS-IS are not supported by this document: 90 o Auto-configuring multiple IS-IS processes. The auto-configuration 91 mechanisms only support configuring a single process. 93 o Route between multiple IS-IS areas. The auto-configuration 94 mechanisms only support routers that are within a single area. 96 o Auto-configuring multiple operation levels. The auto-configuration 97 mechanisms only support level-1 operation mode. 99 o This document does not consider interoperability with other routing 100 protocols. 102 2. IS-IS Default Configuration 104 o IS-IS SHOULD be enabled on all interfaces in a router as default. 105 For some specific situations, interface MAY be excluded if it is a 106 clear that running IS-IS on the interface is not required. 108 o IS-IS interfaces MUST be auto-configured to an interface type 109 corresponding to their layer-2 capability. For example, Ethernet 110 interfaces will be auto-configured as broadcast networks and Point- 111 to-Point Protocol (PPP) interfaces will be auto-configured as Point- 112 to-Point interfaces. 114 3. IS-IS NET Generation 116 In IS-IS, a router (known as an IS) is identified by an Network 117 Entity Title (NET) which is the address of a Network Service Access 118 Point (NSAP) and represented with an IS-IS specific address format. 119 The NSAP is a logical entity which represents an instance of the IS- 120 IS protocol running on an IS. 122 The NET consists of the following three parts: 124 Area address: This field is 1 to 13 octets in length. In IS-IS auto- 125 configuring, this field MUST be 0 in 13 octets length. 127 System ID: This field follows the area address field, and is 6 octets 128 in length. As specified in IS-IS protocol, this field must be unique 129 among all level-1 routers in the same area when the IS operates at 130 Level 1. In IS-IS auto-configuring, this field SHOULD be the MAC 131 address of one IS-IS enabled interface. 133 NSEL: This field is the N-selector, and is 1 octet in length. In IS- 134 IS auto-configuring, tt must be set to "00". 136 4. IS-IS NET Duplication Detection and Resolution 138 As described in Section 3, in IS-IS auto-configuring the NETs are 139 distinguished by the System ID field in which it is a MAC address. So 140 for IS-IS neighbors' NET duplication, it is equal to MAC address 141 duplication in a LAN, which means a serious problem that devices 142 would need to be changed. IS-IS auto-configuring does not consider 143 this situation. 145 For the non-neighbor NET duplication detection within an area, this 146 document utilizes a TLV as following to do it. 148 4.1. Router-Hardware-Fingerprint TLV 150 The Router-Hardware-Fingerprint TLV is defined in [OSPFv3AC]. This 151 document re-uses it to achieve NET duplication detection. 153 0 1 2 3 154 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | TBD | >32 | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Router Hardware Fingerprint | 160 o 161 o 162 o 163 | | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Figure 1 Router-Hardware-Fingerprint TLV Format 168 As defined in [OSPFv3AC], the contents of the hardware fingerprint 169 should be some combination of CPU ID, or serial number(s) that 170 provides an extremely high probability of uniqueness. It MUST be 171 based on hardware attributes that will not change across hard and 172 soft restarts. Note that, since the TLV is to detect MAC address 173 based NET duplication, the TLV content MUST NOT use MAC address only 174 again. Implementations SHOULD use other information exclude MAC 175 address. 177 4.2. NET Duplication Detection and Resolution 179 The Router-Hardware-Fingerprint TLV MUST be included in the first 180 originated level-1 LSP by every auto-configuring routers. An IS-IS 181 auto-configuring router MUST compare a received self-originated LSP's 182 Router-Hardware-Fingerprint TLV against its own one. If the they are 183 not equal, there is a NET duplication and the Router with the 184 numerically smaller router hardware fingerprint MUST generate a new 185 NET. 187 After selecting a new NET, the LSP with the prior duplicate NET MUST 188 be purged. And any IS-IS neighbor adjacencies MUST be reestablished. 190 5. Security Considerations 192 TBD. 194 6. IANA Considerations 196 The Router Hardware Fingerprint TLV type code needs an assignment. 198 7. Acknowledgments 200 Many useful comments and contributions were made by Sheng Jiang. 202 This document was inspired by [OSPFv3AC]. 204 8. References 206 8.1. Normative References 208 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 209 dual environments", RFC 1195, December 1990. 211 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 212 2008. 214 [OSPFv3AC] Lindem, A., and J. Arkko, "OSPFv3 Auto-Configuration", 215 Work in Progress, October 2013 217 Authors' Addresses 219 Bing Liu 220 Huawei Technologies Co., Ltd 221 Q14, Huawei Campus 222 No.156 Beiqing Rd. 223 Hai-Dian District, Beijing 100095 224 P.R. China 226 Email: leo.liubing@huawei.com