idnits 2.17.1 draft-bonaventure-isis-ordered-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 345. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([RTG-OFIB]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 237: '...in this document SHOULD send HELLO PDU...' RFC 2119 keyword, line 243: '...b-TLV), a router MUST ensure that the ...' RFC 2119 keyword, line 247: '...essage. A router MAY send a HELLO PDU ...' RFC 2119 keyword, line 249: '...ission. A router MAY retransmit the sa...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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) == Missing Reference: 'ISIS-CAP' is mentioned on line 111, but not defined == Missing Reference: 'RFC' is mentioned on line 257, but not defined == Unused Reference: 'IS-IS' is defined on line 291, but no explicit reference was found in the text == Unused Reference: 'PFOB05' is defined on line 300, but no explicit reference was found in the text == Unused Reference: 'RFC3567' is defined on line 309, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-ipfrr-framework-04 ** Downref: Normative reference to an Informational draft: draft-ietf-rtgwg-ipfrr-framework (ref. 'IPFRR') -- Possible downref: Non-RFC (?) normative reference: ref. 'PFOB05' == Outdated reference: A later version (-02) exists of draft-francois-ordered-fib-00 ** Downref: Normative reference to an Informational draft: draft-francois-ordered-fib (ref. 'RTG-OFIB') -- Unexpected draft version: The latest known version of draft-vasseur-isis-caps is -02, but you're referring to -06. -- Possible downref: Normative reference to a draft: ref. 'ISISCAP' ** Obsolete normative reference: RFC 3567 (Obsoleted by RFC 5304) Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Olivier Bonaventure 3 INTERNET DRAFT Pierre Francois 4 UCLouvain 5 Mike Shand 6 Stefano Previdi 7 cisco 8 February, 2006 9 Expires August, 2006 11 ISIS extensions for ordered FIB updates 12 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress". 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on August 30, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document proposes extensions to allow IS-IS to support the 46 ordered convergence defined in [RTG-OFIB] that allows to avoid 47 transient forwarding loops during the FIB updates that follow a non- 48 urgent topology change. 50 1 Introduction 52 In large ISP networks, topology changes are frequent events. When a 53 link metric changes, the router responsible for the changing link 54 floods a new LSP and forces all routers to recompute their routing 55 table and update their FIB. This routing convergence is that it can 56 lead to packet losses due to transient forwarding loops [RTG-OFIB]. 58 There are various types of topology changes in IP networks. Sudden 59 failures of unprotected links are urgent and should be handled by 60 using a normal, fast, convergence of the link state routing protocol. 61 However, there are frequent topology changes that are non-urgent. For 62 example, operators often need to enable or disable links for short 63 periods of time during maintenance operations. Another example are 64 the IP networks where traffic engineering is performed by changing 65 the ISIS link metrics. These events are non-urgent and they should 66 not cause packet losses or transient forwarding loops. Transient 67 forwarding loops can be avoided by forcing the routers to orderly 68 update their FIB as proposed in [RTG-OFIB] 70 In this document, we propose IS-IS extensions allowing IS-IS routers 71 to implement the ordered FIB update described in [RTG-OFIB]. We first 72 describe the considered topology changes in section 2. Section 3 73 defines the new IS-IS TLVs that are used to support [RTG-OFIB]. 75 2. Graceful topology changes 77 In this section, we describe two types of graceful topology changes. 78 The first one is the change of a link metric (increase or decrease). 79 The second one is the change of the settings of the overload bit (Set 80 to Unset or Unset to Set). 82 2.1 Change in link metric 84 The first change that we consider is a modification of the metric 85 associated to a link. This change can be a metric increase or a 86 metric decrease. A non-urgent link shutdown can be converted into a 87 weight change by doing the topology change in two steps. First, the 88 metric of the link is set to the highest possible value. This 89 triggers an ordered FIB update. After the FIB update, the link can 90 be safely removed without risking transient loops. Similarly, a 91 failure of a protected link [IPFRR] [MPLSFRR] can be handled as a 92 non-urgent failure. 94 2.2 Overload status change 96 The second change that we consider is the transition of the overload 97 from Set to Unset or from Unset to Set. 99 3. Extensions to IS-IS 101 In this section, we describe the IS-IS extensions that are required 102 to support ordered FIB updates that allow to avoid transient loops. 103 There are two types of new TLVs. First, we define a capability sub- 104 TLV to allow a router to advertise its ability to support ordered FIB 105 updates. Second, we define a TLVs to be used inside the IS-IS Hello 106 PDUs to implement the completion messages defined in [RTG-OFIB]. 108 3.1 Ordered FIB capability sub-TLV 110 We define a FIB capability sub-TLV (advertised in the IS-IS 111 CAPABILITY TLV defined in [ISIS-CAP] ) to allow routers to determine 112 which routers in the network support the ordered FIB updates. The FIB 113 capability sub-TLV is composed of 1 octet for the type, 1 octet 114 specifying the TLV length and a value field. The FIB capability TLV 115 is used to advertise the type of ordered FIB updates supported by 116 this router. The FIB capability sub-TLV shall only be flooded inside 117 the current area. 119 TYPE: TBD (Ordered FIB capability sub-TLV) 120 LENGTH: 1 byte 121 VALUE: Indicates the version of the ordered FIB update supported 122 by the router. This document defines version 1. 124 This ordered FIB capability sub-TLV must be sent in a router 125 capability TLV where the S bit is set to 0x0 and the D bit is set to 126 0x0 according to the leaking rules defined in [ISISCAP]. 128 3.2 Completion message TLV 130 We define a new type of TLV to encode inside the IS-IS Hello PDUs the 131 completion messages proposed in [RTG-OFIB]. A IS-IS Hello PDU may 132 carry several completion messages. Each completion message is encoded 133 as a sub-TLV inside the completion message TLV. 135 Type TBD (Completion TLV) 136 Length # of bytes in the value field (variable) 137 Value : one or several sub-TLVs defined below 139 This document defines three types of sub-TLVs for the completion 140 messages. 142 3.2.1 Metric change sub-TLV 143 The metric change sub-TLV shall be used as a completion message when 144 the metric of a link changes. This happens when a metric is changed 145 manually. It is also possible to use the mechanisms defined in [RTG- 146 OFIB] and this document for link failures. For example, when a link 147 is shutdown manually, the router could first advertise the link with 148 metric maxmetric-1 as a non-urgent change to let all routers apply 149 the ordered FIB update. Later, the link can be safely removed without 150 risking transient loops. A router could use the same technique when 151 one of its protected links fails. 153 We define two types of metric changes sub-TLV that are used inside 154 the completion TLV. The first one is used with wide metrics and the 155 second one with normal metrics. We expect that most deployments will 156 use wide metrics. 158 Type TBD (Wide Metric change sub-TLV) 159 Length # of bytes in the value field (21) 160 Value 161 No. of bytes 162 +-----------------------+ 163 | 0 0 0 0 0 0 0 |Ack | 1 164 +-----------------------+ 165 | Upstream Node Id | 7 166 +-----------------------+ 167 | Downstream Node Id | 7 168 +-----------------------+ 169 | Old metric | 3 170 +-----------------------+ 171 | New metric | 3 172 +-----------------------+ 173 Figure 1: New sub-TLV for (wide) metric change completion message 175 In the Wide metric change sub-TLV, the rightmost bit of the first 176 byte is used to indicate whether it corresponds to a completion 177 message (value 0) or an acknowledgment (value 1). The upstream and 178 downstream node Ids are the system identifiers of the link whose 179 metric changes. "Old metric" is the previous value of the wide metric 180 for this link and "New metric" the current value. 182 A similar sub-TLV is also defined for the normal metric. As current 183 implementations of IS-IS only support the default metric, we do not 184 consider changes in the delay, error or expense metrics. 186 Type TBD (Normal Metric change sub-TLV) 187 Length # of bytes in the value field (17) 188 Value 189 No. of bytes 190 +-----------------------+ 191 | 0 0 0 0 0 0 0 |Ack | 1 192 +-----------------------+ 193 | Upstream Node Id | 7 194 +-----------------------+ 195 | Downstream Node Id | 7 196 +-----------------------+ 197 | Old Default metric | 1 198 +-----------------------+ 199 | New Default metric | 1 200 +-----------------------+ 202 Figure 2: New sub-TLV for (normal) metric change completion message 204 The Default metric shall be encoded as in normal LSPs. 206 3.2.2 Overload change sub-TLV 208 The overload change sub-TLV is used to encode the changes to the 209 Overload Bit. 211 Type TBD (Overload change sub-TLV) 212 Length # of octets in the value field (10) 213 Value 214 No. of bytes 216 +-----------------------+ 217 |Old|New| 0 0 0 0 0 Ack | 1 218 +-----------------------+ 219 | Node Id | 7 220 +-----------------------+ 222 Figure 3: New sub-TLV for Overload bit change 224 The first octet contains three useful bits. The leftmost bit is the 225 old value of the overload bit, the next bit is the new value of the 226 overload bit and rightmost bit is the acknowledgment bit. The Node Id 227 is the system identifier of the node whose overload bit change 228 gracefully. 230 3.3 Utilization of the completion messages 232 The TLVs defined in sections 3.2 and 3.3 allow to implement the 233 completion messages specified in [RTG-OFIB]. Each sub-TLV corresponds 234 to a completion message for one topological change. The completion 235 TLV in one HELLO PDU may carry several sub-TLVs and thus several 236 completion messages. A router supporting the ordered FIB update 237 defined in this document SHOULD send HELLO PDUs containing the 238 completion messages according to the rules defined in [RTG-OFIB]. 240 To ensure a reliable delivery of the completion messages, an 241 acknowledgment scheme is used. Upon reception of a HELLO PDU 242 containing a completion message (rightmost bit of the first byte set 243 to 0 in the sub-TLV), a router MUST ensure that the next HELLO PDU 244 that it will send to this neighbor will contain, in the completion 245 TLV, the same sub-TLV but with the rightmost bit of the first byte 246 set to one. This sub-TLV is used to acknowledge the completion 247 message. A router MAY send a HELLO PDU immediately in response to a 248 receive completion message or wait for the next scheduled Hello 249 transmission. A router MAY retransmit the same completion message in 250 several HELLO PDUs to ensure that they are correctly received by the 251 neighbour. 253 5. Security considerations 255 This document raises no new security issues for IS-IS. For the 256 ordered FIB capability sub-TLV, the discussion in [ISISCAP] is 257 applicable. The authentication mechanisms defined in [RFC] can be 258 used to authenticate the Hello PDUs that carry the completion 259 messages if required. 261 6. IANA considerations 263 IANA will assign a new IS-IS sub-TLV code-point for the order FIB 264 capability sub-TLV that can appear inside the Router Capability TLV 265 defined in [ISISCAP]. 267 IANA will assign a new IS-IS TLV code-point for the completion TLV. 268 This TLV can only appear inside Hello PDUs. 270 Name Value IIH LSP SNP 271 ---------------------- ----- --- --- --- 272 Completion messages TLV TBD y n n 274 IANA will maintain a registry with the sub-TLVs defined for the 275 completion messages TLV. This document defines three sub-TLVs : 277 Name Value 278 ---------------------- ----- 279 Normal metric change sub-TLV TBD 280 Wide metric change sub-TLV TBD 281 Overload change sub-TLV TBD 283 7. Conclusion 285 In this document, we have proposed a set of IS-IS TLVs that allows 286 routers using IS-IS to support the ordered FIB convergence 287 and the completion messages proposed in [RTG-OFIB]. 289 References 291 [IS-IS] "Intermediate system to Intermediate system routeing 292 information exchange protocol for use in conjunction 293 with the Protocol for providing the Connectionless-mode 294 Network Service (ISO 8473)," ISO/IEC 10589:2002, 295 Second Edition. 296 [IPFRR] M. Shand, S. Bryant, IP Fast Reroute Framework, 297 draft-ietf-rtgwg-ipfrr-framework-04.txt, October 2005 298 [MPLSFRR] Pan, P. et al, "Fast Reroute Extensions to 299 RSVP-TE for LSP Tunnels", RFC 4090. 300 [PFOB05] P. Francois, O. Bonaventure. Avoiding transient loops 301 during IGP convergence. IEEE INFOCOM 2005, March 2005, 302 Miami, Fl., USA 303 [RTG-OFIB] P. Francois, O. Bonaventure, M. Shand, S. Previdi, S. Bryant, 304 Loop-free convergence using ordered FIB updates, Internet draft, 305 draft-francois-ordered-fib-00.txt, work in progress, February 2006 306 [ISISCAP] J.-P. Vasseur, S. Previdi, M. Shand, IS-IS extensions for 307 advertising router capabilities, Internet draft, 308 draft-vasseur-isis-caps-06.txt, February 2004, work in progress 309 [RFC3567] T. Li, R. Atkinson, Intermediate System to Intermediate 310 System (IS-IS), Cryptographic Authentication, July 2003, RFC3567 312 Authors Addresses 314 Olivier Bonaventure, Pierre Francois 315 Universite catholique de Louvain 316 Email: FirstName.LastName@uclouvain.be 317 URL : http://www.info.ucl.ac.be/people/OBO/ 319 Stefano Previdi, Mike Shand 320 Cisco Systems 321 Email: {sprevidi,mshand}@cisco.com 323 Intellectual Property Statement 325 The IETF takes no position regarding the validity or scope of any 326 Intellectual Property Rights or other rights that might be claimed to 327 pertain to the implementation or use of the technology described in 328 this document or the extent to which any license under such rights 329 might or might not be available; nor does it represent that it has 330 made any independent effort to identify any such rights. Information 331 on the procedures with respect to rights in RFC documents can be 332 found in BCP 78 and BCP 79. 334 Copies of IPR disclosures made to the IETF Secretariat and any 335 assurances of licenses to be made available, or the result of an 336 attempt made to obtain a general license or permission for the use of 337 such proprietary rights by implementers or users of this 338 specification can be obtained from the IETF on-line IPR repository at 339 http://www.ietf.org/ipr. 341 The IETF invites any interested party to bring to its attention any 342 copyrights, patents or patent applications, or other proprietary 343 rights that may cover technology that may be required to implement 344 this standard. Please address the information to the IETF at 345 ietf-ipr@ietf.org. 347 Disclaimer of Validity 349 This document and the information contained herein are provided on an 350 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 351 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 352 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 353 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 354 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 355 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 357 Copyright Statement 359 Copyright (C) The Internet Society (2006). This document is subject 360 to the rights, licenses and restrictions contained in BCP 78, and 361 except as set forth therein, the authors retain all their rights. 363 Acknowledgment 365 Funding for the RFC Editor function is currently provided by the 366 Internet Society.