idnits 2.17.1 draft-lindem-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 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 (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Acee Lindem (Redback Networks) 3 Internet Draft Naiming Shen (Redback Networks) 4 Expiration Date: December 2003 Rahul Aggarwal (Juniper Networks) 5 Scott Shaffer (Genuity, Inc.) 6 JP Vasseur (Cisco Systems, Inc) 8 Extensions to OSPF for Advertising Optional Router Capabilities 10 draft-lindem-ospf-cap-01.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026, except that the right to 16 produce derivative works is not granted. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 It is useful for routers in an OSPF routing domain to know the 36 capabilities of their neighbors and other routers in the OSPF 37 routing domain. This draft proposes extensions to OSPF for 38 advertising optional router capabilities. A new Router 39 Information (RI) opaque LSA is proposed for this purpose. 41 Conventions used in this document 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 45 this document are to be interpreted as described in RFC-2119 [3]. 47 1. Motivation 49 It is useful for routers in an OSPF routing domain to know the 50 capabilities of their neighbors and other routers in the OSPF 51 routing domain. This can be useful for various applications: 53 o In MPLS Traffic Engineering (TE), it can be used as a discovery 54 mechanism [7, 8] to announce a LSR's TE capabilities like 55 Path Computation Server capability (Capability of an LSR to be 56 a Path Computation Server for TE LSP path computation) or the 57 intention of an LSR to be part of a particular MPLS TE mesh group. 59 o For network management and troubleshooting. It gives operators a 60 network wide view of OSPF capabilities on different routers. 61 The presence of a capability on a given router implies 62 that the software version supports the capability and the router 63 is configured to support it. On the other hand, the absence of an 64 expected capability on a particular router can imply either 65 misconfiguration or an incorrect software version. Hence, this 66 capability information can be used to track problems resulting from 67 misconfiguration or an incorrect software version. 69 OSPF uses the options field in the hello packet to advertise optional 70 router capabilities [1]. However, all the bits in this field have 71 been allocated and there is no way to advertise new optional 72 or MPLS TE capabilities. This document proposes extensions to OSPF 73 to advertise these optional capabilities. For existing OSPF 74 capabilities, this advertisement will be used primarily for 75 informational purposes. For MPLS TE features, it is used for 76 advertisement and discovery. Future OSPF features could also 77 use this mechanism for advertisement and discovery. 79 2. OSPF Router Information (RI) Opaque LSA 81 OSPF routers will optionally advertise their optional capabilities 82 in an area-scoped, local scope, or AS-scoped Opaque-LSA [2]. 83 If a router does not advertise this LSA, it does not imply that the 84 router does not support one or more of the defined capabilities. 85 For existing OSPF capabilities, this advertisement will be used 86 primarily for informational purposes. For MPLS TE features, 87 it is used for advertisement and discovery. Future OSPF features 88 could also use this mechanism for advertisement and discovery. 89 The RI opaque LSA will be originated when one of the advertised 90 capabilities is configured or changed. 92 The Router Information LSA will have an Opaque type of 4 and Opaque 93 ID of 0. 95 0 1 2 3 96 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 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | LS age | Options | 9, 10 or 11 | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | 4 | 0 | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Advertising Router | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | LS sequence number | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | LS checksum | length | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | | 109 +- TLVs -+ 110 | ... | 112 Figure 2. OSPF Router Information LSA 114 The format of the TLVs within the body of a router information LSA 115 is the same as the format used by the Traffic Engineering 116 Extensions to OSPF [4]. The LSA payload consists of one or 117 more nested Type/Length/Value (TLV) triplets. The format of 118 each TLV is: 120 0 1 2 3 121 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 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Type | Length | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Value... | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 Figure 3. TLV Format 130 The Length field defines the length of the value portion in octets 131 (thus a TLV with no value portion would have a length of zero). The 132 TLV is padded to four-octet alignment; padding is not included in 133 the length field (so a three octet value would have a length of 134 three, but the total size of the TLV would be eight octets). Nested 135 TLVs are also 32-bit aligned. For example, a one byte value 136 would have the length field set to 1, and three bytes of padding 137 would be added to the end of the value portion of the TLV. 138 Unrecognized types are ignored. 140 2.1 OSPF Router Capabilities TLV 142 The first defined TLV in the body of a RI opaque LSA is 143 the Router Capabilities TLV. A router advertising a RI opaque LSA 144 SHOULD include the Router Capabilities TLV and SHOULD correctly 145 identify the status of the capabilities defined in section 2.2. 147 The format of the Router Capabilities TLV is as follows: 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Type | Length | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Capabilities | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Figure 4. OSPF Router Capabilities TLV 159 Type A 16 bit field set to 1. 160 Length A 16 bit field that indicates the length of the value 161 portion in bytes. Its set to N x 4 octets. N starts from 162 1 and can be increased when there is a need. Each 4 163 octets are referred to as a capability flag. 164 Value This comprises one or more capability flags. For each 4 165 octets, the bits are indexed from the most significant 166 to the least significant, where each bit represents one 167 router capability. When the first 32 capabilities are 168 defined, a new capability flag will be used to 169 accommodate the next capability. 171 The Router Capabilities TLV MAY be followed by optional TLVs that 172 further specify a capability. 174 2.2 Reserved OSPF Router Capability Bits 176 The following bits in the first capability flag have been 177 assigned: 179 Bit Capabilities 181 0-3 Reserved 182 4 OSPF graceful restart capable [5] 183 5 OSPF graceful restart helper [5] 184 6 Stub Router support [6] 185 7 Traffic Engineering support [4] 186 8 OSPF point-to-point over LAN [9] 187 9 OSPF Path Computation Server discovery [7, 8] 188 10-31 Future assignments 190 2.3 Flooding Scope of the Router Information LSA 192 The flooding scope of the Router Information opaque LSA is determined 193 by the LSA type. A type 9 (link-scope), type 10 (area-scoped), or a 194 type 11 (AS-scoped) opaque LSA may be used. If a type 11 opaque LSA 195 is chosen, the originating router should also advertise type 10 196 LSA(s) into any attached NSSA/stub area(s). The choice of flooding 197 scope is made by the advertising router and is a matter of local 198 policy. The originating router MAY advertise multiple Router 199 Information LSAs as long as the flooding scope differs. TLV flooding 200 scope rules will be specified on a per-TLV basis. 202 3. Security Consideration 204 This memo does not create any new security issues for the OSPF 205 protocol. Security considerations for the base OSPF protocol are 206 covered in [1]. 208 4. Acknowledgments 210 The idea for this work grew out of a conversation with Andrew Partan 211 and we would like to thank him for his contribution. The authors 212 would like to thanks Peter Psenak for his review and helpful 213 comments early versions of the draft. 215 5. IANA Considerations 217 A new opaque LSA type will need to be assigned by IANA. Additionally, 218 IANA will need to have registries for the Router Information opaque 219 LSA TLVs. The TLV assignee will be responsible for allocation of 220 any sub-TLVs for the IANA assigned TLV. All TLVs and sub-TLVs will 221 be subject to OSPF WG review. 223 6. References 225 Normative References 227 [1] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 228 1998. 230 [2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 232 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 233 Level", BCP 14, RFC 2119, March 1997. 235 Informative References 237 [4] Katz, D., D. Yeung and K. Kompella, "Traffic Engineering 238 Extensions to OSPF", Internet Draft, work in progress. 240 [5] Moy, J., "OSPF Graceful OSPF Restart", Internet Draft, work in 241 progress. 243 [6] Retana, A., et al, "OSPF Stub Router Advertisement", 244 RFC 3137, June 2001. 246 [7] Vasseur, Psenak, "Traffic Engineering Capability TLV for OSPF", 247 Internet Draft, work in progress. 249 [8] Vasseur et al, "RSVP Path computation request and reply 250 messages", draft-vasseur-mpls-computation-rsvp-te-03.txt, 251 work in progress 253 [9] N. Shen, et al, "Point-to-point operation over LAN in 254 link-state-routing protocols", Internet Draft, work in 255 progress. 257 9. Author Information 259 Acee Lindem 260 Redback Networks 261 350 Holger Way 262 San Jose, CA 95134 263 e-mail: acee@redback.com 265 Naiming Shen 266 Redback Networks 267 350 Holger Way 268 San Jose, CA 95134 269 e-mail: naiming@redback.com 271 Rahul Aggarwal 272 Juniper Networks 273 1194 N. Mathilda Ave. 274 Sunnyvale, CA 94089 USA 275 e-mail: rahul@juniper.net 277 Scott Shaffer 278 Genuity, Inc. 279 3 Van de Graaff Drive 280 PO Box 3073 281 Burlington, MA 01803 282 e-mail: sshaffer@genuity.com 284 JP Vasseur 285 Cisco Systems, Inc. 286 300 Apollo Drive 287 Chelmsford, MA 01824 288 e-mail: jpv@cisco.com