idnits 2.17.1 draft-martin-isis-local-protect-cap-02.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 248. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 225. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 232. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 238. ** 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 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (February 2006) is 6646 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-ietf-isis-link-attr-01 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-ipfrr-framework-05 ** Downref: Normative reference to an Informational draft: draft-ietf-rtgwg-ipfrr-framework (ref. 'I-D.ietf-rtgwg-ipfrr-framework') == Outdated reference: A later version (-12) exists of draft-ietf-rtgwg-ipfrr-spec-base-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) -- Possible downref: Normative reference to a draft: ref. 'U-TURN' Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Martin, Ed. 3 Internet-Draft iPath Technologies 4 Expires: August 5, 2006 A. Atlas, Ed. 5 Google, Inc. 6 R. Torvi 7 Avici Systems, Inc. 8 D. Fedyk 9 Nortel Networks 10 February 2006 12 ISIS Extensions to support U-turn Alternates for IP/LDP Fast-Reroute 13 draft-martin-isis-local-protect-cap-02 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 5, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document specifies additional information that can inserted in 47 IS-IS LSPs to convey link capabilities that may be useful in certain 48 applications. In particular, an IS may convey that zero or more of 49 its links are explicit marked and/or implicit U-turn recipient 50 capable, which may be described as capable of identifying traffic as 51 U-turn traffic and redirecting the traffic to a suitable alternate. 52 The immediate applicability for these two link capabilities is in 53 support of local protection, provided by a U-turn alternate, in the 54 event of a link and/or node failure while the IS-IS area is 55 reconverging onto a new topology. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Signaling Link Capabilities . . . . . . . . . . . . . . . . . . 3 61 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 62 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 64 Intellectual Property and Copyright Statements . . . . . . . . . . 7 66 1. Introduction 68 Recently, an increasing interest in IGP traffic engineering using 69 intelligent metric assignment has led to the development and 70 deployment of techniques and methods to manage traffic distribution 71 and capacity expansion without explicit source routing [ref]. The 72 fundamental premise to this approach is that it reduces operational 73 complexity by leveraging existing and well-understood routing methods 74 to achieve effectivey the same ends as are possible using explicit 75 source routing, without adding any new technology to the routing 76 system. Many carriers have adopted this approach as a means to 77 better manage bandwidth utilization and overall network efficiency. 78 However, in many environments and under certain failure scenarios, 79 the IGP TE approach does not allow for fast restoration, as the IGP 80 must reconverge. While fast IGP convergence is a topic of great 81 interest, there is concern that a lower floor exists that, if 82 crossed, may have a negative impact on the stability of a network. 83 As the network diameter and node degree increase, this floor 84 invariably raises in some proportionate manner - that is, the bigger 85 the network, the slower the overall convergence. 87 Depending on the application, restoration time-tolerance varies. For 88 real-time applications, it is certainly reasonable to expect 89 restoration times in the <50 msec range. The Fast Reroute method 90 specified in [RFC4090] is one such mechanism to achieve these 91 restoration times, as a precomputed alternate path can service the 92 offered load that was destined for a failed link in a loop-free 93 fashion. However, this requires MPLS TE tunnels, which may not be a 94 desirable option for reasons mentioned above - namely, the increase 95 in complexity. 97 [I-D.ietf-rtgwg-ipfrr-spec-base], [I-D.ietf-rtgwg-ipfrr-framework], 98 and [U-TURN] have proposed an alternative to tunnel-based restoration 99 in IP networks that is independent of MPLS. Clearly, the ability to 100 traffic engineer for bandwidth efficiency and fast restoration are 101 attractive to network operators that are opposed to deploying MPLS- 102 based RSVP-TE. Nevertheless, the destination-based nature of the 103 classical IP routing paradigm does not afford any guarantee that an 104 alternate path around a failure is loop-free. [U-TURN] proposes such 105 a mechanism, however, this mechanism requires additional information 106 to be distributed via IS-IS flooding so as to convey to routers in an 107 area that the capability exists. 109 2. Signaling Link Capabilities 111 [RFC3784] defines extensions to IS-IS as specified in [IS-IS] and 112 extended in [RFC1195] to allow for traffic engineering parameters to 113 be flooded throughout an area. TLV 22, the extended IS-reachability 114 TLV is used to add additional information about an IS's connections 115 to other IS's, such as available bandwidth and color, by creating sub 116 TLVs within TLV 22. [I-D.ietf-isis-link-attr] introduces the notion 117 of extending TLV 22, sub-TLV 19 to signal an IS's capabilities. The 118 initial capabilities proposed in [I-D.ietf-isis-link-attr] are 119 orthogonal to the two proposed here; the "link excluded from local 120 protection path" flag is also used for U-turn alternates [U-TURN]. 122 This draft proposes the creation of two new flags in TLV 22, Sub TLV 123 19 for indicating an IS's ability to be a U-turn recipient. The 124 following bits are defined: 126 0x6: Explicit Marked U-turn Recipient Capable: When this bit is set, 127 an IS can apply the explicitly marked U-turn packet identification 128 method [U-TURN] to identify packets as U-turn packets and redirect 129 those U-turn packets towards an appropriate alternate next-hop, if 130 such is available. A neighbor, which wishes to use this link as a 131 U-turn alternate next-hop, should mark traffic sent on the link 132 into a U-turn alternate. 133 0x7: Implicit U-turn Recipient Capable: When this bit is set, an IS 134 can apply the implicit U-turn packet identification method 135 [U-TURN] to identify packets as U-turn packets and redirect those 136 U-turn packets towards an appropriate alternate next-hop, if such 137 is available. A neighbor, which wishes to use this link as a 138 U-turn alternate next-hop, should not mark traffic sent on the 139 link into a U-turn alternate. 141 3. Security Considerations 143 This document does not introduce any new security issues. 145 4. References 147 [I-D.ietf-isis-link-attr] 148 Vasseur, J. and S. Previdi, "Definition of an IS-IS Link 149 Attribute sub-TLV", draft-ietf-isis-link-attr-01 (work in 150 progress), May 2005. 152 [I-D.ietf-rtgwg-ipfrr-framework] 153 Shand, M. and S. Bryant, "IP Fast Reroute Framework", 154 draft-ietf-rtgwg-ipfrr-framework-05 (work in progress), 155 March 2006. 157 [I-D.ietf-rtgwg-ipfrr-spec-base] 158 Atlas, A. and A. Zinin, Ed., "Basic Specification for IP 159 Fast-Reroute: Loop-free Alternates", 160 draft-ietf-rtgwg-ipfrr-spec-base-05.txt (work in 161 progress), February 2006. 163 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 164 Routing Exchange Protocol for use in Conjunction with the 165 Protocol for Providing the Connectionless-mode Network 166 Service (ISO 8473)", ISO 10589. 168 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 169 dual environments", RFC 1195, December 1990. 171 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 172 System (IS-IS) Extensions for Traffic Engineering (TE)", 173 RFC 3784, June 2004. 175 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 176 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 177 May 2005. 179 [U-TURN] Atlas, A., Ed., "U-turn Alternates for IP/LDP Fast- 180 Reroute", draft-atlas-ip-local-protect-uturn-03.txt (work 181 in progress), February 2006. 183 Authors' Addresses 185 Christian Martin (editor) 186 iPath Technologies 188 Email: chris@ipath.net 190 Alia K. Atlas (editor) 191 Google, Inc. 192 1600 Amphitheatre Parkway 193 Mountain View, CA 94043 194 USA 196 Email: akatlas@alum.mit.edu 198 Raveendra Torvi 199 Avici Systems, Inc. 200 101 Billerica Avenue 201 N. Billerica, MA 01862 202 USA 204 Phone: +1 978 964 2026 205 Email: rtorvi@avici.com 207 Don Fedyk 208 Nortel Networks 209 600 Technology Park 210 Billerica, MA 01821 211 USA 213 Phone: +1 978 288 3041 214 Email: dwfedyk@nortelnetworks.com 216 Intellectual Property Statement 218 The IETF takes no position regarding the validity or scope of any 219 Intellectual Property Rights or other rights that might be claimed to 220 pertain to the implementation or use of the technology described in 221 this document or the extent to which any license under such rights 222 might or might not be available; nor does it represent that it has 223 made any independent effort to identify any such rights. Information 224 on the procedures with respect to rights in RFC documents can be 225 found in BCP 78 and BCP 79. 227 Copies of IPR disclosures made to the IETF Secretariat and any 228 assurances of licenses to be made available, or the result of an 229 attempt made to obtain a general license or permission for the use of 230 such proprietary rights by implementers or users of this 231 specification can be obtained from the IETF on-line IPR repository at 232 http://www.ietf.org/ipr. 234 The IETF invites any interested party to bring to its attention any 235 copyrights, patents or patent applications, or other proprietary 236 rights that may cover technology that may be required to implement 237 this standard. Please address the information to the IETF at 238 ietf-ipr@ietf.org. 240 Disclaimer of Validity 242 This document and the information contained herein are provided on an 243 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 244 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 245 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 246 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 247 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 248 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 250 Copyright Statement 252 Copyright (C) The Internet Society (2006). This document is subject 253 to the rights, licenses and restrictions contained in BCP 78, and 254 except as set forth therein, the authors retain all their rights. 256 Acknowledgment 258 Funding for the RFC Editor function is currently provided by the 259 Internet Society.