idnits 2.17.1 draft-ietf-ospf-cap-03.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 3979, Section 5, paragraph 1 on line 331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 344. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 3 longer pages, the longest (page 7) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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: 7 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Acee Lindem 2 Internet Draft Naiming Shen 3 Expiration Date: February 2005 Redback Networks 4 Rahul Aggarwal 5 Juniper Networks 6 Scott Shaffer 7 Level 3 Communications 8 JP Vasseur 9 Cisco Systems, Inc 11 Extensions to OSPF for Advertising Optional Router Capabilities 12 draft-ietf-ospf-cap-03.txt 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or IPR claims of which I am aware have been disclosed, and 18 any of which I become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 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 an RI opaque LSA is 147 the Router Capabilities TLV. A router advertising an 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 166 from 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 for a 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 flooded. If a type 11 opaque 199 LSA 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 capabilities when both NSSA/stub area type 10 202 LSA(s) and an AS scoped type 11 opaque LSA is advertised. The choice 203 of flooding scope is made by the advertising router and is a matter 204 of local policy. The originating router MAY advertise multiple RI 205 opaque LSAs as long as the flooding scopes differ. 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 5. IANA Considerations 223 A new opaque LSA type will need to be assigned by IANA. 224 Additionally, IANA will need to have registries for the Router 225 Information opaque LSA TLV's. The TLV assignee will be responsible 226 for allocation of any sub-TLV's for the IANA assigned TLV. All 227 TLV's and sub-TLV's will be subject to OSPF WG review. 229 6. References 231 Normative References 233 [1] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 234 1998. 236 [2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 238 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 239 Level", BCP 14, RFC 2119, March 1997. 241 Informative References 243 [4] Katz, D., D. Yeung and K. Kompella, "Traffic Engineering 244 Extensions to OSPF", RFC 3630, September 2003. 246 [5] Moy, J., P. Pillay-Esnault and A. Lindem, "OSPF Graceful 247 OSPF Restart", RFC 3623, November 2003. 249 [6] Retana, A., et al, "OSPF Stub Router Advertisement", 250 RFC 3137, June 2001. 252 [7] Vasseur, J., P. Psenak, "Traffic Engineering Capability TLV 253 for OSPF", Internet Draft, work in progress. 255 [8] Vasseur, J., et al, "RSVP Path computation request and reply 256 messages", draft-vasseur-mpls-computation-rsvp-te-03.txt, 257 work in progress 259 [9] N. Shen, et al, "Point-to-point operation over LAN in 260 link-state-routing protocols", Internet Draft, work in 261 progress. 263 7. Author Information 265 Acee Lindem 266 Redback Networks 267 350 Holger Way 268 San Jose, CA 95134 269 e-mail: acee@redback.com 271 Naiming Shen 272 Redback Networks 273 350 Holger Way 274 San Jose, CA 95134 275 e-mail: naiming@redback.com 277 Rahul Aggarwal 278 Juniper Networks 279 1194 N. Mathilda Ave. 280 Sunnyvale, CA 94089 USA 281 e-mail: rahul@juniper.net 283 Scott Shaffer 284 Level 3 Communications 285 e-mail: scott.shaffer@level3.com 287 JP Vasseur 288 Cisco Systems, Inc. 289 300 Apollo Drive 290 Chelmsford, MA 01824 291 e-mail: jpv@cisco.com 292 8. Full Copyright Statement 294 Copyright (C) The Internet Society (2004). This document is subject 295 to the rights, licenses and restrictions contained in BCP 78 and 296 except as set forth therein, the authors retain all their rights. 298 This document and translations of it may be copied and furnished to 299 others, and derivative works that comment on or otherwise explain it 300 or assist in its implementation may be prepared, copied, published 301 and distributed, in whole or in part, without restriction of any 302 kind, provided that the above copyright notice and this paragraph are 303 included on all such copies and derivative works. However, this 304 document itself may not be modified in any way, such as by removing 305 the copyright notice or references to the Internet Society or other 306 Internet organizations, except as needed for the purpose of 307 developing Internet standards in which case the procedures for 308 copyrights defined in the Internet Standards process must be 309 followed, or as required to translate it into languages other than 310 English. 312 The limited permissions granted above are perpetual and will not be 313 revoked by the Internet Society or its successors or assignees. 315 This document and the information contained herein is provided on an 316 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 317 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 318 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 319 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 320 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 322 9. Intellectual Property 324 The IETF takes no position regarding the validity or scope of any 325 Intellectual Property Rights or other rights that might be claimed to 326 pertain to the implementation or use of the technology described in 327 this document or the extent to which any license under such rights 328 might or might not be available; nor does it represent that it has 329 made any independent effort to identify any such rights. Information 330 on the procedures with respect to rights in RFC documents can be 331 found in BCP 78 and BCP 79. 333 Copies of IPR disclosures made to the IETF Secretariat and any 334 assurances of licenses to be made available, or the result of an 335 attempt made to obtain a general license or permission for the use of 336 such proprietary rights by implementers or users of this 337 specification can be obtained from the IETF on-line IPR repository at 338 http://www.ietf.org/ipr. 340 The IETF invites any interested party to bring to its attention any 341 copyrights, patents or patent applications, or other proprietary 342 rights that may cover technology that may be required to implement 343 this standard. Please address the information to the IETF at ietf- 344 ipr@ietf.org. 346 10. Acknowledgement 348 Funding for the RFC Editor function is currently provided by the 349 Internet Society.