idnits 2.17.1 draft-harrison-isis-ipv6-te-01.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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 420. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 448. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 412), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == 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 (November 2004) is 7096 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' == Outdated reference: A later version (-07) exists of draft-ietf-isis-ipv6-05 ** Obsolete normative reference: RFC 3784 (ref. 'TE') (Obsoleted by RFC 5305) ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'GMPLS') Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force J. Harrison 2 INTERNET-DRAFT J. Berger 3 Expires May 2005 M. Bartlett 4 Data Connection Ltd (DCL) 5 November 2004 7 IPv6 Traffic Engineering in IS-IS 8 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 or will be disclosed, and any of which I become aware will be 15 disclosed, in accordance with RFC 3668. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright Notice 38 Copyright (C) The Internet Society 2004. All Rights Reserved. 40 Abstract 42 This document specifies a method for exchanging IPv6 Traffic 43 Engineering information using the IS-IS routing protocol. The 44 described method uses three new TLVs, together with two new sub-TLVs 45 of the Extended IS Reachability TLV. The information distributed 46 allows a CSPF algorithm to calculate traffic engineered routes using 47 IPv6 addresses. 49 1. Terms 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119. 55 2. Overview 57 [TE] and [GMPLS] define a number of TLVs and sub-TLVs that allow 58 Traffic Engineering information to be disseminated by the IS-IS 59 protocol [IS-IS]. The addressing information passed in these TLVs is 60 IPv4 specific. 62 [IPv6] describes how the IS-IS protocol can be used to carry out SPF 63 routing for IPv6. It does this by defining IPv6 specific TLVs that 64 are analogous to the TLVs used by IS-IS for carrying IPv4 addressing 65 information. 67 MPLS Traffic Engineering is very successful and, as the use of IPv6 68 grows, there is a need to be able to support Traffic Engineering in 69 IPv6 networks. 71 This document defines the TLVs that allow Traffic Engineering 72 (including GMPLS TE) information to be carried in IPv6 IS-IS 73 networks. 75 3. Summary of operation 77 3.1 Identifying IS-IS links using IPv6 addresses 79 Each IS-IS link has certain properties - bandwidth, shared risk 80 link groups (SRLGs), switching capabilities and so on. The IS-IS 81 extensions defined in [TE] and [GMPLS] describe how to associate 82 these traffic engineering parameters with IS-IS links. These TLVs 83 use IPv4 addresses to identify the link (or local/remote link 84 identifiers on unnumbered links). 86 When IPv6 is used, a numbered link may be identified by IPv4 and/or 87 IPv6 interface addresses. The type of identifier used does not 88 affect the properties of the link - it still has the same bandwidth, 89 SRLGs, switching capabilities. 91 This document describes an approach for supporting IPv6 traffic 92 engineering, by defining TLV extensions that allow TE links and nodes 93 to be identified by IPv6 addresses. 95 3.1.1 IPv6 address types 97 An IPv6 address can have global, site-local or link-local scope. 99 - A link-local IPv6 address is valid only within the scope of a 100 single link, and may only be referenced on that link. 102 - A site-local IPv6 address is valid in the scope of a single 103 Autonomous System (AS). 105 - A global IPv6 address is valid within the scope of the Internet. 107 Because the IPv6 traffic engineering TLVs present in LSPs are 108 propagated across networks, they MUST NOT use link-local addresses. 110 As IS-IS only operates within the scope of a single AS, IS-IS does 111 not need to differentiate between global and site-local addresses. 113 3.2 IP addresses used in Traffic Engineering TLVs 115 This section lists the IP addresses used in the TLVs defined in 116 [TE] and [GMPLS], and gives an overview of the required IPv6 117 equivalents. 119 3.2.1 TE Router ID TLV 121 The TE Router ID TLV is a stable IPv4 address that is routable, 122 regardless of the state of each interface. 124 Similarly, for IPv6, it is useful to have a stable IPv6 address 125 identifying a TE node. The IPv6 TE Router ID TLV is defined in 126 section 4.1. 128 3.2.2 IPv4 Interface Address sub-TLV 130 This sub-TLV of the Extended IS Reachability TLV contains an 131 IPv4 address for the local end of a link. The equivalent IPv6 132 Interface Address sub-TLV is defined in section 4.2. 134 3.2.3 IPv4 Neighbor Address sub-TLV 136 This sub-TLV of the Extended IS Reachability TLV is used for 137 point-to-point links, and contains an IPv4 address for the neighbor's 138 end of a link. The equivalent IPv6 Neighbor Address sub-TLV is 139 defined in section 4.3. 141 In order to build the IPv6 Neighbor Address sub-TLV, an IS needs to 142 be able to get hold of a global (or site-local) IPv6 address for the 143 interface from the peer. To achieve this, the IPv6 Global Interface 144 Address TLV is defined in section 4.5. This TLV is included in the 145 IIH PDU and contains global or site-local IPv6 interface address 146 information. The TLV is used in addition to the IPv6 Interface 147 Address TLV defined in [IPv6], which, when used in the IIH PDU, 148 carries only link-local addresses. 150 3.2.4 IPv6 SRLG TLV 152 The SRLG TLV (type 138) defined in [GMPLS] identifies the 153 corresponding link using either local/remote IPv4 addresses or link 154 local/remote identifiers, and includes a flags field to indicate 155 which type of identifier is used. 157 When only IPv6 is used, we may not have either of these means of 158 identifying the corresponding Extended IS Reachability TLV or link. 160 There is no back-compatible way to modify the SRLG TLV (type 138) 161 to identify the link by IPv6 addresses, and therefore we need a new 162 TLV. 164 The IPv6 SRLG TLV is defined in section 4.4. 166 4. IPv6 TE TLVs 168 4.1 IPv6 TE Router ID TLV 170 The IPv6 Traffic Engineering Router ID TLV is TLV type 140. 172 The IPv6 TE Router ID TLV contains a 16-octet IPv6 address. A 173 stable, global or site-local IPv6 address SHOULD be used, so that the 174 router ID provides a routable address, regardless of the state of 175 a node's interfaces. 177 If a router does not implement traffic engineering, it MAY include or 178 omit the IPv6 Traffic Engineering Router ID TLV. If a router 179 implements traffic engineering for IPv6, it MUST include this TLV in 180 its LSP. This TLV MUST NOT be included more than once in an LSP. If 181 the TLV occurs more than once in an LSP, all except the first 182 instance is ignored. 184 Implementations MUST NOT inject a /128 prefix for the IPv6 TE router 185 ID into their forwarding table because this can lead to forwarding 186 loops when interacting with systems that do not support this TLV. 188 4.2 IPv6 Interface Address sub-TLV 190 The IPv6 Interface Address sub-TLV of the Extended IS Reachability 191 TLV has sub-TLV type 12. It contains a 16-octet IPv6 address for the 192 interface described by the (main) TLV. This sub-TLV can occur 193 multiple times. 195 Implementations MUST NOT inject a /128 prefix for the interface 196 address into their routing or forwarding table, because this can lead 197 to forwarding loops when interacting with systems that do not support 198 this sub-TLV. 200 If a router implements the basic TLV extensions described in [TE], it 201 MAY include or omit this sub-TLV. If a router implements IPv6 202 traffic engineering, it MUST include this sub-TLV (except on an 203 unnumbered point-to-point link, in which case the Link Local 204 Interface Identifiers sub-TLV is used instead). 206 This sub-TLV MUST NOT contain an IPv6 link-local address. 208 4.3 IPv6 Neighbor Address sub-TLV 210 The IPv6 Neighbor Address sub-TLV of the Extended IS Reachability TLV 211 has sub-TLV type 13. It contains a 16-octet IPv6 address for a 212 neighboring router on the link described by the (main) TLV. This 213 sub-TLV can occur multiple times. 215 Implementations MUST NOT inject a /128 prefix for the interface 216 address into their routing or forwarding table, because this can lead 217 to forwarding loops when interacting with systems that do not support 218 this sub-TLV. 220 If a router implements the basic TLV extensions described in [TE], it 221 MAY include or omit this sub-TLV. If a router implements IPv6 222 traffic engineering, it MUST include this sub-TLV for point-to-point 223 links (except on an unnumbered point-to-point link, in which case the 224 Link Local Interface Identifiers sub-TLV is used instead). 226 This sub-TLV MUST NOT contain an IPv6 link-local address. 228 4.4 IPv6 SRLG TLV 230 The IPv6 SRLG TLV has type 139. The TLV carries the Shared Risk Link 231 Group information (see Section "Shared Risk Link Group Information" 232 of [GMPLS-ROUTING]). 234 It contains a data structure consisting of: 236 - 6 octets of System ID 237 - 1 octet of Pseudonode Number 238 - 1 octet flags 239 - 16 octets of IPv6 interface address 240 - (optional) 16 octets of IPv6 neighbor address 241 - (variable) list of SRLG values, where each element in the list 242 has 4 octets. 244 The following illustrates encoding of the Value field of the 245 IPv6 SRLG TLV. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | System ID | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | System ID (cont.) | Pseudonode num| Flags | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | IPv6 interface address | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | IPv6 interface address (continued) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | IPv6 interface address (continued) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | IPv6 interface address (continued) | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | (optional) IPv6 neighbor address | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | IPv6 neighbor address (continued) | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | IPv6 neighbor address (continued) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | IPv6 neighbor address (continued) | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Shared Risk Link Group Value | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | ............ | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Shared Risk Link Group Value | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 The neighbor is identified by its System Id (6-octets), plus one 278 octet to indicate the pseudonode number if the neighbor is on a 279 LAN interface. 281 The flag octet indicates whether the IPv6 neighbor address is 282 included (set to 1), or not included (set to 0). Other values for 283 the flags field are reserved - an implementation receiving a value 284 for the flags field other than 0 or 1 SHOULD discard the TLV. 286 Note that this rule for processing the flags octet allows for future 287 extensibility of the IPv6 SRLG TLV. In particular, it allows 288 alternative means of identifying the corresponding link to be added 289 in the future. An implementation that does not understand such an 290 extension will simply discard the TLV, rather than attempting to 291 interpret the TLV incorrectly. 293 The length of this TLV is 24 + 4 * (number of SRLG values) + 16 (if 294 the IPv6 neighbor address is included). 296 To prevent an SRLG TLV and an IPv6 SRLG TLV in the same logical LSP 297 from contradicting each other, the following rules are applied. 299 - The IPv6 SRLG TLV MAY occur more than once within the IS-IS 300 logical LSP. 302 - There MUST NOT be more than one IPv6 SRLG TLV for a given link. 304 - The IPv6 SRLG TLV (type 139) MUST NOT be used to describe the 305 SRLGs for a given link if it is possible to use the SRLG TLV 306 (type 138). 308 In other words, if SRLGs are to be advertised for a link, and if 309 the Extended IS Reachability TLV describing a link contains IPv4 310 interface/neighbor address sub-TLVs or the link local identifiers 311 sub-TLV, then the SRLGs MUST be advertised in the SRLG TLV 312 (type 138). 314 4.5 IPv6 Global Interface Address TLV 316 The IPv6 Global Interface Address TLV is TLV type 233. The TLV 317 structure is identical to that of the IPv6 Interface Address TLV 318 defined in [IPv6], but the semantics are different. In particular, 319 the TLV is included in IIH PDUs for those interfaces using IPv6 TE 320 extensions. The TLV contains global or site-local IPv6 addresses 321 assigned to the interface that is sending the Hello. 323 The IPv6 Global Interface Address TLV is not used in LSPs. 325 5. Security Considerations 327 This document raises no new security considerations. 329 6. IANA Considerations 331 This document defines the following new IS-IS TLV types that need to 332 be reflected in the IS-IS TLV code-point registry: 334 Type Description IIH LSP SNP 335 ---- ---------------------- --- --- --- 336 139 IPv6 SRLG TLV n y n 337 140 IPv6 TE Router ID n y n 338 233 IPv6 Global Interface y n n 339 Address TLV 341 This document also defines the following new sub-TLV types of 342 top-level TLV 22 that need to be reflected in the IS-IS sub-TLV 343 registry for TLV 22: 345 Type Description Length 346 ---- ------------------------------ -------- 347 12 IPv6 Interface Address 16 348 13 IPv6 Neighbor Address 16 350 7. References 352 7.1 Normative References 354 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 355 Routeing Exchange Protocol for use in Conjunction with the 356 Protocol for Providing the Connectionless-mode Network 357 Service (ISO 8473)", ISO 10589, 2002. 359 [IPv6] C. Hopps, "Routing IPv6 with IS-IS", 360 draft-ietf-isis-ipv6-05.txt, January 2003 361 (work in progress). 363 [TE] H. Smit and T. Li, "Intermediate System to Intermediate 364 System (IS-IS) Extensions for Traffic Engineering (TE)", 365 RFC 3784, June 2004. 367 [GMPLS] K.Kompella and Y.Rekhter, "IS-IS Extensions in Support of 368 Generalized Multi-Protocol Label Switching", 369 draft-ietf-isis-gmpls-extensions-19.txt,November 2003 370 (work in progress). 372 7.2 Informative References 374 [GMPLS-ROUTING] 375 K.Kompella and Y.Rekhter, "Routing Extensions in Support of 376 Generalized MPLS", draft-ietf-ccamp-gmpls-routing-09.txt, 377 November 2003 (work in progress). 379 8. Authors' Addresses 381 Jon Harrison 382 Data Connection Ltd 383 100 Church Street 384 Enfield 385 EN2 6BQ 386 U.K. 387 Phone: +44 20 8366 1177 388 Email: jon.harrison@dataconnection.com 390 Jon Berger 391 Data Connection Ltd 392 100 Church Street 393 Enfield 394 EN2 6BQ 395 U.K. 396 Phone: +44 20 8366 1177 397 Email: jon.berger@dataconnection.com 399 Mike Bartlett 400 Data Connection Ltd 401 100 Church Street 402 Enfield 403 EN2 6BQ 404 U.K. 405 Phone: +44 20 8366 1177 406 Email: mike.bartlett@dataconnection.com 408 9. Full Copyright Statement 410 Copyright (C) The Internet Society 2004. This document is subject 411 to the rights, licenses and restrictions contained in BCP 78, and 412 except as set forth therein, the authors retain all their rights. 414 This document and the information contained herein are provided on an 415 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 416 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 417 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 418 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 419 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 420 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 422 This document may not be modified, and derivative works of it may 423 not be created, except to publish it as an RFC and to translate it 424 into languages other than English. 426 Intellectual Property Statement 428 The IETF takes no position regarding the validity or scope of any 429 Intellectual Property Rights or other rights that might be claimed to 430 pertain to the implementation or use of the technology described in 431 this document or the extent to which any license under such rights 432 might or might not be available; nor does it represent that it has 433 made any independent effort to identify any such rights. Information 434 on the IETF's procedures with respect to rights in IETF Documents can 435 be found in BCP 78 and BCP 79. 437 Copies of IPR disclosures made to the IETF Secretariat and any 438 assurances of licenses to be made available, or the result of an 439 attempt made to obtain a general license or permission for the use of 440 such proprietary rights by implementers or users of this 441 specification can be obtained from the IETF on-line IPR repository at 442 http://www.ietf.org/ipr. 444 The IETF invites any interested party to bring to its attention any 445 copyrights, patents or patent applications, or other proprietary 446 rights that may cover technology that may be required to implement 447 this standard. Please address the information to the IETF at 448 ietf-ipr@ietf.org.