idnits 2.17.00 (12 Aug 2021) /tmp/idnits55357/draft-ietf-ospf-cap-04.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 350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 340. ** 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 (November 29, 2004) is 6381 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 200, but not defined == Unused Reference: 'RFC2119' is defined on line 238, but no explicit reference was found in the text == Unused Reference: 'T3CAP' is defined on line 264, but no explicit reference was found in the text -- Duplicate reference: RFC2328, mentioned in 'RFC2119', was also mentioned in 'OSPF'. == Outdated reference: draft-srisuresh-ospf-te has been published as RFC 4973 -- Obsolete informational reference (is this intentional?): RFC 2370 (ref. 'OPAQUE') (Obsoleted by RFC 5250) == Outdated reference: draft-ietf-isis-igp-p2p-over-lan has been published as RFC 5309 -- Obsolete informational reference (is this intentional?): RFC 3137 (ref. 'STUB') (Obsoleted by RFC 6987) Summary: 5 errors (**), 0 flaws (~~), 8 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: May 30, 2005 N. Shen 4 BCN Networks, Inc 5 R. Aggarwal 6 Juniper Networks 7 S. Schaffer 8 BridgePort Networks 9 JP. Vasseur 10 Cisco Systems, Inc 11 November 29, 2004 13 Extensions to OSPF for Advertising Optional Router Capabilities 14 draft-ietf-ospf-cap-04.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 May 30, 2005. 43 Copyright Notice 45 Copyright (C) The Internet Society (2004). 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. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 10 65 5.2 Informative References . . . . . . . . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 67 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 68 Intellectual Property and Copyright Statements . . . . . . . . 13 70 1. Introduction 72 It is useful for routers in an OSPF routing domain to know the 73 capabilities of their neighbors and other routers in the OSPF routing 74 domain. This can be useful for various applications: 75 o In MPLS Traffic Engineering (TE), it can be used as a discovery 76 mechanism [TECAP] to announce a LSR's TE capabilities like Path 77 Computation Server capability (Capability of an LSR to be a Path 78 Computation Server for TE LSP path computation) or the intention 79 of an LSR to be part of a particular MPLS TE mesh group. 80 o For network management and troubleshooting. It gives operators a 81 network wide view of OSPF capabilities on different routers. The 82 presence of a capability on a given router implies that the 83 software version supports the capability and the router is 84 configured to support it. On the other hand, the absence of an 85 expected capability on a particular router can imply either 86 misconfiguration or an incorrect software version. Hence, this 87 capability information can be used to track problems resulting 88 from misconfiguration or an incorrect software version. 90 OSPF uses the options field in the hello packet to advertise optional 91 router capabilities [OSPF]. However, all the bits in this field have 92 been allocated and there is no way to advertise new optional or MPLS 93 TE capabilities. This document proposes extensions to OSPF to 94 advertise these optional capabilities. For existing OSPF 95 capabilities, this advertisement will be used primarily for 96 informational purposes. For MPLS TE features, it is used for 97 advertisement and discovery. Future OSPF features could also use 98 this mechanism for advertisement and discovery. 100 2. OSPF Router Information (RI) Opaque LSA 102 OSPF routers will optionally advertise their optional capabilities in 103 an area-scoped, local scope, or AS-scoped Opaque-LSA [OPAQUE]. If a 104 router does not advertise this LSA, it does not imply that the router 105 does not support one or more of the defined capabilities. For 106 existing OSPF capabilities, this advertisement will be used primarily 107 for informational purposes. For MPLS TE features, it is used for 108 advertisement and discovery. Future OSPF features could also use 109 this mechanism for advertisement and discovery. The RI opaque LSA 110 will be originated when one of the advertised capabilities is 111 configured or changed. 113 The Router Information LSA will have an Opaque type of 4 and Opaque 114 ID of 0. 116 0 1 2 3 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | LS age | Options | 9, 10 or 11 | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | 4 | 0 | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Advertising Router | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | LS sequence number | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | LS checksum | length | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | | 130 +- TLV's -+ 131 | ... | 133 The format of the TLV's within the body of a router information LSA 134 is the same as the format used by the Traffic Engineering Extensions 135 to OSPF [TE]. The LSA payload consists of one or more nested Type/ 136 Length/Value (TLV) triplets. The format of each TLV is: 138 0 1 2 3 139 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 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Type | Length | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Value... | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 The Length field defines the length of the value portion in octets 147 (thus a TLV with no value portion would have a length of zero). The 148 TLV is padded to four-octet alignment; padding is not included in 149 the length field (so a three octet value would have a length of 150 three, but the total size of the TLV would be eight octets). Nested 151 TLV's are also 32-bit aligned. For example, a one byte value would 152 have the length field set to 1, and three bytes of padding would be 153 added to the end of the value portion of the TLV. Unrecognized types 154 are ignored. 156 2.1 OSPF Router Capabilities TLV 158 The first defined TLV in the body of an RI opaque LSA is the Router 159 Capabilities TLV. A router advertising an RI opaque LSA SHOULD 160 include the Router Capabilities TLV and SHOULD correctly identify the 161 status of the capabilities defined in section 2.2. 163 The format of the Router Capabilities TLV is as follows: 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Type | Length | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Capabilities | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Type A 16 bit field set to 1. 174 Length A 16 bit field that indicates the length of the value 175 portion in bytes. Its set to N x 4 octets. N starts 176 from 1 and can be increased when there is a need. Each 4 177 octets are referred to as a capability flag. 178 Value This comprises one or more capability flags. For each 4 179 octets, the bits are indexed from the most significant 180 to the least significant, where each bit represents one 181 router capability. When the first 32 capabilities are 182 defined, a new capability flag will be used to 183 accommodate the next capability. 185 The Router Capabilities TLV MAY be followed by optional TLV's that 186 further specify a capability. 188 2.2 Reserved OSPF Router Capability Bits 190 The following bits in the first capability flag have been assigned: 192 Bit Capabilities 194 0-3 Reserved 195 4 OSPF graceful restart capable [GRACE] 196 5 OSPF graceful restart helper [GRACE] 197 6 OSPF Stub Router support [STUB] 198 7 OSPF Traffic Engineering support [TE] 199 8 OSPF point-to-point over LAN [P2PLAN] 200 9 OSPF Path Computation Server discovery [TECAP] 201 10 OSPF Experimental TE [EXPTE] 202 11-31 Future assignments 204 2.3 Flooding Scope of the Router Information LSA 206 The flooding scope for a Router Information opaque LSA is determined 207 by the LSA type. A type 9 (link-scope), type 10 (area-scoped), or a 208 type 11 (AS-scoped) opaque LSA may be flooded. If a type 11 opaque 209 LSA is chosen, the originating router should also advertise type 10 210 LSA(s) into any attached NSSA/stub area(s). An OSPF router MAY 211 advertise different capabilities when both NSSA/stub area type 10 212 LSA(s) and an AS scoped type 11 opaque LSA is advertised. The choice 213 of flooding scope is made by the advertising router and is a matter 214 of local policy. The originating router MAY advertise multiple RI 215 opaque LSAs as long as the flooding scopes differ. TLV flooding 216 scope rules will be specified on a per-TLV basis. 218 3. Security Considerations 220 This memo does not create any new security issues for the OSPF 221 protocol. Security considerations for the base OSPF protocol are 222 covered in [OSPF]. 224 4. IANA Considerations 226 A new opaque LSA type will need to be assigned by IANA. 227 Additionally, IANA will need to have registries for the Router 228 Information opaque LSA TLV's. The TLV assignee will be responsible 229 for allocation of any sub-TLV's for the IANA assigned TLV. All TLV's 230 and sub-TLV's will be subject to OSPF WG review. 232 5. References 234 5.1 Normative References 236 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 238 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 239 Requirement Levels", RFC 2328, March 1977. 241 [TE] Katz, D., Yeung, D. and K. Kompella, "Traffic Engineering 242 Extensions to OSPF", RFC 3630, September 2003. 244 5.2 Informative References 246 [EXPTE] Srisuresh, P. and P. Joseph, "OSPF OSPF-TE: An 247 experimental extension to OSPF for Traffic Engineering", 248 draft-srisuresh-ospf-te-07.txt (work in progress). 250 [GRACE] Moy, J., Pillay-Esnault, P. and A. Lindem, "Graceful OSPF 251 Restart", RFC 3623, November 2003. 253 [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 254 1998. 256 [P2PLAN] Shen, N. and A. Zinin, "Point-to-point operation over LAN 257 in link-state routing protocols", 258 draft-ietf-isis-igp-p2p-over-lan-05.txt (work in progress). 260 [STUB] Retana, A., Nguyen, L., White, R., Zinin, A. and D. 261 McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 262 2001. 264 [T3CAP] Vasseur, JP., Psenak, P., Yasukawa, S. and JL. Le Roux, 265 "OSPF MPLS Traffic Engineering Capabilities", 266 draft-vasseur-ospf-te-caps-00.txt (work in progress). 268 Authors' Addresses 270 Acee Lindem 271 Cisco Systems, Inc 272 7025 Kit Creek Road 273 Research Triangle Park, NC 27709 274 USA 276 EMail: acee@cisco.com 277 Naiming Shen 278 BCN Networks, Inc 279 2975 San Ysidro Way 280 Santa Clara, CA 95051 281 USA 283 EMail: naiming@bcn-inc.net 285 Rahul Aggarwal 286 Juniper Networks 287 1194 N. Mathilda Ave. 288 Sunnyvale, CA 94089 289 USA 291 EMail: rahul@juniper.net 293 Scott Schaffer 294 BridgePort Networks 295 One Main Street, 7th Floor 296 Cambridge, MA 02142 297 USA 299 EMail: sschafferl@bridgeport-networks.com 301 Jean-Philippe Vasseur 302 Cisco Systems, Inc 303 300 Beaver Brook Road 304 Boxborough, MA 01719 305 USA 307 EMail: jpv@cisco.com 309 Appendix A. Acknowledgments 311 The idea for this work grew out of a conversation with Andrew Partan 312 and we would like to thank him for his contribution. The authors 313 would like to thanks Peter Psenak for his review and helpful comments 314 early versions of the draft. 316 The RFC text was produced using Marshall Rose's xml2rfc tool. 318 Intellectual Property Statement 320 The IETF takes no position regarding the validity or scope of any 321 Intellectual Property Rights or other rights that might be claimed to 322 pertain to the implementation or use of the technology described in 323 this document or the extent to which any license under such rights 324 might or might not be available; nor does it represent that it has 325 made any independent effort to identify any such rights. Information 326 on the procedures with respect to rights in RFC documents can be 327 found in BCP 78 and BCP 79. 329 Copies of IPR disclosures made to the IETF Secretariat and any 330 assurances of licenses to be made available, or the result of an 331 attempt made to obtain a general license or permission for the use of 332 such proprietary rights by implementers or users of this 333 specification can be obtained from the IETF on-line IPR repository at 334 http://www.ietf.org/ipr. 336 The IETF invites any interested party to bring to its attention any 337 copyrights, patents or patent applications, or other proprietary 338 rights that may cover technology that may be required to implement 339 this standard. Please address the information to the IETF at 340 ietf-ipr@ietf.org. 342 Disclaimer of Validity 344 This document and the information contained herein are provided on an 345 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 346 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 347 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 348 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 349 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 350 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 352 Copyright Statement 354 Copyright (C) The Internet Society (2004). This document is subject 355 to the rights, licenses and restrictions contained in BCP 78, and 356 except as set forth therein, the authors retain all their rights. 358 Acknowledgment 360 Funding for the RFC Editor function is currently provided by the 361 Internet Society.