idnits 2.17.1 draft-raggarwa-isis-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 == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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 95: '... in the LSP, the router SHOULD set all...' RFC 2119 keyword, line 115: '...he L1/L2 routers MUST observe the Down...' RFC 2119 keyword, line 117: '... this TLV and it MUST be set when leak...' RFC 2119 keyword, line 120: '...s capability TLV MUST be preserved at ...' RFC 2119 keyword, line 121: '...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 230, 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 (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Acee Lindem (Redback Networks) 2 Internet Draft Naiming Shen (Redback Networks) 3 Expiration Date: August 2004 Rahul Aggarwal (Juniper Networks) 4 Scott Shaffer (Genuity, Inc.) 6 Extensions to IS-IS for Advertising Optional 7 Router Capabilities 9 draft-raggarwa-isis-cap-01.txt 11 1. Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026, except that the right to 15 produce derivative works is not granted. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 2. Abstract 34 It is useful for routers in an IS-IS domain to know of the capabilities 35 of their neighbors, and/or of other routers in the domain. This 36 draft proposes extensions to IS-IS for advertising optional router 37 capabilities. In particular it defines an optional Router Capability 38 TLV for IS-IS. 40 3. Motivation 42 It is useful for routers in a domain to know of the capabilities 43 of their IS-IS neighbors, and/or of other routers in the domain. This 44 can be useful for various purposes: 45 o In MPLS Traffic Engineering (TE) as a TE discovery mechanism 46 [10] to announce a LSR's TE capabilities like Path Computation 47 Server capability (Capability of a LSR to be a Path Computation 48 Server for TE LSP path computation) or the intention of a LSR to be 49 part of a particular MPLS TE mesh group. 50 o For network management and troubleshooting. It gives operators a 51 network wide view of IS-IS capabilities on different routers in the 52 network. The presence of a capability on a given router implies 53 that the software version supports the capability and the router is 54 configured to support it. On the other hand the absence of an 55 expected capability on a particular router can imply either 56 mis-configuration or an incorrect software version. Hence this 57 capability information can be used to track problems resulting from 58 mis-configuration or an incorrect software version. 60 There is no existing mechanism in IS-IS to advertise optional router 61 capabilities. We propose extensions to IS-IS for advertising these 62 optional capabilities. For current IS-IS capabilities this 63 advertisement will be used primarily for MPLS TE and informational 64 purposes. Conceivably, future capability advertisements could be 65 used for other purposes. 67 4. IS-IS Router Capability TLV 69 IS-IS [1] routers may optionally advertise their router 70 capabilities in the TLV with code type 242. This TLV specifies 71 the router ID of the router that originates the TLV, defines the 72 flooding scope of the TLV, specifies the router capability bits in 73 the first sub-TLV and certain capability related information in other 74 sub-TLVs. This draft does not specify how an application may use the 75 Router Capability TLV and such specification is outside the scope of 76 this draft. 78 The router ID is a 32 bit unsigned integer to represent the router 79 that originated this capability TLV. This is needed since this TLV 80 can be flooded over the entire domain, hence the router ID of the 81 originating router must be kept. 83 The capability bits are defined in a mandatory sub-TLV with 84 code 1. It starts as a 32 bits flag, where each bit can represent 85 a router capability. This flag can be expanded as needed to 86 include more capabilities. 88 Some of the router capabilities may require more information 89 than a single bit. The extra capability information can be encoded 90 as sub-TLVs under this router capability TLV. The definition 91 of these sub-TLVs is outside the scope of this draft. 93 If a router does not advertise this TLV, it does not imply that 94 the router does not support one or more of the defined capabilities. 95 If this TLV is included in the LSP, the router SHOULD set all 96 the defined bits corresponding to the capabilities which the 97 software supports, unless they are explicitly configured off. 99 4.1 Flooding Scope of the Router Capability TLV 101 There are three bits currently defined for this TLV in the 102 information flag to control the flooding scope of the TLV. The 103 Flooding bit, the Transit bit and the Down bit. 105 There are two flooding types defined for this router capability 106 TLV's flooding scope. One is the domain wide flooding scope and 107 the other is the intra-area flooding scope. The F bit if set 108 indicates this TLV has the domain wide flooding scope. 110 The Transit bit can be used to signal the routers on the edge 111 of the IGP routing domain to redistribute this TLV information 112 into another routing process. How this is done is an application 113 specific issue and is outside the scope of this document. 115 The L1/L2 routers MUST observe the Down bit to avoid TLV leak 116 looping. This Down bit is not set when the router first originates 117 this TLV and it MUST be set when leaking into a lower level or into 118 another area of the same level. When the Down bit is set, this TLV 119 can no longer be leaked to a higher level or into another area 120 of the same level. This capability TLV MUST be preserved at the 121 level boundary during TLV leaking. The L1/L2 router SHOULD 122 NOT leak the TLV back into the same area which originated 123 this TLV. It MAY be able to alter certain capability contents 124 during TLV leaking when specified by applications. 126 4.2 Encoding of the Router Capability TLV 128 The following figure depicts the structure of this IS-IS Router 129 Capability TLV. 131 x CODE - 242 132 x LENGTH - total length of the value field in this TLV 133 x VALUE - 4-octet information flag, 4-octet router ID, 134 1-octet sub-tlv length, the mandatory sub-TLV code 1 135 for capability flags, and optional sub-TLVs for extra 136 capability information, structured as follows: 138 0 1 2 3 139 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 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 |F|T|D| Reserved Information Flag | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Router ID | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 |sub-TLV Length |Sub-TLV Type(1)| Length | N x 32bits... | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Other optional Sub-TLVs.. | 149 Figure 1. IS-IS Router Capability TLV 151 The first field is the 4-octet information flag, which consists 152 of the F, T and D bits, the reserved information bits. 154 Bit F represents the Flooding scope of the TLV. If set, this TLV 155 SHOULD be flooded to entire IGP domain. Otherwise, it SHOULD NOT 156 be leaked into the other level or another area in the same level. 158 Bit T determines the Transit behavior into other routing domains. 159 For example, if this bit is set, a router can leak this capability 160 information into another routing protocol. 162 Bit D represents Down/Up behavior during the TLV leaking. When the 163 capability is leaked from level 2 into level 1 or it is leaked into 164 another area of the same level, this D bit MUST be set. Otherwise 165 this bit MUST be cleared. 167 Router ID is an unsigned 32 bit number representing the router 168 that originates this router capability TLV. 170 The next octet of the TLV is the total sub-TLV length of this 171 router capability TLV. This sub-TLV length includes the first 172 mandatory sub-TLV. The minimum value of this field is 6. 174 The first sub-TLV with code 1 is a mandatory sub-TLV, the router 175 capability flag sub-TLV. The length is the length of this sub-TLV. 176 Its set to N x 4 octets. N starts from 1 and can be increased when 177 there is a need. Each 4 octets are referred to as a capability flag. 178 For each capability flag the bits are indexed from the most 179 significant to the least significant, where each bit represents one 180 router capability. 182 There can be other sub-TLVs after the first sub-TLV to include 183 extra information describing certain router capabilities. The 184 description of those sub-TLVs is outside the scope of this draft. 186 The above data structure can be replicated within this TLV, but 187 can not exceed the maximum length of 255 octets. If no other 188 sub-TLVs are used and the capability flag is the minimum 4 octets, 189 this encoding can contain up to 17 router capability TLVs where 190 each have a minimum of 15 octets of data(4 byte information flag, 191 4 byte router-id, 1 byte total sub-tlv length, 6 byte capability 192 flag). 194 4.3 Reserved IS-IS 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 IS-IS graceful restart capable [4] 203 5 IS-IS and BGP blackhole avoidance capable [6] 204 6 IS-IS wide metric processing capable [3] 205 7 IS-IS short metric processing capable [1] 206 8 IS-IS hmac-md5 authentication capable [5] 207 9 IS-IS Traffic Engineering support [3] 208 10 IS-IS point-to-point over LAN [7] 209 11 IS-IS Path Computation Server discovery [10] 210 12 M-ISIS capable [8] 211 13 IS-IS IPv6 capable [9] 212 14-31 For future assignments 214 6. Security Consideration 216 This document does not introduce new security issues. The security 217 considerations pertaining to the original IS-IS protocol remain 218 relevant. 220 7. Acknowledgments 222 The idea for this work grew out of a conversation with Andrew Partan 223 and we would like to thank him for his contribution. 225 8. References 227 [1] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, 228 December 1990. 230 [2] ISO, "Intermediate system to Intermediate system routeing 231 information exchange protocol for use in conjunction with the 232 Protocol for providing the Connectionless-mode Network 233 Service (ISO 8473)," ISO/IEC 10589:1992. 235 [3] Li, T. et al, "IS-IS Extensions for Traffic Engineering", 236 Internet Draft, work in Progress. 238 [4] Shand, M., "Restart Signaling for IS-IS", Internet Draft, work 239 in Progress. 241 [5] Li, T., "IS-IS Cryptographic Authentication", Internet Draft, 242 work in progress. 244 [6] McPherson, D., "IS-IS Transient Blackhole Avoidance", Internet 245 Draft, work in progress. 247 [7] N. Shen, et al, "Point-to-point operation over LAN in 248 link-state-routing protocols", Internet Draft, work in 249 progress. 251 [8] T. Przygienda, N. Shen, N. Sheth, "M-ISIS: Multi Topology (MT) 252 Routing in IS-IS", Internet Draft, work in progress. 254 [9] C. Hopps, "Routing IPv6 with IS-IS", Internet Draft, work 255 in progress. 257 [10] Vasseur et al, "RSVP Path computation request and reply 258 " messages", draft-vasseur-mpls-computation-rsvp-te-03.txt, 259 work in progress 261 9. Author Information 263 Acee Lindem 264 Redback Networks 265 350 Holger Way 266 San Jose, CA 95134 267 e-mail: acee@redback.com 269 Naiming Shen 270 Redback Networks 271 350 Holger Way 272 San Jose, CA 95134 273 e-mail: naiming@redback.com 275 Rahul Aggarwal 276 Juniper Networks 277 1194 N. Mathilda Avenue 278 San Jose, CA 94089 279 e-mail: rahul@juniper.net 280 Scott Shaffer 281 Genuity, Inc. 282 3 Van de Graaff Drive 283 PO Box 3073 284 Burlington, MA 01803 285 e-mail: sshaffer@genuity.com