idnits 2.17.00 (12 Aug 2021) /tmp/idnits42588/draft-lindem-ospf-cap-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. 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: 4 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: November 2003 Rahul Aggarwal (Redback 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-00.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 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 a LSR to be 56 a Path Computation Server for TE LSP path computation) or the 57 intention of a 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 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 For current OSPF capabilities, the advertisement will be used for 90 The Router Information opaque LSA will be originated at startup and 91 reoriginated when router capabilities change or when the LSA is 92 periodically refreshed. 94 The Router Information LSA will have an Opaque type of 4 and Opaque 95 ID of 0. 97 0 1 2 3 98 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 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | LS age | Options | 9, 10 or 11 | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | 4 | 0 | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | Advertising Router | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | LS sequence number | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | LS checksum | length | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | | 111 +- TLVs -+ 112 | ... | 114 Figure 2. OSPF Router Information LSA 116 The format of the TLVs within the body of a Router Information LSA is 117 the same as the TLV format used by the Traffic Engineering Extensions 118 to OSPF [3]. The TLV header consists of a 16-bit Type field and a 119 16-bit length field, and is followed by zero or more bytes of value. 120 The length field indicates the length of the value portion in bytes. 121 The value portion is padded to four-octet alignment, but the padding 122 is not included in the length field. For example, a one byte value 123 would have the length field set to 1, and three bytes of padding 124 would be added to the end of the value portion of the TLV. 126 0 1 2 3 127 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 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Type | Length | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Value... | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 Figure 3. OSPF TLV Format 136 2.1 OSPF Router Capability TLV 138 The first TLV in the body of a Router Information LSA is the 139 Router Capability TLV. It MUST be included. A router advertising 140 an optional Router Information LSA SHOULD set the supported optional 141 capabilities, unless they are explicitly configured off, in the 142 Router Capability TLV. 144 The format of the Router Capability TLV is as follows : 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Type | Length | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Reserved | | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Router Capability sub-TLV | | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Optional sub-TLVs | 157 Figure 4. OSPF Router Capability TLV 159 Type A 16 bit field set to 1. 160 Length A 16 bit field that indicates the length of the TLV, 161 other than the Type and the Length fields in bytes. 163 The first four bytes of the TLV are reserved. This is followed by 164 a Router Capability sub-TLV that MUST be included. The format of 165 the Router Capability sub-TLV is as follows : 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Type | Length | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Value... | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Figure 5. OSPF Router Capability Sub-TLV 177 Type A 16 bit field set to 1. 178 Length A 16 bit field that indicates the length of the value 179 portion in bytes. Its set to N x 4 octets. N starts from 180 1 and can be increased when there is a need. Each 4 181 octets are referred to as a capability flag. 182 Value This comprises one or more capability flags. For each 4 183 octets, the bits are indexed from the most significant 184 to the least significant, where each bit represents one 185 router capability. When the first 32 capabilities are 186 defined, a new capability flag will be used to 187 accommodate the next capability. 189 The Router Capability sub-TLV MAY be followed by optional sub-TLVs. 190 In some cases it may be desirable to advertise additional information 191 for a particular capability. This can be done by including other 192 sub-TLVs. 194 2.2 Reserved OSPF Router Capability Bits 196 We have assigned some pre-determined bits to the first capability 197 flag. 199 Bit Capabilities 201 0-3 Reserved 202 4 OSPF graceful restart capable [5] 203 5 OSPF graceful restart helper [5] 204 6 Stub Router support [6] 205 7 Traffic Engineering support [4] 206 8 OSPF point-to-point over LAN [9] 207 9 OSPF Path Computation Server discovery [7, 8] 208 10-31 Future assignments 210 2.3 Flooding Scope of the Router Information LSA 212 The flooding scope of the Router Information opaque LSA is determined 213 by the LSA type. A type 10 (area-scoped) opaque LSA or a type 11 214 (AS-scoped) LSA may be used. The choice of flooding scope is made 215 by the advertising router and is a matter of local policy. A Router 216 Information LSA must be announced using only one flooding scope. 218 3. Security Consideration 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 [1]. 224 4. Acknowledgments 226 The idea for this work grew out of a conversation with Andrew Partan 227 and we would like to thank him for his contribution. 229 5. IANA Considerations 231 A new opaque LSA type will need to be assigned by IANA. Additionally, 232 IANA will need to have registries for the Router Information opaque 233 LSA TLVs. The TLV assignee will be responsible for allocation of 234 any sub-TLVs for the IANA assigned TLV. All TLVs and sub-TLVs will 235 be subject to OSPF WG review. 237 6. References 239 Normative References 241 [1] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 242 1998. 244 [2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 246 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 247 Level", BCP 14, RFC 2119, March 1997. 249 Informative References 251 [4] Katz, D., D. Yeung and K. Kompella, "Traffic Engineering 252 Extensions to OSPF", Internet Draft, work in progress. 254 [5] Moy, J., "OSPF Graceful OSPF Restart", Internet Draft, work in 255 progress. 257 [6] Retana, A., et al, "OSPF Stub Router Advertisement", 258 RFC 3137, June 2001. 260 [7] Vasseur, Psenak, "Traffic Engineering Capability TLV for OSPF", 261 Internet Draft, work in progress. 263 [8] Vasseur et al, "RSVP Path computation request and reply 264 messages", draft-vasseur-mpls-computation-rsvp-te-03.txt, 265 work in progress 267 [9] N. Shen, et al, "Point-to-point operation over LAN in 268 link-state-routing protocols", Internet Draft, work in 269 progress. 271 9. Author Information 273 Acee Lindem 274 Redback Networks 275 350 Holger Way 276 San Jose, CA 95134 277 e-mail: acee@redback.com 279 Naiming Shen 280 Redback Networks 281 350 Holger Way 282 San Jose, CA 95134 283 e-mail: naiming@redback.com 285 Rahul Aggarwal 286 Redback Networks 287 350 Holger Way 288 San Jose, CA 95134 289 e-mail: rahul@redback.com 291 Scott Shaffer 292 Genuity, Inc. 293 3 Van de Graaff Drive 294 PO Box 3073 295 Burlington, MA 01803 296 e-mail: sshaffer@genuity.com 298 JP Vasseur 299 Cisco Systems, Inc. 300 300 Apollo Drive 301 Chelmsford, MA 01824 302 e-mail: jpv@cisco.com