idnits 2.17.1 draft-ietf-ospf-cap-01.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 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 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: 3 errors (**), 0 flaws (~~), 2 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: April 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 14 draft-ietf-ospf-cap-01.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026, except that the right to 20 produce derivative works is not granted. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as ``work in progress.'' 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 It is useful for routers in an OSPF routing domain to know the 40 capabilities of their neighbors and other routers in the OSPF 41 routing domain. This draft proposes extensions to OSPF for 42 advertising optional router capabilities. A new Router 43 Information (RI) opaque LSA is proposed for this purpose. 45 Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 49 this document are to be interpreted as described in RFC-2119 [3]. 51 1. Motivation 53 It is useful for routers in an OSPF routing domain to know the 54 capabilities of their neighbors and other routers in the OSPF 55 routing domain. This can be useful for various applications: 57 o In MPLS Traffic Engineering (TE), it can be used as a discovery 58 mechanism [7, 8] to announce a LSR's TE capabilities like 59 Path Computation Server capability (Capability of an LSR to be 60 a Path Computation Server for TE LSP path computation) or the 61 intention of an LSR to be part of a particular MPLS TE mesh group. 63 o For network management and troubleshooting. It gives operators a 64 network wide view of OSPF capabilities on different routers. 65 The presence of a capability on a given router implies 66 that the software version supports the capability and the router 67 is configured to support it. On the other hand, the absence of an 68 expected capability on a particular router can imply either 69 misconfiguration or an incorrect software version. Hence, this 70 capability information can be used to track problems resulting from 71 misconfiguration or an incorrect software version. 73 OSPF uses the options field in the hello packet to advertise optional 74 router capabilities [1]. However, all the bits in this field have 75 been allocated and there is no way to advertise new optional 76 or MPLS TE capabilities. This document proposes extensions to OSPF 77 to advertise these optional capabilities. For existing OSPF 78 capabilities, this advertisement will be used primarily for 79 informational purposes. For MPLS TE features, it is used for 80 advertisement and discovery. Future OSPF features could also 81 use this mechanism for advertisement and discovery. 83 2. OSPF Router Information (RI) Opaque LSA 85 OSPF routers will optionally advertise their optional capabilities 86 in an area-scoped, local scope, or AS-scoped Opaque-LSA [2]. 87 If a router does not advertise this LSA, it does not imply that the 88 router does not support one or more of the defined capabilities. 89 For existing OSPF capabilities, this advertisement will be used 90 primarily for informational purposes. For MPLS TE features, 91 it is used for advertisement and discovery. Future OSPF features 92 could also use this mechanism for advertisement and discovery. 93 The RI opaque LSA will be originated when one of the advertised 94 capabilities is configured or changed. 96 The Router Information LSA will have an Opaque type of 4 and Opaque 97 ID of 0. 99 0 1 2 3 100 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 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | LS age | Options | 9, 10 or 11 | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | 4 | 0 | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Advertising Router | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | LS sequence number | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | LS checksum | length | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | | 113 +- TLV's -+ 114 | ... | 116 Figure 2. OSPF Router Information LSA 118 The format of the TLV's within the body of a router information LSA 119 is the same as the format used by the Traffic Engineering 120 Extensions to OSPF [4]. The LSA payload consists of one or 121 more nested Type/Length/Value (TLV) triplets. The format of 122 each TLV is: 124 0 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Type | Length | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Value... | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 Figure 3. TLV Format 134 The Length field defines the length of the value portion in octets 135 (thus a TLV with no value portion would have a length of zero). The 136 TLV is padded to four-octet alignment; padding is not included in 137 the length field (so a three octet value would have a length of 138 three, but the total size of the TLV would be eight octets). Nested 139 TLV's are also 32-bit aligned. For example, a one byte value 140 would have the length field set to 1, and three bytes of padding 141 would be added to the end of the value portion of the TLV. 142 Unrecognized types are ignored. 144 2.1 OSPF Router Capabilities TLV 146 The first defined TLV in the body of a RI opaque LSA is 147 the Router Capabilities TLV. A router advertising a RI opaque LSA 148 SHOULD include the Router Capabilities TLV and SHOULD correctly 149 identify the status of the capabilities defined in section 2.2. 151 The format of the Router Capabilities TLV is as follows: 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Type | Length | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Capabilities | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 4. OSPF Router Capabilities TLV 163 Type A 16 bit field set to 1. 164 Length A 16 bit field that indicates the length of the value 165 portion in bytes. Its set to N x 4 octets. N starts from 166 1 and can be increased when there is a need. Each 4 167 octets are referred to as a capability flag. 168 Value This comprises one or more capability flags. For each 4 169 octets, the bits are indexed from the most significant 170 to the least significant, where each bit represents one 171 router capability. When the first 32 capabilities are 172 defined, a new capability flag will be used to 173 accommodate the next capability. 175 The Router Capabilities TLV MAY be followed by optional TLV's that 176 further specify a capability. 178 2.2 Reserved OSPF Router Capability Bits 180 The following bits in the first capability flag have been 181 assigned: 183 Bit Capabilities 185 0-3 Reserved 186 4 OSPF graceful restart capable [5] 187 5 OSPF graceful restart helper [5] 188 6 Stub Router support [6] 189 7 Traffic Engineering support [4] 190 8 OSPF point-to-point over LAN [9] 191 9 OSPF Path Computation Server discovery [7, 8] 192 10-31 Future assignments 194 2.3 Flooding Scope of the Router Information LSA 196 The flooding scope of the Router Information opaque LSA is determined 197 by the LSA type. A type 9 (link-scope), type 10 (area-scoped), or a 198 type 11 (AS-scoped) opaque LSA may be used. If a type 11 opaque LSA 199 is chosen, the originating router should also advertise type 10 200 LSA(s) into any attached NSSA/stub area(s). An OSPF router MAY 201 advertise different values in advertised NSSA/stub area type 10 202 LSA(s) and its AS scoped type 11 opaque LSA. The choice of 203 flooding scope is made by the advertising router and is a matter of 204 local policy. The originating router MAY advertise multiple Router 205 Information LSAs as long as the flooding scope differs. TLV flooding 206 scope rules will be specified on a per-TLV basis. 208 3. Security Consideration 210 This memo does not create any new security issues for the OSPF 211 protocol. Security considerations for the base OSPF protocol are 212 covered in [1]. 214 4. Acknowledgments 216 The idea for this work grew out of a conversation with Andrew Partan 217 and we would like to thank him for his contribution. The authors 218 would like to thanks Peter Psenak for his review and helpful 219 comments early versions of the draft. 221 Funding for the RFC Editor function is currently provided by the 222 Internet Society. 224 5. IANA Considerations 226 A new opaque LSA type will need to be assigned by IANA. Additionally, 227 IANA will need to have registries for the Router Information opaque 228 LSA TLV's. The TLV assignee will be responsible for allocation of 229 any sub-TLV's for the IANA assigned TLV. All TLV's and sub-TLV's 230 will be subject to OSPF WG review. 232 6. References 234 Normative References 236 [1] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 237 1998. 239 [2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 241 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 242 Level", BCP 14, RFC 2119, March 1997. 244 Informative References 246 [4] Katz, D., D. Yeung and K. Kompella, "Traffic Engineering 247 Extensions to OSPF", RFC 3630, September 2003. 249 [5] Moy, J., "OSPF Graceful OSPF Restart", Internet Draft, work in 250 progress. 252 [6] Retana, A., et al, "OSPF Stub Router Advertisement", 253 RFC 3137, June 2001. 255 [7] Vasseur, Psenak, "Traffic Engineering Capability TLV for OSPF", 256 Internet Draft, work in progress. 258 [8] Vasseur et al, "RSVP Path computation request and reply 259 messages", draft-vasseur-mpls-computation-rsvp-te-03.txt, 260 work in progress 262 [9] 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 Juniper Networks 282 1194 N. Mathilda Ave. 283 Sunnyvale, CA 94089 USA 284 e-mail: rahul@juniper.net 286 Scott Shaffer 287 Level 3 Communications 288 e-mail: scott.shaffer@level3.com 290 JP Vasseur 291 Cisco Systems, Inc. 292 300 Apollo Drive 293 Chelmsford, MA 01824 294 e-mail: jpv@cisco.com 295 10. IPR Notice 297 The IETF takes no position regarding the validity or scope of any 298 intellectual property or other rights that might be claimed to 299 pertain to the implementation or use of the technology described in 300 this document or the extent to which any license under such rights 301 might or might not be available; neither does it represent that it 302 has made any effort to identify any such rights. Information on the 303 IETF's procedures with respect to rights in standards-track and 304 standards-related documentation can be found in BCP-11. Copies of 305 claims of rights made available for publication and any assurances of 306 licenses to be made available, or the result of an attempt made to 307 obtain a general license or permission for the use of such 308 proprietary rights by implementors or users of this specification can 309 be obtained from the IETF Secretariat. 311 The IETF invites any interested party to bring to its attention any 312 copyrights, patents or patent applications, or other proprietary 313 rights which may cover technology that may be required to practice 314 this standard. Please address the information to the IETF Executive 315 Director. 317 11. Full Copyright Notice 319 Copyright (C) The Internet Society (2003). All Rights Reserved. 321 This document and translations of it may be copied and furnished to 322 others, and derivative works that comment on or otherwise explain it 323 or assist in its implementation may be prepared, copied, published 324 and distributed, in whole or in part, without restriction of any 325 kind, provided that the above copyright notice and this paragraph are 326 included on all such copies and derivative works. However, this 327 document itself may not be modified in any way, such as by removing 328 the copyright notice or references to the Internet Society or other 329 Internet organizations, except as needed for the purpose of 330 developing Internet standards in which case the procedures for 331 copyrights defined in the Internet Standards process must be 332 followed, or as required to translate it into languages other than 333 English. 335 The limited permissions granted above are perpetual and will not be 336 revoked by the Internet Society or its successors or assigns. 338 This document and the information contained herein is provided on an 339 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 340 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 341 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 342 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 343 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."