idnits 2.17.1 draft-ietf-ospf-cap-05.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 372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 362. ** 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 (January 7, 2005) is 7049 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) == Missing Reference: 'TECAP' is mentioned on line 201, but not defined == Unused Reference: 'RFC2119' is defined on line 257, but no explicit reference was found in the text == Unused Reference: 'T3CAP' is defined on line 283, but no explicit reference was found in the text -- Duplicate reference: RFC2328, mentioned in 'RFC2119', was also mentioned in 'OSPF'. -- Obsolete informational reference (is this intentional?): RFC 2370 (ref. 'OPAQUE') (Obsoleted by RFC 5250) == 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: 5 errors (**), 0 flaws (~~), 7 warnings (==), 10 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: July 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 January 7, 2005 13 Extensions to OSPF for Advertising Optional Router Capabilities 14 draft-ietf-ospf-cap-05.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 July 8, 2005. 43 Copyright Notice 45 Copyright (C) The Internet Society (2005). 47 Abstract 48 It is useful for routers in an OSPF routing domain to know the 49 capabilities of their neighbors and other routers in the OSPF routing 50 domain. This draft proposes extensions to OSPF for advertising 51 optional router capabilities. A new Router Information (RI) opaque 52 LSA is proposed for this purpose. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. OSPF Router Information (RI) Opaque LSA . . . . . . . . . . . 4 58 2.1 OSPF Router Capabilities TLV . . . . . . . . . . . . . . . 5 59 2.2 Reserved OSPF Router Capability Bits . . . . . . . . . . . 6 60 2.3 Flooding Scope of the Router Information LSA . . . . . . . 6 61 3. Router Information LSA Opaque Usage and Applicability . . . . 8 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 66 6.2 Informative References . . . . . . . . . . . . . . . . . . . 11 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 68 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 69 Intellectual Property and Copyright Statements . . . . . . . . 14 71 1. Introduction 73 It is useful for routers in an OSPF routing domain to know the 74 capabilities of their neighbors and other routers in the OSPF routing 75 domain. This can be useful for various applications: 76 o In MPLS Traffic Engineering (TE), it can be used as a discovery 77 mechanism [TECAP] to announce a LSR's TE capabilities like Path 78 Computation Server capability (Capability of an LSR to be a Path 79 Computation Server for TE LSP path computation) or the intention 80 of an LSR to be part of a particular MPLS TE mesh group. 81 o For network management and troubleshooting. It gives operators a 82 network wide view of OSPF capabilities on different routers. The 83 presence of a capability on a given router implies that the 84 software version supports the capability and the router is 85 configured to support it. On the other hand, the absence of an 86 expected capability on a particular router can imply either 87 misconfiguration or an incorrect software version. Hence, this 88 capability information can be used to track problems resulting 89 from misconfiguration or an incorrect software version. 91 OSPF uses the options field in the hello packet to advertise optional 92 router capabilities [OSPF]. However, all the bits in this field have 93 been allocated and there is no way to advertise new optional or MPLS 94 TE capabilities. This document proposes extensions to OSPF to 95 advertise these optional capabilities. For existing OSPF 96 capabilities, this advertisement will be used primarily for 97 informational purposes. For MPLS TE features, it is used for 98 advertisement and discovery. Future OSPF features could also use 99 this mechanism for advertisement and discovery. 101 2. OSPF Router Information (RI) Opaque LSA 103 OSPF routers will optionally advertise their optional capabilities in 104 an area-scoped, local scope, or AS-scoped Opaque-LSA [OPAQUE]. If a 105 router does not advertise this LSA, it does not imply that the router 106 does not support one or more of the defined capabilities. For 107 existing OSPF capabilities, this advertisement will be used primarily 108 for informational purposes. For MPLS TE features, it is used for 109 advertisement and discovery. Future OSPF features could also use 110 this mechanism for advertisement and discovery. The RI opaque LSA 111 will be originated when one of the advertised capabilities is 112 configured or changed. 114 The Router Information LSA will have an Opaque type of 4 and Opaque 115 ID of 0. 117 0 1 2 3 118 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 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | LS age | Options | 9, 10 or 11 | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | 4 | 0 | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Advertising Router | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | LS sequence number | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | LS checksum | length | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | | 131 +- TLV's -+ 132 | ... | 134 The format of the TLV's within the body of a router information LSA 135 is the same as the format used by the Traffic Engineering Extensions 136 to OSPF [TE]. The LSA payload consists of one or more nested Type/ 137 Length/Value (TLV) triplets. The format of each TLV is: 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Type | Length | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Value... | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 The Length field defines the length of the value portion in octets 148 (thus a TLV with no value portion would have a length of zero). The 149 TLV is padded to four-octet alignment; padding is not included in 150 the length field (so a three octet value would have a length of 151 three, but the total size of the TLV would be eight octets). Nested 152 TLV's are also 32-bit aligned. For example, a one byte value would 153 have the length field set to 1, and three bytes of padding would be 154 added to the end of the value portion of the TLV. Unrecognized types 155 are ignored. 157 2.1 OSPF Router Capabilities TLV 159 The first defined TLV in the body of an RI opaque LSA is the Router 160 Capabilities TLV. A router advertising an RI opaque LSA SHOULD 161 include the Router Capabilities TLV and SHOULD correctly identify the 162 status of the capabilities defined in section 2.2. 164 The format of the Router Capabilities TLV is as follows: 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Type | Length | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Capabilities | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 Type A 16 bit field set to 1. 175 Length A 16 bit field that indicates the length of the value 176 portion in bytes. Its set to N x 4 octets. N starts 177 from 1 and can be increased when there is a need. Each 4 178 octets are referred to as a capability flag. 179 Value This comprises one or more capability flags. For each 4 180 octets, the bits are indexed from the most significant 181 to the least significant, where each bit represents one 182 router capability. When the first 32 capabilities are 183 defined, a new capability flag will be used to 184 accommodate the next capability. 186 The Router Capabilities TLV MAY be followed by optional TLV's that 187 further specify a capability. 189 2.2 Reserved OSPF Router Capability Bits 191 The following bits in the first capability flag have been assigned: 193 Bit Capabilities 195 0-3 Reserved 196 4 OSPF graceful restart capable [GRACE] 197 5 OSPF graceful restart helper [GRACE] 198 6 OSPF Stub Router support [STUB] 199 7 OSPF Traffic Engineering support [TE] 200 8 OSPF point-to-point over LAN [P2PLAN] 201 9 OSPF Path Computation Server discovery [TECAP] 202 10 OSPF Experimental TE [EXPTE] 203 11-31 Future assignments 205 2.3 Flooding Scope of the Router Information LSA 207 The flooding scope for a Router Information opaque LSA is determined 208 by the LSA type. A type 9 (link-scope), type 10 (area-scoped), or a 209 type 11 (AS-scoped) opaque LSA may be flooded. If a type 11 opaque 210 LSA is chosen, the originating router should also advertise type 10 211 LSA(s) into any attached NSSA/stub area(s). An OSPF router MAY 212 advertise different capabilities when both NSSA/stub area type 10 213 LSA(s) and an AS scoped type 11 opaque LSA is advertised. This 214 allows functional capabilities to be limited in scope. For example, 215 a router may be an area border router but only support traffic 216 engineering (TE) in a subset of its attached areas. The choice of 217 flooding scope is made by the advertising router and is a matter of 218 local policy. The originating router MAY advertise multiple RI 219 opaque LSAs as long as the flooding scopes differ. TLV flooding 220 scope rules will be specified on a per-TLV basis. 222 3. Router Information LSA Opaque Usage and Applicability 224 The purpose of the Router Information (RI) opaque LSA is to advertise 225 information relating to the aggregate OSPF router. Normally, this 226 should be confined to TLVs with a single value or very few values. 227 It is not meant to be a generic container to carry any and all 228 information. The intent is to both limit the size of the RI LSA to 229 the point where an OSPF router will always be able to contain the 230 TLVs in a single LSA and to keep the task of determining what has 231 changed between LSA instances reasonably simple. Hence, discretion 232 and sound engineering judgement MUST be adhered to when deciding 233 whether newly proposed TLV(s) in support of a new function are 234 advertised in the RI opaque LSA or warrent the creation of a function 235 specific opaque LSA. 237 4. Security Considerations 239 The function described in this document does not create any new 240 security issues for the OSPF protocol. Security considerations for 241 the base OSPF protocol are covered in [OSPF]. 243 5. IANA Considerations 245 A new opaque LSA type will need to be assigned by IANA. 246 Additionally, IANA will need to have registries for the Router 247 Information opaque LSA TLV's. The TLV assignee will be responsible 248 for allocation of any sub-TLV's for the IANA assigned TLV. All TLV's 249 and sub-TLV's will be subject to OSPF WG review. 251 6. References 253 6.1 Normative References 255 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 257 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 258 Requirement Levels", RFC 2328, March 1977. 260 [TE] Katz, D., Yeung, D. and K. Kompella, "Traffic Engineering 261 Extensions to OSPF", RFC 3630, September 2003. 263 6.2 Informative References 265 [EXPTE] Srisuresh, P. and P. Joseph, "OSPF OSPF-TE: An 266 experimental extension to OSPF for Traffic Engineering", 267 draft-srisuresh-ospf-te-07.txt (work in progress). 269 [GRACE] Moy, J., Pillay-Esnault, P. and A. Lindem, "Graceful OSPF 270 Restart", RFC 3623, November 2003. 272 [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 273 1998. 275 [P2PLAN] Shen, N. and A. Zinin, "Point-to-point operation over LAN 276 in link-state routing protocols", 277 draft-ietf-isis-igp-p2p-over-lan-05.txt (work in progress). 279 [STUB] Retana, A., Nguyen, L., White, R., Zinin, A. and D. 280 McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 281 2001. 283 [T3CAP] Vasseur, JP., Psenak, P., Yasukawa, S. and JL. Le Roux, 284 "OSPF MPLS Traffic Engineering Capabilities", 285 draft-vasseur-ospf-te-caps-00.txt (work in progress). 287 Authors' Addresses 289 Acee Lindem 290 Cisco Systems, Inc 291 7025 Kit Creek Road 292 Research Triangle Park, NC 27709 293 USA 295 EMail: acee@cisco.com 296 Naiming Shen 297 Cisco Systems 298 225 West Tasman Drive 299 San Jose, CA 95134 300 USA 302 EMail: naiming@cisco.com 304 Rahul Aggarwal 305 Juniper Networks 306 1194 N. Mathilda Ave. 307 Sunnyvale, CA 94089 308 USA 310 EMail: rahul@juniper.net 312 Scott Shaffer 313 BridgePort Networks 314 One Main Street, 7th Floor 315 Cambridge, MA 02142 316 USA 318 EMail: sshafferl@bridgeport-networks.com 320 Jean-Philippe Vasseur 321 Cisco Systems, Inc 322 300 Beaver Brook Road 323 Boxborough, MA 01719 324 USA 326 EMail: jpv@cisco.com 328 Appendix A. Acknowledgments 330 The idea for this work grew out of a conversation with Andrew Partan 331 and we would like to thank him for his contribution. The authors 332 would like to thanks Peter Psenak for his review and helpful comments 333 early versions of the draft. 335 Comments from Abhay Roy, Vishwas Manral, and Vivek Dubey were 336 incorporated into the final draft version. 338 The RFC text was produced using Marshall Rose's xml2rfc tool. 340 Intellectual Property Statement 342 The IETF takes no position regarding the validity or scope of any 343 Intellectual Property Rights or other rights that might be claimed to 344 pertain to the implementation or use of the technology described in 345 this document or the extent to which any license under such rights 346 might or might not be available; nor does it represent that it has 347 made any independent effort to identify any such rights. Information 348 on the procedures with respect to rights in RFC documents can be 349 found in BCP 78 and BCP 79. 351 Copies of IPR disclosures made to the IETF Secretariat and any 352 assurances of licenses to be made available, or the result of an 353 attempt made to obtain a general license or permission for the use of 354 such proprietary rights by implementers or users of this 355 specification can be obtained from the IETF on-line IPR repository at 356 http://www.ietf.org/ipr. 358 The IETF invites any interested party to bring to its attention any 359 copyrights, patents or patent applications, or other proprietary 360 rights that may cover technology that may be required to implement 361 this standard. Please address the information to the IETF at 362 ietf-ipr@ietf.org. 364 Disclaimer of Validity 366 This document and the information contained herein are provided on an 367 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 368 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 369 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 370 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 371 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 372 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 374 Copyright Statement 376 Copyright (C) The Internet Society (2005). This document is subject 377 to the rights, licenses and restrictions contained in BCP 78, and 378 except as set forth therein, the authors retain all their rights. 380 Acknowledgment 382 Funding for the RFC Editor function is currently provided by the 383 Internet Society.