idnits 2.17.1 draft-raggarwa-igp-cap-01.txt: ** The Abstract section seems to be numbered 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. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 102: '... in the LSP, the router SHOULD set all...' RFC 2119 keyword, line 122: '...he L1/L2 routers MUST observe the Down...' RFC 2119 keyword, line 124: '... this TLV and it MUST be set when leak...' RFC 2119 keyword, line 127: '...s capability TLV MUST be preserved at ...' RFC 2119 keyword, line 128: '...g TLV leaking. The L1/L2 router SHOULD...' (8 more instances...) 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) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 3137 (ref. '5') (Obsoleted by RFC 6987) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- No information found for draft-vasseur-mpls-computation-rsvp-te - is the name correct? -- Possible downref: Normative reference to a draft: ref. '16' Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 15 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: May 2003 Rahul Aggarwal (Redback Networks) 5 Scott Shaffer (Genuity, Inc.) 6 JP Vasseur (Cisco Systems, Inc) 8 Extensions to IS-IS and OSPF for Advertising 9 Optional Router Capabilities 11 draft-raggarwa-igp-cap-01.txt 13 1. Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026, except that the right to 17 produce derivative works is not granted. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 2. Abstract 36 It is useful for routers in a domain to know of the capabilities 37 of their IGP neighbors, and/or of other routers in the domain. This 38 draft proposes extensions to IS-IS and OSPF for advertising optional 39 router capabilities. We define an optional Router Capability TLV for 40 IS-IS, while for OSPF we define an optional Router Information Opaque 41 LSA. 43 3. Motivation 45 It is useful for routers in a domain to know of the capabilities 46 of their IGP neighbors, and/or of other routers in the domain. This 47 can be uesful for various purposes: 48 o In MPLS Traffic Engineering (TE) as a TE discovery mechanism 49 [15, 16] to announce a LSR's TE capabilities like Path Computation 50 Server capability (Capability of a LSR to be a Path Computation 51 Server for TE LSP path computation) or the intention of a LSR to be 52 part of a particular MPLS TE mesh group. 53 o For network management and troubleshooting. It gives operators a 54 network wide view of IGP capabilities on different routers in the 55 network. The presence of a capability on a given router implies 56 that the software version supports the capability and the router is 57 configured to support it. On the other hand the absence of an 58 expected capability on a particular router can imply either 59 mis-configuration or an incorrect software version. Hence this 60 capability information can be used to track problems resulting from 61 mis-configuration or an incorrect software version. 63 There is no existing mechanism in IS-IS to advertise optional router 64 capabilities. On the other hand OSPF uses the options field in the 65 hello packet to advertise optional router capabilities [2]. However 66 this attribute is not extensible for advertising optional 67 capabilities such as hitless graceful restart or MPLS TE capabilities. 68 We propose extensions to IS-IS and OSPF for advertising these optional 69 capabilities. For current IS-IS and OSPF capabilities this 70 advertisement will be used primarily for MPLS TE and informational 71 purposes. Conceivably, future IS-IS and OSPF capability advertisements 72 could be used for other purposes. 74 4. IS-IS Router Capability TLV 76 IS-IS [7] routers may optionally advertise their router 77 capabilities in the TLV with code type 242. This TLV specifies 78 the router ID of the router that originates the TLV, defines the 79 flooding scope of the TLV, specifies the router capability bits in 80 the first sub-TLV and certain capability related information in other 81 sub-TLVs. This draft does not specify how an application may use the 82 Router Capability TLV and such specification is outside the scope of 83 this draft. 85 The router ID is a 32 bit unsigned integer to represent the router 86 that originated this capability TLV. This is needed since this TLV 87 can be flooded over the entire domain, hence the router ID of the 88 originating router must be kept. 90 The capability bits are defined in a mandatory sub-TLV with 91 code 1. It starts as a 32 bits flag, where each bit can represent 92 a router capability. This flag can be expanded as needed to 93 include more capabilities. 95 Some of the router capabilities may require more information 96 than a single bit. The extra capability information can be encoded 97 as sub-TLVs under this router capability TLV. The definition 98 of these sub-TLVs is outside the scope of this draft. 100 If a router does not advertise this TLV, it does not imply that 101 the router does not support one or more of the defined capabilities. 102 If this TLV is included in the LSP, the router SHOULD set all 103 the defined bits corresponding to the capabilities which the 104 software supports, unless they are explicitly configured off. 106 4.1 Flooding Scope of the Router Capability TLV 108 There are three bits currently defined for this TLV in the 109 information flag to control the flooding scope of the TLV. The 110 Flooding bit, the Transit bit and the Down bit. 112 There are two flooding types defined for this router capability 113 TLV's flooding scope. One is the domain wide flooding scope and 114 the other is the intra-area flooding scope. The F bit if set 115 indicates this TLV has the domain wide flooding scope. 117 The Transit bit can be used to signal the routers on the edge 118 of the IGP routing domain to redistribute this TLV information 119 into another routing process. How this is done is an application 120 specific issue and is outside the scope of this document. 122 The L1/L2 routers MUST observe the Down bit to avoid TLV leak 123 looping. This Down bit is not set when the router first originates 124 this TLV and it MUST be set when leaking into a lower level or into 125 another area of the same level. When the Down bit is set, this TLV 126 can no longer be leaked to a higher level or into another area 127 of the same level. This capability TLV MUST be preserved at the 128 level boundary during TLV leaking. The L1/L2 router SHOULD 129 NOT leak the TLV back into the same area which originated 130 this TLV. It MAY be able to alter certain capability contents 131 during TLV leaking when specified by applications. 133 4.2 Encoding of the Router Capability TLV 135 The following figure depicts the structure of this IS-IS Router 136 Capability TLV. 138 x CODE - 242 139 x LENGTH - total length of the value field in this TLV 140 x VALUE - 4-octet information flag, 4-octet router ID, 141 1-octet sub-tlv length, the mandatory sub-TLV code 1 142 for capability flags, and optional sub-TLVs for extra 143 capability information, structured as follows: 145 0 1 2 3 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 |F|T|D| Reserved Information Flag | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Router ID | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 |sub-TLV Length |Sub-TLV Type(1)| Length | N x 32bits... | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Other optional Sub-TLVs.. | 156 Figure 1. IS-IS Router Capability TLV 158 The first field is the 4-octet information flag, which consists 159 of the F, T and D bits, the reserved information bits. 161 Bit F represents the Flooding scope of the TLV. If set, this TLV 162 SHOULD be flooded to entire IGP domain. Otherwise, it SHOULD NOT 163 be leaked into the other level or another area in the same level. 165 Bit T determines the Transit behavior into other routing domains. 166 For example, if this bit is set, a router can leak this capability 167 information into another routing protocol. 169 Bit D represents Down/Up behavior during the TLV leaking. When the 170 capability is leaked from level 2 into level 1 or it is leaked into 171 another area of the same level, this D bit MUST be set. Otherwise 172 this bit MUST be cleared. 174 Router ID is an unsigned 32 bit number representing the router 175 that originates this router capability TLV. 177 The next octet of the TLV is the total sub-TLV length of this 178 router capability TLV. This sub-TLV length includes the first 179 mandatory sub-TLV. The minimum value of this field is 6. 181 The first sub-TLV with code 1 is a mandatory sub-TLV, the router 182 capability flag sub-TLV. The length is the length of this sub-TLV. 183 Its set to N x 4 octets. N starts from 1 and can be increased when 184 there is a need. Each 4 octets are referred to as a capability flag. 185 For each capability flag the bits are indexed from the most 186 significant to the least significant, where each bit represents one 187 router capability. 189 There can be other sub-TLVs after the first sub-TLV to include 190 extra information describing certain router capabilities. The 191 description of those sub-TLVs is outside the scope of this draft. 193 The above data structure can be replicated within this TLV, but 194 can not exceed the maximum length of 255 octets. If no other 195 sub-TLVs are used and the capability flag is the minimum 4 octets, 196 this encoding can contain up to 17 router capability TLVs where 197 each have a minimum of 15 octets of data(4 byte information flag, 198 4 byte router-id, 1 byte total sub-tlv length, 6 byte capability 199 flag). 201 4.3 Reserved IS-IS Router Capability Bits 203 We have assigned some pre-determined bits to the first capability 204 flag. 206 Bit Capabilities 208 0-3 Reserved 209 4 IS-IS hitless graceful restart capable [9] 210 5 IS-IS and BGP blackhole avoidance capable [11] 211 6 IS-IS wide metric processing capable [8] 212 7 IS-IS short metric processing capable [6] 213 8 IS-IS hmac-md5 authentication capable [10] 214 9 IS-IS Traffic Engineering support [8] 215 10 IS-IS point-to-point over LAN [12] 216 11 IS-IS Path Computation Server discovery [16] 217 12 M-ISIS capable [13] 218 13 IS-IS IPv6 capable [14] 219 14-31 For future assignments 220 5. OSPF Router Information LSA 222 OSPF routers will optionally advertise their optional capabilities 223 in an area-scoped, local scope, or AS-scoped Opaque-LSA [1]. 224 If a router does not advertise this LSA, it does not imply that the 225 router does not support one or more of the defined capabilities. 226 For current OSPF capabilities, the advertisement will be used for MPLS 227 TE [15] and information purposes. Conceivably, future OSPF 228 capabilities could require other capability LSA advertisement. The 229 Router Information LSA will be originated at startup and re-originated 230 when router capabilities change or when periodically refreshed. 232 The Router Information LSA will have an Opaque type of 4 and Opaque 233 ID of 0. 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | LS age | Options | 9, 10 or 11 | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | 4 | 0 | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Advertising Router | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | LS sequence number | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | LS checksum | length | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | | 249 +- TLVs -+ 250 | ... | 252 Figure 2. OSPF Router Information LSA 254 The format of the TLVs within the body of a Router Information LSA is 255 the same as the TLV format used by the Traffic Engineering Extensions 256 to OSPF [3]. The TLV header consists of a 16-bit Type field and a 257 16-bit length field, and is followed by zero or more bytes of value. 258 The length field indicates the length of the value portion in bytes. 259 The value portion is padded to four-octet alignment, but the padding 260 is not included in the length field. For example, a one byte value 261 would have the length field set to 1, and three bytes of padding 262 would be added to the end of the value portion of the TLV. 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Type | Length | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Value... | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 3. OSPF TLV Format 274 5.1 OSPF Router Capability TLV 276 The first TLV in the body of a Router Information LSA is the 277 Router Capability TLV. It MUST be included. A router advertising 278 an optional Router Information LSA SHOULD set the supported optional 279 capabilities, unless they are explicitly configured off, in the 280 Router Capability TLV. 282 The format of the Router Capability TLV is as follows : 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Type | Length | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Reserved | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Router Capability sub-TLV | | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Optional sub-TLVs | 295 Figure 4. OSPF Router Capability TLV 297 Type A 16 bit field set to 1. 298 Length A 16 bit field that indicates the length of the TLV, 299 other than the Type and the Length fields in bytes. 301 The first four bytes of the TLV are reserved. This is followed by 302 a Router Capability sub-TLV that MUST be included. The format of 303 the Router Capability sub-TLV is as follows : 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Type | Length | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Value... | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Figure 5. OSPF Router Capability Sub-TLV 315 Type A 16 bit field set to 1. 316 Length A 16 bit field that indicates the length of the value 317 portion in bytes. Its set to N x 4 octets. N starts from 318 1 and can be increased when there is a need. Each 4 octets 319 are referred to as a capability flag. 320 Value This comprises one or more capability flags. For each 4 321 octets, the bits are indexed from the most significant to 322 the least significant, where each bit represents one 323 router capability. When the first 32 capabilities are 324 defined, a new capability flag will be used to 325 accommodate the next capability. 327 The Router Capability sub-TLV MAY be followed by optional sub-TLVs. 328 In some cases it may be desirable to advertise additional information 329 for a particular capability. This can be done by including other 330 sub-TLVs. 332 5.2 Reserved OSPF Router Capability Bits 334 We have assigned some pre-determined bits to the first capability 335 flag. 337 Bit Capabilities 339 0-3 Reserved 340 4 Hitless graceful restart capable [4] 341 5 OSPF hitless graceful restart helper [4] 342 6 Stub Router support [5] 343 7 Traffic Engineering support [3] 344 8 OSPF point-to-point over LAN [12] 345 9 OSPF Path Computation Server discovery [15, 16] 346 10-31 Future assignments 347 5.3 Flooding Scope of the Router Information LSA 349 The flooding scope of the Router Information LSA is detemined by the 350 LSA type. A local scope i.e. Type 9 LSA is flooded on a link, an 351 area-scoped i.e. Type 10 LSA is flooded throughout the area, while 352 an AS-scoped i.e. Type 11 LSA is flooded throughout the AS. Choice of 353 the flooding scope is made by the advertising router and is a matter 354 of local policy. A router information LSA must be announced using one 355 flooding mode. A router may announce more than one router 356 information LSA for local scope, intra-area scope or domain scope 357 capabilities. 359 6. Security Consideration 361 This document does not introduce new security issues. The security 362 considerations pertaining to the original IS-IS and OSPF protocols 363 remain relevant. 365 7. Acknowledgments 367 The idea for this work grew out of a conversation with Andrew Partan 368 and we would like to thank him for his contribution. 370 8. References 372 [1] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 373 1998. 375 [2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 377 [3] Katz, D., D. Yeung and K. Kompella, "Traffic Engineering 378 Extensions to OSPF", Internet Draft, work in progress. 380 [4] Moy, J., "OSPF Hitless OSPF Restart", Internet Draft, work in 381 progress. 383 [5] Retana, A., et al, "OSPF Stub Router Advertisement", 384 RFC 3137, June 2001. 386 [6] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, 387 December 1990. 389 [7] ISO, "Intermediate system to Intermediate system routeing 390 information exchange protocol for use in conjunction with the 391 Protocol for providing the Connectionless-mode Network 392 Service (ISO 8473)," ISO/IEC 10589:1992. 394 [8] Li, T. et al, "IS-IS Extensions for Traffic Engineering", 395 Internet Draft, work in Progress. 397 [9] Shand, M., "Restart Signaling for IS-IS", Internet Draft, work 398 in Progress. 400 [10] Li, T., "IS-IS Cryptographic Authentication", Internet Draft, 401 work in progress. 403 [11] McPherson, D., "IS-IS Transient Blackhole Avoidance", Internet 404 Draft, work in progress. 406 [12] N. Shen, et al, "Point-to-point operation over LAN in 407 link-state-routing protocols", Internet Draft, work in 408 progress. 410 [13] T. Przygienda, N. Shen, N. Sheth, "M-ISIS: Multi Topology (MT) 411 Routing in IS-IS", Internet Draft, work in progress. 413 [14] C. Hopps, "Routing IPv6 with IS-IS", Internet Draft, work 414 in progress. 416 [15] Vasseur, Psenak, "Traffic Engineering Capability TLV for OSPF", 417 Internet Draft, work in progress. 419 [16] Vasseur et al, "RSVP Path computation request and reply 420 " messages", draft-vasseur-mpls-computation-rsvp-te-03.txt, 421 work in progress 422 9. Author Information 424 Acee Lindem 425 Redback Networks 426 350 Holger Way 427 San Jose, CA 95134 428 e-mail: acee@redback.com 430 Naiming Shen 431 Redback Networks 432 350 Holger Way 433 San Jose, CA 95134 434 e-mail: naiming@redback.com 436 Rahul Aggarwal 437 Redback Networks 438 350 Holger Way 439 San Jose, CA 95134 440 e-mail: rahul@redback.com 442 Scott Shaffer 443 Genuity, Inc. 444 3 Van de Graaff Drive 445 PO Box 3073 446 Burlington, MA 01803 447 e-mail: sshaffer@genuity.com 449 JP Vasseur 450 Cisco Systems, Inc. 451 300 Apollo Drive 452 Chelmsford, MA 01824 453 e-mail: jpv@cisco.com