idnits 2.17.00 (12 Aug 2021) /tmp/idnits53792/draft-raggarwa-isis-cap-00.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 == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters 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 97: '... in the LSP, the router SHOULD set all...' RFC 2119 keyword, line 117: '...he L1/L2 routers MUST observe the Down...' RFC 2119 keyword, line 119: '... this TLV and it MUST be set when leak...' RFC 2119 keyword, line 122: '...s capability TLV MUST be preserved at ...' RFC 2119 keyword, line 123: '...g TLV leaking. The L1/L2 router SHOULD...' (4 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) == Unused Reference: '2' is defined on line 232, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- No information found for draft-vasseur-mpls-computation-rsvp-te - is the name correct? -- Possible downref: Normative reference to a draft: ref. '10' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 12 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 IS-IS for Advertising Optional 9 Router Capabilities 11 draft-raggarwa-isis-cap-00.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 an IS-IS domain to know of the capabilities 37 of their neighbors, and/or of other routers in the domain. This 38 draft proposes extensions to IS-IS for advertising optional router 39 capabilities. In particular it defines an optional Router Capability 40 TLV for IS-IS. 42 3. Motivation 44 It is useful for routers in a domain to know of the capabilities 45 of their IS-IS neighbors, and/or of other routers in the domain. This 46 can be useful for various purposes: 47 o In MPLS Traffic Engineering (TE) as a TE discovery mechanism 48 [10] to announce a LSR's TE capabilities like Path Computation 49 Server capability (Capability of a LSR to be a Path Computation 50 Server for TE LSP path computation) or the intention of a LSR to be 51 part of a particular MPLS TE mesh group. 52 o For network management and troubleshooting. It gives operators a 53 network wide view of IS-IS capabilities on different routers in the 54 network. The presence of a capability on a given router implies 55 that the software version supports the capability and the router is 56 configured to support it. On the other hand the absence of an 57 expected capability on a particular router can imply either 58 mis-configuration or an incorrect software version. Hence this 59 capability information can be used to track problems resulting from 60 mis-configuration or an incorrect software version. 62 There is no existing mechanism in IS-IS to advertise optional router 63 capabilities. We propose extensions to IS-IS for advertising these 64 optional capabilities. For current IS-IS capabilities this 65 advertisement will be used primarily for MPLS TE and informational 66 purposes. Conceivably, future capability advertisements could be 67 used for other purposes. 69 4. IS-IS Router Capability TLV 71 IS-IS [1] routers may optionally advertise their router 72 capabilities in the TLV with code type 242. This TLV specifies 73 the router ID of the router that originates the TLV, defines the 74 flooding scope of the TLV, specifies the router capability bits in 75 the first sub-TLV and certain capability related information in other 76 sub-TLVs. This draft does not specify how an application may use the 77 Router Capability TLV and such specification is outside the scope of 78 this draft. 80 The router ID is a 32 bit unsigned integer to represent the router 81 that originated this capability TLV. This is needed since this TLV 82 can be flooded over the entire domain, hence the router ID of the 83 originating router must be kept. 85 The capability bits are defined in a mandatory sub-TLV with 86 code 1. It starts as a 32 bits flag, where each bit can represent 87 a router capability. This flag can be expanded as needed to 88 include more capabilities. 90 Some of the router capabilities may require more information 91 than a single bit. The extra capability information can be encoded 92 as sub-TLVs under this router capability TLV. The definition 93 of these sub-TLVs is outside the scope of this draft. 95 If a router does not advertise this TLV, it does not imply that 96 the router does not support one or more of the defined capabilities. 97 If this TLV is included in the LSP, the router SHOULD set all 98 the defined bits corresponding to the capabilities which the 99 software supports, unless they are explicitly configured off. 101 4.1 Flooding Scope of the Router Capability TLV 103 There are three bits currently defined for this TLV in the 104 information flag to control the flooding scope of the TLV. The 105 Flooding bit, the Transit bit and the Down bit. 107 There are two flooding types defined for this router capability 108 TLV's flooding scope. One is the domain wide flooding scope and 109 the other is the intra-area flooding scope. The F bit if set 110 indicates this TLV has the domain wide flooding scope. 112 The Transit bit can be used to signal the routers on the edge 113 of the IGP routing domain to redistribute this TLV information 114 into another routing process. How this is done is an application 115 specific issue and is outside the scope of this document. 117 The L1/L2 routers MUST observe the Down bit to avoid TLV leak 118 looping. This Down bit is not set when the router first originates 119 this TLV and it MUST be set when leaking into a lower level or into 120 another area of the same level. When the Down bit is set, this TLV 121 can no longer be leaked to a higher level or into another area 122 of the same level. This capability TLV MUST be preserved at the 123 level boundary during TLV leaking. The L1/L2 router SHOULD 124 NOT leak the TLV back into the same area which originated 125 this TLV. It MAY be able to alter certain capability contents 126 during TLV leaking when specified by applications. 128 4.2 Encoding of the Router Capability TLV 130 The following figure depicts the structure of this IS-IS Router 131 Capability TLV. 133 x CODE - 242 134 x LENGTH - total length of the value field in this TLV 135 x VALUE - 4-octet information flag, 4-octet router ID, 136 1-octet sub-tlv length, the mandatory sub-TLV code 1 137 for capability flags, and optional sub-TLVs for extra 138 capability information, structured as follows: 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 |F|T|D| Reserved Information Flag | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Router ID | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 |sub-TLV Length |Sub-TLV Type(1)| Length | N x 32bits... | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Other optional Sub-TLVs.. | 151 Figure 1. IS-IS Router Capability TLV 153 The first field is the 4-octet information flag, which consists 154 of the F, T and D bits, the reserved information bits. 156 Bit F represents the Flooding scope of the TLV. If set, this TLV 157 SHOULD be flooded to entire IGP domain. Otherwise, it SHOULD NOT 158 be leaked into the other level or another area in the same level. 160 Bit T determines the Transit behavior into other routing domains. 161 For example, if this bit is set, a router can leak this capability 162 information into another routing protocol. 164 Bit D represents Down/Up behavior during the TLV leaking. When the 165 capability is leaked from level 2 into level 1 or it is leaked into 166 another area of the same level, this D bit MUST be set. Otherwise 167 this bit MUST be cleared. 169 Router ID is an unsigned 32 bit number representing the router 170 that originates this router capability TLV. 172 The next octet of the TLV is the total sub-TLV length of this 173 router capability TLV. This sub-TLV length includes the first 174 mandatory sub-TLV. The minimum value of this field is 6. 176 The first sub-TLV with code 1 is a mandatory sub-TLV, the router 177 capability flag sub-TLV. The length is the length of this sub-TLV. 178 Its set to N x 4 octets. N starts from 1 and can be increased when 179 there is a need. Each 4 octets are referred to as a capability flag. 180 For each capability flag the bits are indexed from the most 181 significant to the least significant, where each bit represents one 182 router capability. 184 There can be other sub-TLVs after the first sub-TLV to include 185 extra information describing certain router capabilities. The 186 description of those sub-TLVs is outside the scope of this draft. 188 The above data structure can be replicated within this TLV, but 189 can not exceed the maximum length of 255 octets. If no other 190 sub-TLVs are used and the capability flag is the minimum 4 octets, 191 this encoding can contain up to 17 router capability TLVs where 192 each have a minimum of 15 octets of data(4 byte information flag, 193 4 byte router-id, 1 byte total sub-tlv length, 6 byte capability 194 flag). 196 4.3 Reserved IS-IS Router Capability Bits 198 We have assigned some pre-determined bits to the first capability 199 flag. 201 Bit Capabilities 203 0-3 Reserved 204 4 IS-IS graceful restart capable [4] 205 5 IS-IS and BGP blackhole avoidance capable [6] 206 6 IS-IS wide metric processing capable [3] 207 7 IS-IS short metric processing capable [1] 208 8 IS-IS hmac-md5 authentication capable [5] 209 9 IS-IS Traffic Engineering support [3] 210 10 IS-IS point-to-point over LAN [7] 211 11 IS-IS Path Computation Server discovery [10] 212 12 M-ISIS capable [8] 213 13 IS-IS IPv6 capable [9] 214 14-31 For future assignments 216 6. Security Consideration 218 This document does not introduce new security issues. The security 219 considerations pertaining to the original IS-IS protocol remain 220 relevant. 222 7. Acknowledgments 224 The idea for this work grew out of a conversation with Andrew Partan 225 and we would like to thank him for his contribution. 227 8. References 229 [1] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, 230 December 1990. 232 [2] ISO, "Intermediate system to Intermediate system routeing 233 information exchange protocol for use in conjunction with the 234 Protocol for providing the Connectionless-mode Network 235 Service (ISO 8473)," ISO/IEC 10589:1992. 237 [3] Li, T. et al, "IS-IS Extensions for Traffic Engineering", 238 Internet Draft, work in Progress. 240 [4] Shand, M., "Restart Signaling for IS-IS", Internet Draft, work 241 in Progress. 243 [5] Li, T., "IS-IS Cryptographic Authentication", Internet Draft, 244 work in progress. 246 [6] McPherson, D., "IS-IS Transient Blackhole Avoidance", Internet 247 Draft, work in progress. 249 [7] N. Shen, et al, "Point-to-point operation over LAN in 250 link-state-routing protocols", Internet Draft, work in 251 progress. 253 [8] T. Przygienda, N. Shen, N. Sheth, "M-ISIS: Multi Topology (MT) 254 Routing in IS-IS", Internet Draft, work in progress. 256 [9] C. Hopps, "Routing IPv6 with IS-IS", Internet Draft, work 257 in progress. 259 [10] Vasseur et al, "RSVP Path computation request and reply 260 " messages", draft-vasseur-mpls-computation-rsvp-te-03.txt, 261 work in progress 263 9. 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 Redback Networks 279 350 Holger Way 280 San Jose, CA 95134 281 e-mail: rahul@redback.com 282 Scott Shaffer 283 Genuity, Inc. 284 3 Van de Graaff Drive 285 PO Box 3073 286 Burlington, MA 01803 287 e-mail: sshaffer@genuity.com 289 JP Vasseur 290 Cisco Systems, Inc. 291 300 Beaver Brook Road 292 Boxborough , MA - 01719 293 USA 294 e-mail: jpv@cisco.com