idnits 2.17.1 draft-ietf-ospf-cap-02.txt: 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 4 longer pages, the longest (page 4) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. 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 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) ** Obsolete normative reference: RFC 2370 (ref. '1') (Obsoleted by RFC 5250) -- Obsolete informational reference (is this intentional?): RFC 3137 (ref. '6') (Obsoleted by RFC 6987) -- No information found for draft-vasseur-mpls-computation-rsvp-te - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Acee Lindem 3 Internet Draft Naiming Shen 4 Expiration Date: December 2004 Redback Networks 5 Rahul Aggarwal 6 Juniper Networks 7 Scott Shaffer 8 Level 3 Communications 9 JP Vasseur 10 Cisco Systems, Inc 12 Extensions to OSPF for Advertising Optional Router Capabilities 13 draft-ietf-ospf-cap-02.txt 15 Status of this Memo 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or IPR claims of which I am aware have been disclosed, and 19 any of which I become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as ``work in progress.'' 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 It is useful for routers in an OSPF routing domain to know the 41 capabilities of their neighbors and other routers in the OSPF 42 routing domain. This draft proposes extensions to OSPF for 43 advertising optional router capabilities. A new Router 44 Information (RI) opaque LSA is proposed for this purpose. 46 Conventions used in this document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 50 this document are to be interpreted as described in RFC-2119 [3]. 52 1. Motivation 54 It is useful for routers in an OSPF routing domain to know the 55 capabilities of their neighbors and other routers in the OSPF 56 routing domain. This can be useful for various applications: 58 o In MPLS Traffic Engineering (TE), it can be used as a discovery 59 mechanism [7, 8] to announce a LSR's TE capabilities like 60 Path Computation Server capability (Capability of an LSR to be 61 a Path Computation Server for TE LSP path computation) or the 62 intention of an LSR to be part of a particular MPLS TE mesh group. 64 o For network management and troubleshooting. It gives operators a 65 network wide view of OSPF capabilities on different routers. 66 The presence of a capability on a given router implies 67 that the software version supports the capability and the router 68 is configured to support it. On the other hand, the absence of an 69 expected capability on a particular router can imply either 70 misconfiguration or an incorrect software version. Hence, this 71 capability information can be used to track problems resulting from 72 misconfiguration or an incorrect software version. 74 OSPF uses the options field in the hello packet to advertise optional 75 router capabilities [1]. However, all the bits in this field have 76 been allocated and there is no way to advertise new optional 77 or MPLS TE capabilities. This document proposes extensions to OSPF 78 to advertise these optional capabilities. For existing OSPF 79 capabilities, this advertisement will be used primarily for 80 informational purposes. For MPLS TE features, it is used for 81 advertisement and discovery. Future OSPF features could also 82 use this mechanism for advertisement and discovery. 84 2. OSPF Router Information (RI) Opaque LSA 86 OSPF routers will optionally advertise their optional capabilities 87 in an area-scoped, local scope, or AS-scoped Opaque-LSA [2]. 88 If a router does not advertise this LSA, it does not imply that the 89 router does not support one or more of the defined capabilities. 90 For existing OSPF capabilities, this advertisement will be used 91 primarily for informational purposes. For MPLS TE features, 92 it is used for advertisement and discovery. Future OSPF features 93 could also use this mechanism for advertisement and discovery. 94 The RI opaque LSA will be originated when one of the advertised 95 capabilities is configured or changed. 97 The Router Information LSA will have an Opaque type of 4 and Opaque 98 ID of 0. 100 0 1 2 3 101 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 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | LS age | Options | 9, 10 or 11 | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | 4 | 0 | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Advertising Router | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | LS sequence number | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | LS checksum | length | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | | 114 +- TLV's -+ 115 | ... | 117 Figure 2. OSPF Router Information LSA 119 The format of the TLV's within the body of a router information LSA 120 is the same as the format used by the Traffic Engineering 121 Extensions to OSPF [4]. The LSA payload consists of one or 122 more nested Type/Length/Value (TLV) triplets. The format of 123 each TLV is: 125 0 1 2 3 126 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 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Type | Length | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Value... | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 Figure 3. TLV Format 135 The Length field defines the length of the value portion in octets 136 (thus a TLV with no value portion would have a length of zero). The 137 TLV is padded to four-octet alignment; padding is not included in 138 the length field (so a three octet value would have a length of 139 three, but the total size of the TLV would be eight octets). Nested 140 TLV's are also 32-bit aligned. For example, a one byte value 141 would have the length field set to 1, and three bytes of padding 142 would be added to the end of the value portion of the TLV. 143 Unrecognized types are ignored. 145 2.1 OSPF Router Capabilities TLV 147 The first defined TLV in the body of a RI opaque LSA is 148 the Router Capabilities TLV. A router advertising a RI opaque LSA 149 SHOULD include the Router Capabilities TLV and SHOULD correctly 150 identify the status of the capabilities defined in section 2.2. 152 The format of the Router Capabilities TLV is as follows: 154 0 1 2 3 155 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 | Type | Length | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Capabilities | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 Figure 4. OSPF Router Capabilities TLV 164 Type A 16 bit field set to 1. 165 Length A 16 bit field that indicates the length of the value 166 portion in bytes. Its set to N x 4 octets. N starts 167 from 1 and can be increased when there is a need. Each 4 168 octets are referred to as a capability flag. 169 Value This comprises one or more capability flags. For each 4 170 octets, the bits are indexed from the most significant 171 to the least significant, where each bit represents one 172 router capability. When the first 32 capabilities are 173 defined, a new capability flag will be used to 174 accommodate the next capability. 176 The Router Capabilities TLV MAY be followed by optional TLV's that 177 further specify a capability. 179 2.2 Reserved OSPF Router Capability Bits 181 The following bits in the first capability flag have been 182 assigned: 184 Bit Capabilities 186 0-3 Reserved 187 4 OSPF graceful restart capable [5] 188 5 OSPF graceful restart helper [5] 189 6 Stub Router support [6] 190 7 Traffic Engineering support [4] 191 8 OSPF point-to-point over LAN [9] 192 9 OSPF Path Computation Server discovery [7, 8] 193 10-31 Future assignments 195 2.3 Flooding Scope of the Router Information LSA 197 The flooding scope of the Router Information opaque LSA is determined 198 by the LSA type. A type 9 (link-scope), type 10 (area-scoped), or a 199 type 11 (AS-scoped) opaque LSA may be used. If a type 11 opaque LSA 200 is chosen, the originating router should also advertise type 10 201 LSA(s) into any attached NSSA/stub area(s). An OSPF router MAY 202 advertise different values in advertised NSSA/stub area type 10 203 LSA(s) and its AS scoped type 11 opaque LSA. The choice of 204 flooding scope is made by the advertising router and is a matter of 205 local policy. The originating router MAY advertise multiple Router 206 Information LSAs as long as the flooding scope differs. TLV 207 flooding scope rules will be specified on a per-TLV basis. 209 3. Security Consideration 211 This memo does not create any new security issues for the OSPF 212 protocol. Security considerations for the base OSPF protocol are 213 covered in [1]. 215 4. Acknowledgments 217 The idea for this work grew out of a conversation with Andrew Partan 218 and we would like to thank him for his contribution. The authors 219 would like to thanks Peter Psenak for his review and helpful 220 comments early versions of the draft. 222 Funding for the RFC Editor function is currently provided by the 223 Internet Society. 225 5. IANA Considerations 227 A new opaque LSA type will need to be assigned by IANA. 228 Additionally, IANA will need to have registries for the Router 229 Information opaque LSA TLV's. The TLV assignee will be responsible 230 for allocation of any sub-TLV's for the IANA assigned TLV. All 231 TLV's and sub-TLV's will be subject to OSPF WG review. 233 6. References 235 Normative References 237 [1] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 238 1998. 240 [2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 242 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 243 Level", BCP 14, RFC 2119, March 1997. 245 Informative References 247 [4] Katz, D., D. Yeung and K. Kompella, "Traffic Engineering 248 Extensions to OSPF", RFC 3630, September 2003. 250 [5] Moy, J., P. Pillay-Esnault and A. Lindem, "OSPF Graceful 251 OSPF Restart", RFC 3623, November 2003. 253 [6] Retana, A., et al, "OSPF Stub Router Advertisement", 254 RFC 3137, June 2001. 256 [7] Vasseur, J., P. Psenak, "Traffic Engineering Capability TLV 257 for OSPF", Internet Draft, work in progress. 259 [8] Vasseur, J., et al, "RSVP Path computation request and reply 260 messages", draft-vasseur-mpls-computation-rsvp-te-03.txt, 261 work in progress 263 [9] N. Shen, et al, "Point-to-point operation over LAN in 264 link-state-routing protocols", Internet Draft, work in 265 progress. 267 9. Author Information 269 Acee Lindem 270 Redback Networks 271 350 Holger Way 272 San Jose, CA 95134 273 e-mail: acee@redback.com 275 Naiming Shen 276 Redback Networks 277 350 Holger Way 278 San Jose, CA 95134 279 e-mail: naiming@redback.com 281 Rahul Aggarwal 282 Juniper Networks 283 1194 N. Mathilda Ave. 284 Sunnyvale, CA 94089 USA 285 e-mail: rahul@juniper.net 287 Scott Shaffer 288 Level 3 Communications 289 e-mail: scott.shaffer@level3.com 291 JP Vasseur 292 Cisco Systems, Inc. 293 300 Apollo Drive 294 Chelmsford, MA 01824 295 e-mail: jpv@cisco.com 296 10. IPR Notice 298 The IETF takes no position regarding the validity or scope of any 299 intellectual property or other rights that might be claimed to 300 pertain to the implementation or use of the technology described in 301 this document or the extent to which any license under such rights 302 might or might not be available; neither does it represent that it 303 has made any effort to identify any such rights. Information on the 304 IETF's procedures with respect to rights in standards-track and 305 standards-related documentation can be found in BCP-11. Copies of 306 claims of rights made available for publication and any assurances of 307 licenses to be made available, or the result of an attempt made to 308 obtain a general license or permission for the use of such 309 proprietary rights by implementors or users of this specification can 310 be obtained from the IETF Secretariat. 312 The IETF invites any interested party to bring to its attention any 313 copyrights, patents or patent applications, or other proprietary 314 rights which may cover technology that may be required to practice 315 this standard. Please address the information to the IETF Executive 316 Director. 318 11. Full Copyright Notice 320 Copyright (C) The Internet Society (2003). All Rights Reserved. 322 This document and translations of it may be copied and furnished to 323 others, and derivative works that comment on or otherwise explain it 324 or assist in its implementation may be prepared, copied, published 325 and distributed, in whole or in part, without restriction of any 326 kind, provided that the above copyright notice and this paragraph are 327 included on all such copies and derivative works. However, this 328 document itself may not be modified in any way, such as by removing 329 the copyright notice or references to the Internet Society or other 330 Internet organizations, except as needed for the purpose of 331 developing Internet standards in which case the procedures for 332 copyrights defined in the Internet Standards process must be 333 followed, or as required to translate it into languages other than 334 English. 336 The limited permissions granted above are perpetual and will not be 337 revoked by the Internet Society or its successors or assigns. 339 This document and the information contained herein is provided on an 340 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 341 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 342 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 343 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 344 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."