idnits 2.17.00 (12 Aug 2021) /tmp/idnits63075/draft-raggarwa-igp-cap-00.txt: ** The Abstract section seems to be numbered 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 == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 61 lines 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 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 74: '... included in the IS-IS LSP packet [6]. It SHOULD reside in fragment...' RFC 2119 keyword, line 78: '... LSP, the router SHOULD set all the de...' RFC 2119 keyword, line 172: '... the Router Capability TLV. It MUST be...' RFC 2119 keyword, line 174: '... SHOULD set defined its correspondin...' 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '7' is defined on line 245, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2370 (ref. '1') (Obsoleted by RFC 5250) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 3137 (ref. '5') (Obsoleted by RFC 6987) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Acee Lindem (Redback Networks) 3 Internet Draft Naiming Shen (Redback Networks) 4 Expiration Date: November 2002 Rahul Aggarwal (Redback Networks) 5 Scott Shaffer (Genuity, Inc.) 7 Extensions to IS-IS and OSPF for Advertising 8 Optional Router Capabilities 10 draft-raggarwa-igp-cap-00.txt 12 1. Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026, except that the right to 16 produce derivative works is not granted. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 2. Abstract 35 It is useful for routers in a IGP domain to know of the capabilities 36 of their IGP neighbors and/or other routers in the domain. This draft 37 proposes extensions to IS-IS and OSPF for advertising optional router 38 capabilities. We define an optional Router Capability TLV for IS-IS, 39 while for OSPF we define an optional Router Capability Opaque LSA. 41 3. Motivation 43 It is useful for routers in a IGP domain to know of the capabilities 44 of their IGP neighbors and/or other routers in the domain. A domain 45 refers to the IGP link state packet flooding domain. Hence for OSPF a 46 domain implies the same area, while for IS-IS it implies the same 47 level. It gives operators a domain wide view of IGP capabilities on 48 different routers in the network. This can be fairly useful for 49 network management and troubleshooting. Here IGP domain refers to 50 the IGP link state packet flooding domain, 52 The presence of a capability on a given router implies that the 53 software version supports the capability and the router is configured 54 to support it. On the other hand the absence of an expected 55 capability on a particular router can imply either mis-configuration 56 or an incorrect software version. Hence this capability information 57 can be used to track problems resulting from mis-configuration or an 58 incorrect software version. 60 There is no existing mechanism in IS-IS to advertise optional router 61 capabilities. On the other hand OSPF uses the options field in the 62 hello packet to advertise optional router capabilities [2]. However 63 this attribute is not extensible for advertising optional 64 capabilities such as hitless graceful restart. We propose extensions 65 to IS-IS and OSPF for advertising these optional capabilities. For 66 current IS-IS and OSPF capabilities this advertisement will be used 67 primarily for informational purposes. Conceivably, future IS-IS and 68 OSPF capability advertisements could be used for other purposes. 70 4. IS-IS Router Capability TLV 72 IS-IS routers will optionally advertise their optional capabilities 73 in an IS-IS Router Capability TLV of type 242. This optional TLV is 74 included in the IS-IS LSP packet [6]. It SHOULD reside in fragment 75 zero of the LSPs of each level. If a router does not advertise this 76 TLV in any of its LSP packets, it does not imply that the router does 77 not support one or more of the defined capabilities. If this TLV is 78 included in a LSP, the router SHOULD set all the defined bits 79 corresponding to the capabilities which the software supports, unless 80 they are explicitly configured off. 82 The following figure depicts the format of the IS-IS Router 83 Capability TLV. 85 0 1 2 3 86 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 87 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 88 | Type | Length | Value... | 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 Type A 8 bit field set to 242. 92 Length A 8 bit field that indicates the length of the Value 93 portion in bytes. Its set to N x 4 octets. N starts from 94 1 and can be increased when there is a need. Each 4 95 octets are referred to as a capability flag. 96 Value This comprises one or more capability flags. For each 4 97 octets, the bits are indexed from the most significant to 98 the least significant, where each bit represents one 99 router capability. When the first 32 capabilities are 100 defined, a new capability flag will be used to 101 accommodate the next capability. 103 4.1 Reserved IS-IS Router Capability Bits 105 We have assigned some pre-determined bits to the first capability 106 flag. 108 Bit Capabilities 110 0-3 Reserved 111 4 IS-IS hitless graceful restart capable [9] 112 5 IS-IS and BGP blackhole avoidance capable [11] 113 6 IS-IS wide metric processing capable [8] 114 7 IS-IS hmac-md5 authentication capable [10] 115 8 IS-IS Traffic Engineering support [8] 116 9 IS-IS point-to-point over LAN [12] 117 10-31 For future assignments 118 5. OSPF Router Information LSA 120 OSPF routers will optionally advertise their optional capabilities 121 in an area-scoped Opaque-LSA [1]. If a router does not advertise 122 this LSA, it does not imply that the router does not support one or 123 more of the defined capabilities. For current OSPF capabilities, 124 the advertisement will be used solely for information purposes. 125 Conceivably, future OSPF capabilities could require other capability 126 LSA advertisement. The LSA is area-scoped to be consistent with the 127 scope of the OSPF router LSA [2]. The Router Information LSA will 128 be originated at startup and re-originated when router capabilities 129 change or when periodically refreshed. 131 The Router Information LSA will have an Opaque type of 4 and Opaque 132 ID of 0. 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | LS age | Options | 10 | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | 4 | 0 | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Advertising Router | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | LS sequence number | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | LS checksum | length | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | | 148 +- TLVs -+ 149 | ... | 151 The format of the TLVs within the body of a Router Information LSA is 152 the same as the TLV format used by the Traffic Engineering Extensions 153 to OSPF [3]. The TLV header consists of a 16-bit Type field and a 154 16-bit length field, and is followed by zero or more bytes of value. 155 The length field indicates the length of the value portion in bytes. 156 The value portion is padded to four-octet alignment, but the padding 157 is not included in the length field. For example, a one byte value 158 would have the length field set to 1, and three bytes of padding 159 would be added to the end of the value portion of the TLV. 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Type | Length | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Value... | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 5.1 OSPF Router Capability TLV 171 Initially, only a single TLV may appear in the body of a Router 172 Information LSA. This is the Router Capability TLV. It MUST be 173 included. A router advertising an optional Router Information LSA 174 SHOULD set defined its corresponding to the supported optional 175 capabilities, unless they are explicitly configured off, in the 176 Router Capability TLV. 178 The format of the Router Capability TLV is as follows : 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Type | Length | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Value... | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Type A 16 bit field set to 1. 189 Length A 16 bit field that indicates the length of the Value 190 portion in bytes. Its set to N x 4 octets. N starts from 191 1 and can be increased when there is a need. Each 4 octets 192 are referred to as a capability flag. 193 Value This comprises one or more capability flags. For each 4 194 octets, the bits are indexed from the most significant to 195 the least significant, where each bit represents one 196 router capability. When the first 32 capabilities are 197 defined, a new capability flag will be used to 198 accommodate the next capability. 200 5.2 Reserved OSPF Router Capability Bits 202 We have assigned some pre-determined bits to the first capability 203 flag. 205 Bit Capabilities 207 0-3 Reserved 208 4 Hitless graceful restart capable [4] 209 5 OSPF hitless graceful restart helper [4] 210 6 Stub Router support [5] 211 7 Traffic Engineering support [3] 212 8 OSPF point-to-point over LAN [12] 213 8-31 Future assignments 215 6. Security Consideration 217 This document does not introduce new security issues. The security 218 considerations pertaining to the original IS-IS and OSPF protocols 219 remain relevant. 221 7. Acknowledgments 223 The idea for this work grew out of a conversation with Andrew Partan 224 and we would like to thank him for his contribution. 226 8. References 228 [1] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 229 1998. 231 [2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 233 [3] Katz, D., D. Yeung and K. Kompella, "Traffic Engineering 234 Extensions to OSPF", Internet Draft, work in progress. 236 [4] Moy, J., "OSPF Hitless OSPF Restart", Internet Draft, work in 237 progress. 239 [5] Retana, A., et al, "OSPF Stub Router Advertisement", 240 RFC 3137, June 2001. 242 [6] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, 243 December 1990. 245 [7] ISO, "Intermediate system to Intermediate system routeing 246 information exchange protocol for use in conjunction with the 247 Protocol for providing the Connectionless-mode Network 248 Service (ISO 8473)," ISO/IEC 10589:1992. 250 [8] Li, T. et al, "IS-IS Extensions for Traffic Engineering", 251 Internet Draft, work in Progress. 253 [9] Shand, M., "Restart Signaling for IS-IS", Internet Draft, work 254 in Progress. 256 [10] Li, T., "IS-IS Cryptographic Authentication", Internet Draft, 257 work in progress. 259 [11] McPherson, D., "IS-IS Transient Blackhole Avoidance", Internet 260 Draft, work in progress. 262 [12] N. Shen, et al, "Point-to-point operation over LAN in 263 link-state-routing protocols", Internet Draft, work in 264 progress. 266 9. Author Information 268 Acee Lindem 269 Redback Networks 270 350 Holger Way 271 San Jose, CA 95134 272 e-mail: acee@redback.com 274 Naiming Shen 275 Redback Networks 276 350 Holger Way 277 San Jose, CA 95134 278 e-mail: naiming@redback.com 280 Rahul Aggarwal 281 Redback Networks 282 350 Holger Way 283 San Jose, CA 95134 284 e-mail: rahul@redback.com 286 Scott Shaffer 287 Genuity, Inc. 288 3 Van de Graaff Drive 289 PO Box 3073 290 Burlington, MA 01803 291 e-mail: sshaffer@genuity.com