idnits 2.17.1 draft-ietf-ospf-cap-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 400. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 7, 2005) is 6990 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) == Unused Reference: 'RFC2119' is defined on line 297, but no explicit reference was found in the text == Unused Reference: 'T3CAP' is defined on line 320, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2370 (ref. 'OPAQUE') (Obsoleted by RFC 5250) ** Obsolete normative reference: RFC 2740 (ref. 'OSPFV3') (Obsoleted by RFC 5340) -- Duplicate reference: RFC2328, mentioned in 'RFC2119', was also mentioned in 'OSPF'. == Outdated reference: A later version (-06) exists of draft-ietf-isis-igp-p2p-over-lan-05 -- Obsolete informational reference (is this intentional?): RFC 3137 (ref. 'STUB') (Obsoleted by RFC 6987) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Lindem (Editor) 2 Internet-Draft Cisco Systems, Inc 3 Expires: August 8, 2005 N. Shen 4 Cisco Systems 5 R. Aggarwal 6 Juniper Networks 7 S. Shaffer 8 BridgePort Networks 9 JP. Vasseur 10 Cisco Systems, Inc 11 February 7, 2005 13 Extensions to OSPF for Advertising Optional Router Capabilities 14 draft-ietf-ospf-cap-06.txt 16 Status of this Memo 18 This document is an Internet-Draft and is subject to all provisions 19 of section 3 of RFC 3667. By submitting this Internet-Draft, each 20 author represents that any applicable patent or other IPR claims of 21 which he or she is aware have been or will be disclosed, and any of 22 which he or she become aware will be disclosed, in accordance with 23 RFC 3668. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 8, 2005. 43 Copyright Notice 45 Copyright (C) The Internet Society (2005). 47 Abstract 48 It is useful for routers in an OSPFv2 or OSPFv3 routing domain to 49 know the capabilities of their neighbors and other routers in the 50 routing domain. This draft proposes extensions to OSPFv2 and OSPFv3 51 for advertising optional router capabilities. A new Router 52 Information (RI) LSA is proposed for this purpose. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. OSPF Router Information (RI) LSA . . . . . . . . . . . . . . . 4 58 2.1 OSPFv2 Router Information (RI) Opaque LSA . . . . . . . . 4 59 2.2 OSPFv3 Router Information (RI) Opaque LSA . . . . . . . . 5 60 2.3 OSPF Router Capabilities TLV . . . . . . . . . . . . . . . 6 61 2.4 Assiged OSPF Router Capability Bits . . . . . . . . . . . 7 62 2.5 Flooding Scope of the Router Information LSA . . . . . . . 7 63 3. Router Information LSA Opaque Usage and Applicability . . . . 9 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 68 6.2 Informative References . . . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 70 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 71 Intellectual Property and Copyright Statements . . . . . . . . 15 73 1. Introduction 75 It is useful for routers in an OSPFv2 [OSPF] or OSPFv3 [OSPFV3] 76 routing domain to know the capabilities of their neighbors and other 77 routers in the routing domain. This can be useful for both the 78 advertisement and discovery of OSPFv2 and OSPFv3 capabilities. 79 Throughout this document, OSPF will be used when the specification is 80 applicable to both OSPFv2 and OSPFv3. Similiarly, OSPFv2 or OSPFv3 81 will be used when the text is protocol specific. 83 OSPF uses the options field in LSAs and hello packets to advertise 84 optional router capabilities. In the case of OSFPv2, all the bits in 85 this field have been allocated and there is no way to advertise new 86 optional capabilities. This document proposes extensions to OSPF to 87 advertise these optional capabilities. For existing OSPF 88 capabilities, backward compatibility issues dictate that this 89 advertisement is used primarily for informational purposes. For 90 future OSPF features, this advertimsement MAY be used as the sole 91 mechanism for advertisement and discovery. 93 2. OSPF Router Information (RI) LSA 95 OSPF routers MAY optionally advertise their optional capabilities in 96 a link-scoped, area-scoped, or AS-scoped LSA. For existing OSPF 97 capabilities, this advertisement will be used primarily for 98 informational purposes. Future OSPF features could the RI LSA as the 99 sole mechanism for advertisement and discovery. The RI LSA will be 100 originated initially when an OSPF router instance is created and 101 whenever one of the advertised capabilities is configured or changed. 103 2.1 OSPFv2 Router Information (RI) Opaque LSA 105 OSPFv2 routers will advertise a link scoped, area-scoped, or 106 AS-scoped Opaque-LSA [OPAQUE]. The OSPFv2 Router Information LSA has 107 an Opaque type of 4 and Opaque ID of 0. 109 0 1 2 3 110 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 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | LS age | Options | 9, 10 or 11 | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | 4 | 0 | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Advertising Router | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | LS sequence number | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | LS checksum | length | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | | 123 +- TLV's -+ 124 | ... | 126 The format of the TLV's within the body of a router information LSA 127 is the same as the format used by the Traffic Engineering Extensions 128 to OSPF [TE]. The LSA payload consists of one or more nested Type/ 129 Length/Value (TLV) triplets. The format of each TLV is: 131 0 1 2 3 132 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 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Type | Length | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Value... | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 The Length field defines the length of the value portion in octets 140 (thus a TLV with no value portion would have a length of zero). The 141 TLV is padded to four-octet alignment; padding is not included in 142 the length field (so a three octet value would have a length of 143 three, but the total size of the TLV would be eight octets). Nested 144 TLV's are also 32-bit aligned. For example, a one byte value would 145 have the length field set to 1, and three octets of padding would be 146 added to the end of the value portion of the TLV. Unrecognized types 147 are ignored. 149 2.2 OSPFv3 Router Information (RI) Opaque LSA 151 The OSPFv3 Router Information LSA has a function code of 12 while the 152 S1/S2 bit are dependent on the desired flooding scope for the LSA. 153 The U bit will be set indicating the OSPFv3 RI LSA should be flooded 154 even if it is not understood. The Link State ID (LSID) value for 155 this LSA is 0. This is unambiguous since an OSPFv3 router will only 156 advertise a single RI LSA per flooding scope. 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | LS age |1|S12| 12 | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | 0 (Link State ID) | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Advertising Router | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | LS sequence number | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | LS checksum | length | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | | 172 +- TLV's -+ 173 | ... | 175 The format of the TLV's within the body of a router information LSA 176 as defined in Section 2.1 178 When a new Router Information LSA TLV is defined, the specification 179 MUST explicitly state whether the TLV is applicable to OSPFv2 only, 180 OSPFv3 only, or both OSPFv2 and OSPFv3. 182 2.3 OSPF Router Capabilities TLV 184 The first defined TLV in the body of an RI LSA is the Router 185 Capabilities TLV. A router advertising an RI LSA MUST include the 186 Router Capabilities TLV and it MUST be the first TLV in the LSA. 187 Additionally, the TLV MUST accurately reflect the OSPF router's 188 capabilities in the scope it is advertised. 190 The format of the Router Capabilities TLV is as follows: 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Type | Length | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Capabilities | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Type A 16 bit field set to 1. 201 Length A 16 bit field that indicates the length of the value 202 portion in octets and will be a multiple of 4 octets 203 dependent on the number of capabilities advertised. In 204 this revision the length will be 4 denoting 4 octets of 205 capability bits. 206 Value A variable length sequence of capability flags rounded 207 to a multiple of 4 octects padded with undefined bits. 208 In this revision, there are 4 octets of capability bits. 210 The Router Capabilities TLV MAY be followed by optional TLV's that 211 further specify a capability. 213 2.4 Assiged OSPF Router Capability Bits 215 The following bits in the first capability flag have been assigned: 217 Bit Capabilities 219 0-3 Unassigned 220 4 OSPF graceful restart capable [GRACE] 221 5 OSPF graceful restart helper [GRACE] 222 6 OSPF Stub Router support [STUB] 223 7 OSPF Traffic Engineering support [TE] 224 8 OSPF point-to-point over LAN [P2PLAN] 225 9 OSPF Experimental TE [EXPTE] 226 10-31 Future assignments 228 2.5 Flooding Scope of the Router Information LSA 230 The flooding scope for a Router Information LSA is determined by the 231 LSA type. For OSPFv2, type 9 (link-scope), type 10 (area-scoped), or 232 a type 11 (AS-scoped) opaque LSA may be flooded. For OSPFv3, the 233 flooding scope is determined by the S1 and S2 bits in the LSA type. 234 If AS wide flooding scope is chosen, the originating router should 235 also advertise area scoped LSA(s) into any attached NSSA area(s). An 236 OSPF router MAY advertise different capabilities when both NSSA area 237 scoped LSA(s) and an AS scoped LSA is advertised. This allows 238 functional capabilities to be limited in scope. For example, a 239 router may be an area border router but only support traffic 240 engineering (TE) in a subset of its attached areas. The choice of 241 flooding scope is made by the advertising router and is a matter of 242 local policy. The originating router MAY advertise multiple RI LSAs 243 as long as the flooding scopes differ. TLV flooding scope rules will 244 be specified on a per-TLV basis and MUST be specified in the 245 accompanying specifications for new Router Information LSA TLVs. 247 3. Router Information LSA Opaque Usage and Applicability 249 The purpose of the Router Information (RI) LSA is to advertise 250 information relating to the aggregate OSPF router. Normally, this 251 should be confined to TLVs with a single value or very few values. 252 It is not meant to be a generic container to carry any and all 253 information. The intent is to both limit the size of the RI LSA to 254 the point where an OSPF router will always be able to contain the 255 TLVs in a single LSA and to keep the task of determining what has 256 changed between LSA instances reasonably simple. Hence, discretion 257 and sound engineering judgement MUST be adhered to when deciding 258 whether newly proposed TLV(s) in support of a new application are 259 advertised in the RI LSA or warrent the creation of an application 260 specific LSA. 262 4. Security Considerations 264 The function described in this document does not create any new 265 security issues for the OSPF protocol. Security considerations for 266 the base OSPF protocol are covered in [OSPF]. 268 5. IANA Considerations 270 The following IANA assignments are to be made from existing 271 registries: 272 1. The OSPFv2 opaque LSA type 4 will need to be reserved for the 273 OSPFv2 RI opaque LSA. 274 2. The OSPFv2 LSA type function code 18 will need to be reserved for 275 the OSPFv3 RI LSA. 277 New registries are defined for the following purposes: 278 1. Registry for OSPF RI TLVs - The value of 1 for the capabilities 279 TLV is defined herein. All TLV additions are subject to OSPF WG 280 review. 281 2. Registry for OSPF Router Capability Flags - The values defined in 282 Section 2.3. All Router Capability TLV additions are subject to 283 OSPF WG review. 285 6. References 287 6.1 Normative References 289 [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 290 1998. 292 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 294 [OSPFV3] Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 295 2740, April 1998. 297 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 298 Requirement Levels", RFC 2328, March 1977. 300 [TE] Katz, D., Yeung, D. and K. Kompella, "Traffic Engineering 301 Extensions to OSPF", RFC 3630, September 2003. 303 6.2 Informative References 305 [EXPTE] Srisuresh, P. and P. Joseph, "OSPF OSPF-TE: An 306 experimental extension to OSPF for Traffic Engineering", 307 draft-srisuresh-ospf-te-07.txt (work in progress). 309 [GRACE] Moy, J., Pillay-Esnault, P. and A. Lindem, "Graceful OSPF 310 Restart", RFC 3623, November 2003. 312 [P2PLAN] Shen, N. and A. Zinin, "Point-to-point operation over LAN 313 in link-state routing protocols", 314 draft-ietf-isis-igp-p2p-over-lan-05.txt (work in progress). 316 [STUB] Retana, A., Nguyen, L., White, R., Zinin, A. and D. 317 McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 318 2001. 320 [T3CAP] Vasseur, JP., Psenak, P., Yasukawa, S. and JL. Le Roux, 321 "OSPF MPLS Traffic Engineering Capabilities", 322 draft-vasseur-ospf-te-caps-00.txt (work in progress). 324 Authors' Addresses 326 Acee Lindem 327 Cisco Systems, Inc 328 7025 Kit Creek Road 329 Research Triangle Park, NC 27709 330 USA 332 EMail: acee@cisco.com 334 Naiming Shen 335 Cisco Systems 336 225 West Tasman Drive 337 San Jose, CA 95134 338 USA 340 EMail: naiming@cisco.com 342 Rahul Aggarwal 343 Juniper Networks 344 1194 N. Mathilda Ave. 345 Sunnyvale, CA 94089 346 USA 348 EMail: rahul@juniper.net 350 Scott Shaffer 351 BridgePort Networks 352 One Main Street, 7th Floor 353 Cambridge, MA 02142 354 USA 356 EMail: sshafferl@bridgeport-networks.com 358 Jean-Philippe Vasseur 359 Cisco Systems, Inc 360 300 Beaver Brook Road 361 Boxborough, MA 01719 362 USA 364 EMail: jpv@cisco.com 366 Appendix A. Acknowledgments 368 The idea for this work grew out of a conversation with Andrew Partan 369 and we would like to thank him for his contribution. The authors 370 would like to thanks Peter Psenak for his review and helpful comments 371 early versions of the draft. 373 Comments from Abhay Roy, Vishwas Manral, Vivek Dubey, and Adrian 374 Farrel were incorporated into the final draft version. 376 The RFC text was produced using Marshall Rose's xml2rfc tool. 378 Intellectual Property Statement 380 The IETF takes no position regarding the validity or scope of any 381 Intellectual Property Rights or other rights that might be claimed to 382 pertain to the implementation or use of the technology described in 383 this document or the extent to which any license under such rights 384 might or might not be available; nor does it represent that it has 385 made any independent effort to identify any such rights. Information 386 on the procedures with respect to rights in RFC documents can be 387 found in BCP 78 and BCP 79. 389 Copies of IPR disclosures made to the IETF Secretariat and any 390 assurances of licenses to be made available, or the result of an 391 attempt made to obtain a general license or permission for the use of 392 such proprietary rights by implementers or users of this 393 specification can be obtained from the IETF on-line IPR repository at 394 http://www.ietf.org/ipr. 396 The IETF invites any interested party to bring to its attention any 397 copyrights, patents or patent applications, or other proprietary 398 rights that may cover technology that may be required to implement 399 this standard. Please address the information to the IETF at 400 ietf-ipr@ietf.org. 402 Disclaimer of Validity 404 This document and the information contained herein are provided on an 405 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 406 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 407 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 408 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 409 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 410 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 412 Copyright Statement 414 Copyright (C) The Internet Society (2005). This document is subject 415 to the rights, licenses and restrictions contained in BCP 78, and 416 except as set forth therein, the authors retain all their rights. 418 Acknowledgment 420 Funding for the RFC Editor function is currently provided by the 421 Internet Society.