idnits 2.17.1 draft-ietf-ccamp-isis-interas-te-extension-03.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 876. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 859. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 865. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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.) -- 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) ** Obsolete normative reference: RFC 4971 (ref. 'ISIS-CAP') (Obsoleted by RFC 7981) -- Obsolete informational reference (is this intentional?): RFC 3784 (ref. 'ISIS-TE') (Obsoleted by RFC 5305) -- Obsolete informational reference (is this intentional?): RFC 4205 (ref. 'GMPLS-TE') (Obsoleted by RFC 5307) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group M. Chen 2 Internet Draft Renhai Zhang 3 Category: Standards Track Huawei Technologies Co.,Ltd 4 Created: August 25, 2008 Xiaodong Duan 5 Expires: February 25, 2009 China Mobile 7 ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching 8 (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering 10 draft-ietf-ccamp-isis-interas-te-extension-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that 15 any applicable patent or other IPR claims of which he or she is 16 aware have been or will be disclosed, and any of which he or she 17 becomes aware will be disclosed, in accordance with Section 6 of 18 BCP 79. 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 Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference 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/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on January 25, 2009. 38 Abstract 40 This document describes extensions to the ISIS (ISIS) protocol to 41 support Multiprotocol Label Switching (MPLS) and Generalized MPLS 42 (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems 43 (ASes). It defines ISIS-TE extensions for the flooding of TE 44 information about inter-AS links which can be used to perform inter- 45 AS TE path computation. 47 No support for flooding information from within one AS to another AS 48 is proposed or defined in this document. 50 Conventions used in this document 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC-2119 [RFC2119]. 56 Table of Contents 58 1. Introduction.................................................2 59 2. Problem Statement............................................3 60 2.1. A Note on Non-Objectives................................4 61 2.2. Per-Domain Path Determination...........................4 62 2.3. Backward Recursive Path Computation.....................6 63 3. Extensions to ISIS-TE........................................7 64 3.1. Inter-AS Reachability TLV...............................8 65 3.2. TE Router ID............................................9 66 3.3. Sub-TLV Detail.........................................10 67 3.3.1. Remote AS Number Sub-TLV..........................10 68 3.3.2. IPv4 Remote ASBR ID Sub-TLV.......................11 69 3.3.3. IPv6 Remote ASBR ID Sub-TLV.......................11 70 3.3.4. IPv4 TE Router ID sub-TLV.........................12 71 3.3.5. IPv6 TE Router ID sub-TLV.........................13 72 4. Procedure for Inter-AS TE Links.............................13 73 4.1. Origin of Proxied TE Information.......................15 74 5. Security Considerations.....................................15 75 6. IANA Considerations.........................................16 76 6.1. Inter-AS Reachability TLV..............................16 77 6.2. Sub-TLVs for the Inter-AS Reachability TLV.............16 78 6.3. Sub-TLVs for the IS-IS Router Capability TLV...........17 79 7. Acknowledgments.............................................17 80 8. References..................................................17 81 8.1. Normative References...................................17 82 8.2. Informative References.................................18 83 Authors' Addresses.............................................19 84 Intellectual Property Statement................................19 85 Disclaimer of Validity.........................................20 86 Copyright Statement............................................20 88 1. Introduction 90 [ISIS-TE] defines extensions to the ISIS protocol [ISIS] to support 91 intra-area Traffic Engineering (TE). The extensions provide a way of 92 encoding the TE information for TE-enabled links within the network 93 (TE links) and flooding this information within an area. The 94 Extended IS Reachability TLV and Traffic Engineering Router ID TLV, 95 which are defined in [ISIS-TE], are used to carry such TE 96 information. The Extended IS Reachability TLV has several nested 97 sub-TLVs which describe the TE attributes for a TE link. 99 [ISIS-TE-V3] and [GMPLS-TE] define similar extensions to ISIS [ISIS] 100 in support of IPv6 and GMPLS traffic engineering respectively. 102 Requirements for establishing Multiprotocol Label Switching (MPLS) 103 TE Label Switched Paths (LSPs) that cross multiple Autonomous 104 Systems (ASes) are described in [INTER-AS-TE-REQ]. As described in 105 [INTER-AS-TE-REQ], a method SHOULD provide the ability to compute a 106 path spanning multiple ASes. So a path computation entity that may 107 be the head-end Label Switching Router (LSR), an AS Border Router 108 (ASBR), or a Path Computation Element (PCE [PCE]) needs to know the 109 TE information not only of the links within an AS, but also of the 110 links that connect to other ASes. 112 In this document, a new TLV, which is referred to as the Inter-AS 113 Reachability TLV, is defined to advertise inter-AS TE information, 114 three new sub-TLVs are defined for inclusion in the Inter-AS 115 Reachability TLV to carry the information about the remote AS number 116 and remote ASBR ID. The sub-TLVs defined in [ISIS-TE], [ISIS-TE-V3] 117 and other documents for inclusion in the Extended IS Reachability 118 TLV for describing the TE properties of a TE link are applicable to 119 be included in the Inter-AS Reachability TLV for describing the TE 120 properties of an inter-AS TE link as well. And two more new sub-TLVs 121 are defined for inclusion in the IS-IS Router Capability TLV to 122 carry the TE Router ID when TE Router ID needs to reach all routers 123 within an entire ISIS routing domain. The extensions are equally 124 applicable to IPv4 and IPv6 as identical extensions to [ISIS-TE] and 125 [ISIS-TE-V3]. The detailed definitions and procedures are discussed 126 in the following sections. 128 This document does not propose or define any mechanisms to advertise 129 any other extra-AS TE information within ISIS. See Section 2.1 for a 130 full list of non-objectives for this work. 132 2. Problem Statement 134 As described in [INTER-AS-TE-REQ], in the case of establishing an 135 inter-AS TE LSP traversing multiple ASes, the Path message [RFC3209] 136 may include the following elements in the Explicit Route Object (ERO) 137 in order to describe the path of the LSP: 139 - a set of AS numbers as loose hops; and/or 141 - a set of LSRs including ASBRs as loose hops. 143 Two methods for determining inter-AS paths are currently being 144 discussed. The per-domain method [PD-PATH] determines the path one 145 domain at a time. The backward recursive method [BRPC] uses 146 cooperation between PCEs to determine an optimum inter-domain path. 147 The sections that follow examine how inter-AS TE link information 148 could be useful in both cases. 150 2.1. A Note on Non-Objectives 152 It is important to note that this document does not make any change 153 to the confidentiality and scaling assumptions surrounding the use 154 of ASes in the Internet. In particular, this document is conformant 155 to the requirements set out in [INTER-AS-TE-REQ]. 157 The following features are explicitly excluded: 159 o There is no attempt to distribute TE information from within one 160 AS to another AS. 162 o There is no mechanism proposed to distribute any form of TE 163 reachability information for destinations outside the AS. 165 o There is no proposed change to the PCE architecture or usage. 167 o TE aggregation is not supported or recommended. 169 o There is no exchange of private information between ASes. 171 o No ISIS adjacencies are formed on the inter-AS link. 173 2.2. Per-Domain Path Determination 175 In the per-domain method of determining an inter-AS path for an 176 MPLS-TE LSP, when an LSR that is an entry-point to an AS receives a 177 Path message from an upstream AS with an ERO containing a next hop 178 that is an AS number, it needs to find which LSRs (ASBRs) within the 179 local AS are connected to the downstream AS so that it can compute a 180 TE LSP segment across the local AS to one of those LSRs and forward 181 the Path message to it and hence into the next AS. See Figure 1 for 182 an example: 184 R1------R3----R5-----R7------R9-----R11 185 | | \ | / | 186 | | \ | ---- | 187 | | \ | / | 188 R2------R4----R6 --R8------R10----R12 189 : : 190 <-- AS1 -->:<---- AS2 --->:<--- AS3 ---> 192 Figure 1: Inter-AS Reference Model 194 The figure shows three ASes (AS1, AS2, and AS3) and twelve LSRs (R1 195 through R12). R3 and R4 are ASBRs in AS1. R5, R6, R7, and R8 are 196 ASBRs in AS2. R9 and R10 are ASBRs in AS3. 198 If an inter-AS TE LSP is planned to be established from R1 to R12, 199 the AS sequence will be: AS1, AS2, AS3. 201 Suppose that the Path message enters AS2 from R3. The next hop in 202 the ERO shows AS3, and R5 must determine a path segment across AS2 203 to reach AS3. It has a choice of three exit points from AS2 (R6, R7, 204 and R8) and it needs to know which of these provide TE connectivity 205 to AS3, and whether the TE connectivity (for example, available 206 bandwidth) is adequate for the requested LSP. 208 Alternatively, if the next hop in the ERO is the entry ASBR for AS3 209 (say R9), R5 needs to know which of its exit ASBRs has a TE link 210 that connects to R9. Since there may be multiple ASBRs that are 211 connected to R9 (both R7 and R8 in this example), R5 also needs to 212 know the TE properties of the inter-AS TE links so that it can 213 select the correct exit ASBR. 215 Once the path message reaches the exit ASBR, any choice of inter-AS 216 TE link can be made by the ASBR if not already made by entry ASBR 217 that computed the segment. 219 More details can be found in the Section 4. of [PD-PATH], which 220 clearly points out why advertising of inter-AS links is desired. 222 To enable R5 to make the correct choice of exit ASBR the following 223 information is needed: 225 o List of all inter-AS TE links for the local AS. 227 o TE properties of each inter-AS TE link. 229 o AS number of the neighboring AS connected to by each inter-AS TE 230 link. 232 o Identity (TE Router ID) of the neighboring ASBR connected to by 233 each inter-AS TE link. 235 In GMPLS networks further information may also be required to select 236 the correct TE links as defined in [GMPLS-TE]. 238 The example above shows how this information is needed at the entry 239 point ASBRs for each AS (or the PCEs that provide computation 240 services for the ASBRs), but this information is also needed 241 throughout the local AS if path computation function is fully 242 distributed among LSRs in the local AS, for example to support LSPs 243 that have start points (ingress nodes) within the AS. 245 2.3. Backward Recursive Path Computation 247 Another scenario using PCE techniques has the same problem. [BRPC] 248 defines a PCE-based TE LSP computation method (called Backward 249 Recursive Path Computation) to compute optimal inter-domain 250 constrained MPLS-TE or GMPLS LSPs. In this path computation method, 251 a specific set of traversed domains (ASes) are assumed to be 252 selected before computation starts. Each downstream PCE in domain(i) 253 returns to its upstream neighbor PCE in domain(i-1) a multipoint-to- 254 point tree of potential paths. Each tree consists of the set of 255 paths from all Boundary Nodes located in domain(i) to the 256 destination where each path satisfies the set of required 257 constraints for the TE LSP (bandwidth, affinities, etc.). 259 So a PCE needs to select Boundary Nodes (that is, ASBRs) that 260 provide connectivity from the upstream AS. In order that the tree of 261 paths provided by one PCE to its neighbor can be correlated, the 262 identities of the ASBRs for each path need to be referenced, so the 263 PCE must know the identities of the ASBRs in the remote AS reached 264 by any inter-AS TE link, and, in order that it provides only 265 suitable paths in the tree, the PCE must know the TE properties of 266 the inter-AS TE links. See the following figure as an example: 268 PCE1<------>PCE2<-------->PCE3 269 / : : 270 / : : 271 R1------R3----R5-----R7------R9-----R11 272 | | \ | / | 273 | | \ | ---- | 274 | | \ | / | 275 R2------R4----R6 --R8------R10----R12 276 : : 277 <-- AS1 -->:<---- AS2 --->:<--- AS3 ---> 279 Figure 2: BRPC for Inter-AS Reference Model 281 The figure shows three ASes (AS1, AS2, and AS3), three PCEs (PCE1, 282 PCE2, and PCE3), and twelve LSRs (R1 through R12). R3 and R4 are 283 ASBRs in AS1. R5, R6, R7, and R8 are ASBRs in AS2. R9 and R10 are 284 ASBRs in AS3. PCE1, PCE2, and PCE3 cooperate to perform inter-AS 285 path computation and are responsible for path segment computation 286 within their own domain(s). 288 If an inter-AS TE LSP is planned to be established from R1 to R12, 289 the traversed domains are assumed to be selected: AS1->AS2->AS3, and 290 the PCE chain is: PCE1->PCE2->PCE3. First, the path computation 291 request originated from the PCC (R1) is relayed by PCE1 and PCE2 292 along the PCE chain to PCE3, then PCE3 begins to compute the path 293 segments from the entry boundary nodes that provide connection from 294 AS2 to the destination (R12). But, to provide suitable path segments, 295 PCE3 must determine which entry boundary nodes provide connectivity 296 to its upstream neighbor AS (identified by its AS number), and must 297 know the TE properties of the inter-AS TE links. In the same way, 298 PCE2 also needs to determine the entry boundary nodes according to 299 its upstream neighbor AS and the inter-AS TE link capabilities. 301 Thus, to support Backward Recursive Path Computation the same 302 information listed in Section 2.2 is required. The AS number of the 303 neighboring AS connected to by each inter-AS TE link is particularly 304 important. 306 3. Extensions to ISIS-TE 308 Note that this document does not define mechanisms for distribution 309 of TE information from one AS to another, does not distribute any 310 form of TE reachability information for destinations outside the AS, 311 does not change the PCE architecture or usage, does not suggest or 312 recommend any form of TE aggregation, and does not feed private 313 information between ASes. See Section 2.1. 315 In this document, for the advertisement of inter-AS TE links, a new 316 TLV, which is referred to as the Inter-AS Reachability TLV, is 317 defined and three new sub-TLVs are defined for inclusion in the 318 Inter-AS Reachability TLV to carry the information about the 319 neighboring AS number and the remote ASBR ID of an inter-AS link. 320 The sub-TLVs defined in [ISIS-TE], [ISIS-TE-V3] and other documents 321 for inclusion in the Extended IS Reachability TLV are applicable to 322 be included in the Inter-AS Reachability TLV for inter-AS TE links 323 advertisement. And another two new sub-TLVs are defined for 324 inclusion in the IS-IS Router Capability TLV to carry the TE Router 325 ID when the TE Router ID is needed to reach all routers within an 326 entire ISIS routing domain. 328 While some of the TE information of an inter-AS TE link may be 329 available within the AS from other protocols, in order to avoid any 330 dependency on where such protocols are processed, this mechanism 331 carries all the information needed for the required TE operations. 333 3.1. Inter-AS Reachability TLV 335 The Inter-AS Reachability TLV has type 141 (which needs to be 336 confirmed by IANA see Section 6.1), it contains a data structure 337 consisting of: 339 4 octets of Router ID 340 3 octets of default metric 341 1 octet of control information, consisting of: 342 1 bit of flooding-scope information (S bit) 343 1 bit of up/down information (D bit) 344 6 bits reserved 345 1 octet of length of sub-TLVs 346 0-246 octets of sub-TLVs 347 where each sub-TLV consists of a sequence of: 348 1 octet of sub-type 349 1 octet of length of the value field of the sub-TLV 350 0-244 octets of value 352 Compare to the Extended Reachability TLV which is defined in [ISIS- 353 TE], the Inter-AS Reachability TLV replaces the "7 octets of System 354 ID and Pseudonode Number" field with a "4 octets of Router ID" field 355 and introduces an extra "control information" field which is 356 consisted of a flooding-scope bit (S bit), a up/down bit (D bit) and 357 6 reserved bits. 359 The Router ID field of the Inter-AS Reachability TLV is four octets 360 in length, which contains the Router ID of the router who generates 361 the Inter-AS Reachability TLV. The Router ID MUST be unique within 362 the ISIS area. If the router generates Inter-AS Reachability TLV 363 with entire ISIS routing domain flooding scope, then the Router ID 364 MUST also be unique within the entire ISIS routing domain. The 365 Router ID could be used to indicate the source of the Inter-AS 366 Reachability TLV. 368 The flooding procedures for Inter-AS Reachability TLV are identical 369 to the flooding procedures for the GNINFO TLV which are defined in 370 the Section 4 of [GENINFO]. These procedures have been previously 371 discussed in [ISIS-CAP]. The flooding-scope bit (S bit) SHOULD be 372 set to 0 if the flooding scope is to be limited to within the single 373 IGP area to which the ASBR belongs, or MAY be set to 1 if the 374 information is intended to reach all routers (including area border 375 routers, ASBRs, and PCEs) in the entire ISIS routing domain. The 376 choice between the use of 0 or 1 is an AS-wide policy choice, and 377 configuration control SHOULD be provided in ASBR implementations 378 that supports the advertisement of inter-AS TE links. 380 The sub-TLVs which are defined in [ISIS-TE], [ISIS-TE-V3] and other 381 documents for describing the TE properties of an TE link are also 382 applicable to be carried in the Inter-AS Reachability TLV to 383 describe the TE properties of an Inter-AS TE link. Apart from these 384 sub-TLVs, three new sub-TLVs are defined for inclusion in the Inter- 385 AS Reachability TLV in this document: 387 Sub-TLV type Length Name 388 ------------ ------ --------------------------- 389 23 4 Remote AS number 390 24 4 IPv4 Remote ASBR Identifier 391 25 16 IPv6 Remote ASBR Identifier 393 The detailed definitions of the three new sub-TLVs are described in 394 Section 3.3. 396 3.2. TE Router ID 398 The IPv4 TE Router ID TLV (type 134) and IPv6 TE Router ID TLV (type 399 140), which are defined in [ISIS-TE] and [ISIS-TE-V3] respectively, 400 only have area flooding-scope, when performing inter-AS TE, the TE 401 Router ID MAY be needed to reach all routers within an entire ISIS 402 routing domain, and it MUST have the same flooding scope as the 403 Inter-AS Reachability TLV does. 405 [ISIS-CAP] defines a generic advertisement mechanism for ISIS which 406 allows a router to advertise its capabilities within an ISIS area or 407 an entire ISIS routing domain. And [ISIS-CAP] also points out that 408 TE Router ID is candidate to be carried in the IS-IS Router 409 Capability TLV when performing inter-area TE. 411 This document uses such mechanism for TE Router ID advertisement 412 when the TE Router ID is needed to reach all routers within an 413 entire ISIS Routing domain. Two new sub-TLVs are defined for 414 inclusion in the IS-IS Router Capability TLV to carry the IPv4 and 415 IPv6 TE Router ID respectively: 417 Sub-TLV type Length Name 418 ------------ ------ ----------------- 419 11 4 IPv4 TE Router ID 420 12 16 IPv6 TE Router ID 422 The Detailed definitions of the two new sub-TLVs are described in 423 Section 3.3. 425 3.3. Sub-TLV Detail 427 3.3.1. Remote AS Number Sub-TLV 429 A new sub-TLV, the Remote AS Number sub-TLV is defined for inclusion 430 in the Inter-AS Reachability TLV when advertising inter-AS links. 431 The Remote AS Number sub-TLV specifies the AS number of the 432 neighboring AS to which the advertised link connects. 434 The Remote AS number sub-TLV is TLV type 23 (which needs to be 435 confirmed by IANA see Section 6.2), and is four octets in length. 436 The format is as follows: 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Type | Length | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Remote AS Number | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 The Remote AS number field has 4 octets. When only two octets are 447 used for the AS number, as in current deployments, the left (high- 448 order) two octets MUST be set to zero. The Remote AS Number Sub-TLV 449 MUST be included when a router advertises an inter-AS TE link. 451 3.3.2. IPv4 Remote ASBR ID Sub-TLV 453 A new sub-TLV, which is referred to as the IPv4 Remote ASBR ID sub- 454 TLV, is defined for inclusion in the Inter-AS Reachability TLV when 455 advertising inter-AS links. The IPv4 Remote ASBR ID sub-TLV 456 specifies the IPv4 identifier of the remote ASBR to which the 457 advertised inter-AS link connects. This could be any stable and 458 routable IPv4 address of the remote ASBR. Use of the TE Router ID as 459 specified in the Traffic Engineering Router ID TLV [ISIS-TE] is 460 RECOMMENDED. 462 The IPv4 Remote ASBR ID sub-TLV is TLV type 24 (which needs to be 463 confirmed by IANA see Section 6.2), and is four octets in length. 464 The format of the IPv4 Remote ASBR ID sub-TLV is as follows: 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Type | Length | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Remote ASBR ID | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 The IPv4 Remote ASBR ID sub-TLV MUST be included if the neighboring 475 ASBR has an IPv4 address. If the neighboring ASBR does not have an 476 IPv4 address (not even an IPv4 TE Router ID), the IPv6 Remote ASBR 477 ID sub-TLV MUST be included instead. An IPv4 Remote ASBR ID sub-TLV 478 and IPv6 Remote ASBR ID sub-TLV MAY both be present in an Extended 479 IS Reachability TLV. 481 3.3.3. IPv6 Remote ASBR ID Sub-TLV 483 A new sub-TLV, which is referred to as the IPv6 Remote ASBR ID sub- 484 TLV, is defined for inclusion in the Inter-AS Reachability TLV when 485 advertising inter-AS links. The IPv6 Remote ASBR ID sub-TLV 486 specifies the IPv6 identifier of the remote ASBR to which the 487 advertised inter-AS link connects. This could be any stable and 488 routable IPv6 address of the remote ASBR. Use of the TE Router ID as 489 specified in the IPv6 Traffic Engineering Router ID TLV [ISIS-TE-V3] 490 is RECOMMENDED. 492 The IPv6 Remote ASBR ID sub-TLV is TLV type 25 (which needs to be 493 confirmed by IANA see Section 6.2), and is sixteen octets in length. 494 The format of the IPv6 Remote ASBR ID sub-TLV is as follows: 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Type | Length | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Remote ASBR ID | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Remote ASBR ID (continued) | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Remote ASBR ID (continued) | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Remote ASBR ID (continued) | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 The IPv6 Remote ASBR ID sub-TLV MUST be included if the neighboring 511 ASBR has an IPv6 address. If the neighboring ASBR does not have an 512 IPv6 address, the IPv4 Remote ASBR ID sub-TLV MUST be included 513 instead. An IPv4 Remote ASBR ID sub-TLV and IPv6 Remote ASBR ID sub- 514 TLV MAY both be present in an Extended IS Reachability TLV. 516 3.3.4. IPv4 TE Router ID sub-TLV 518 The IPv4 TE Router ID sub-TLV is TLV type 11 (which needs to be 519 confirmed by IANA see Section 6.3), and is four octets in length. 520 The format of the IPv4 TE Router ID sub-TLV is as follows: 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Type | Length | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | TE Router ID | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 When the TE Router ID is needed to reach all routers within an 531 entire ISIS routing domain, the IS-IS Router Capability TLV MUST be 532 included in its LSP. And if an ASBR supports Traffic Engineering for 533 IPv4, the IPv4 TE Router ID sub-TLV MUST be included if the ASBR has 534 an IPv4 TE Router ID. If the ASBR does not have an IPv4 TE Router ID, 535 the IPv6 TE Router sub-TLV MUST be included instead. An IPv4 TE 536 Router ID sub-TLV and IPv6 TE Router ID sub-TLV MAY both be present 537 in an IS-IS Router Capability TLV. 539 3.3.5. IPv6 TE Router ID sub-TLV 541 The IPv6 TE Router ID sub-TLV is TLV type 12 (which needs to be 542 confirmed by IANA see Section 6.3), and is four octets in length. 543 The format of the IPv6 TE Router ID sub-TLV is as follows: 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Type | Length | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | TE Router ID | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | TE Router ID (continued) | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | TE Router ID (continued) | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | TE Router ID (continued) | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 When the TE Router ID is needed to reach all routers within an 560 entire ISIS routing domain, the IS-IS Router Capability TLV MUST be 561 included in its LSP. And if an ASBR supports Traffic Engineering for 562 IPv6, the IPv6 TE Router ID sub-TLV MUST be included if the ASBR has 563 an IPv6 TE Router ID. If the ASBR does not have an IPv6 TE Router ID, 564 the IPv4 TE Router sub-TLV MUST be included instead. An IPv4 TE 565 Router ID sub-TLV and IPv6 TE Router ID sub-TLV MAY both be present 566 in an IS-IS Router Capability TLV. 568 4. Procedure for Inter-AS TE Links 570 When TE is enabled on an inter-AS link and the link is up, the ASBR 571 SHOULD advertise this link using the normal procedures for ISIS-TE 572 [ISIS-TE]. When either the link is down or TE is disabled on the 573 link, the ASBR SHOULD withdraw the advertisement. When there are 574 changes to the TE parameters for the link (for example, when the 575 available bandwidth changes) the ASBR SHOULD re-advertise the link, 576 but the ASBR MUST take precautions against excessive re- 577 advertisements. 579 Hellos MUST NOT be exchanged over the inter-AS link, and 580 consequently, an ISIS adjacency MUST NOT be formed. 582 The information advertised comes from the ASBR's knowledge of the TE 583 capabilities of the link, the ASBR's knowledge of the current status 584 and usage of the link, and configuration at the ASBR of the remote 585 AS number and remote ASBR TE Router ID. 587 Legacy routers receiving an advertisement for an inter-AS TE link 588 are able to ignore it because they do not know the new TLV and sub- 589 TLVs that are defined in Section 3 in this document. They will 590 continue to flood the LSP, but will not attempt to use the 591 information received. 593 In the current operation of ISIS TE the LSRs at each end of a TE 594 link emit LSAs describing the link. The databases in the LSRs then 595 have two entries (one locally generated, the other from the peer) 596 that describe the different 'directions' of the link. This enables 597 CSPF to do a two-way check on the link when performing path 598 computation and eliminate it from consideration unless both 599 directions of the link satisfy the required constraints. 601 In the case we are considering here (i.e., of a TE link to another 602 AS) there is, by definition, no IGP peering and hence no bi- 603 directional TE link information. In order for the CSPF route 604 computation entity to include the link as a candidate path, we have 605 to find a way to get LSAs describing its (bidirectional) TE 606 properties into the TE database. 608 This is achieved by the ASBR advertising, internally to its AS, 609 information about both directions of the TE link to the next AS. The 610 ASBR will normally generate a LSA describing its own side of a link; 611 here we have it 'proxy' for the ASBR at the edge of the other AS and 612 generate an additional LSA that describes that devices 'view' of the 613 link. 615 Only some essential TE information for the link needs to be 616 advertised; i.e., the Interface Address, the Remote AS number and 617 the Remote ASBR ID of an inter-AS TE link. 619 Routers or PCEs that are capable of processing advertisements of 620 inter-AS TE links SHOULD NOT use such links to compute paths that 621 exit an AS to a remote ASBR and then immediately re-enter the AS 622 through another TE link. Such paths would constitute extremely rare 623 occurrences and SHOULD NOT be allowed except as the result of 624 specific policy configurations at the router or PCE computing the 625 path. 627 4.1. Origin of Proxied TE Information 629 Section 4 describes how to an ASBR advertises TE link information as 630 a proxy for its neighbor ASBR, but does not describe where this 631 information comes from. 633 Although the source of this information is outside the scope of this 634 document, it is possible that it will be a configuration requirement 635 at the ASBR, as are other, local, properties of the TE link. Further, 636 where BGP is used to exchange IP routing information between the 637 ASBRs, a certain amount of additional local configuration about the 638 link and the remote ASBR is likely to be available. 640 We note further that it is possible, and may be operationally 641 advantageous, to obtain some of the required configuration 642 information from BGP. Whether and how to utilize these possibilities 643 is an implementation matter. 645 5. Security Considerations 647 The protocol extensions defined in this document are relatively 648 minor and can be secured within the AS in which they are used by the 649 existing ISIS security mechanisms. 651 There is no exchange of information between ASes, and no change to 652 the ISIS security relationship between the ASes. In particular, 653 since no ISIS adjacency is formed on the inter-AS links, there is no 654 requirement for ISIS security between the ASes. 656 Some of the information included in these new advertisements (e.g., 657 the remote AS number and the remote ASBR ID) is obtained manually 658 from a neighboring administration as part of commercial relationship. 659 The source and content of this information should be carefully 660 checked before it is entered as configuration information at the 661 ASBR responsible for advertising the inter-AS TE links. 663 It is worth noting that in the scenario we are considering a Border 664 Gateway Protocol (BGP) peering may exist between the two ASBRs and 665 this could be used to detect inconsistencies in configuration (e.g., 666 the administration that originally supplied the information may be 667 lying, or some manual mis-configurations or mistakes are made by the 668 operators). For example, if a different remote AS number is received 669 in a BGP OPEN [BGP] from that locally configured into ISIS-TE, as we 670 describe here, then local policy SHOULD be applied to determine 671 whether to alert the operator to a potential mis-configuration or to 672 suppress the ISIS advertisement of the inter-AS TE link. Note, 673 further, that if BGP is used to exchange TE information as described 674 in Section 4.1, the inter-AS BGP session SHOULD be secured using 675 mechanisms as described in [BGP] to provide authentication and 676 integrity checks. 678 6. IANA Considerations 680 IANA is requested to make the following allocations from registries 681 under its control. 683 6.1. Inter-AS Reachability TLV 685 This document defines the following new ISIS TLV type, described in 686 Section 3.4, that needs to be registered in the ISIS TLV code-point 687 registry: 689 Type Description IIH LSP SNP 690 ---- ---------------------- --- --- --- 691 141 Inter-AS reachability n y n 692 information 694 6.2. Sub-TLVs for the Inter-AS Reachability TLV 696 This document defines the following new sub-TLV types, described in 697 Sections 3.3.1, 3.3.2 and 3.3.3, of top-level TLV 141 (see section 698 6.1 above) that need to be registered in the ISIS sub-TLV registry 699 for TLV 141, note that these three new sub-TLVs SHOULD NOT appear in 700 TLV 22 (or TLV 222) and MUST be ignored in TLV 22 (or TLV 222): 702 Type Description Length 703 ---- ------------------------------ -------- 704 23 Remote AS number 4 705 24 IPv4 Remote ASBR Identifier 4 706 25 IPv6 Remote ASBR Identifier 16 708 As described above in Section 3.1, the sub-TLVs which are defined in 709 [ISIS-TE], [ISIS-TE-V3] and other documents for describing the TE 710 properties of an TE link are applicable to describe an inter-AS TE 711 link and MAY be included in the Inter-AS Reachability TLV when 712 adverting inter-AS TE links. So, these sub-TLVs need to be 713 registered in the ISIS sub-TLV registry for TLV 141. And in order to 714 simplify the registration, we suggest using the same registry value 715 as they are registered in the ISIS sub-TLV registry for TLV 22. 717 Type Description 718 ---- ------------------------------ 719 3 Administrative group (color) [ISIS-TE] 720 4 Link Local/Remote Identifiers [GMPLS-TE] 721 6 IPv4 interface address [ISIS-TE] 722 9 Maximum link bandwidth [ISIS-TE] 723 10 Reservable link bandwidth [ISIS-TE] 724 11 Unreserved bandwidth [ISIS-TE] 725 12 IPv6 Interface Address [ISIS-TE-V3] 726 18 TE Default metric [ISIS-TE] 727 19 Link-attributes [RFC5029] 728 20 Link Protection Type [GMPLS-TE] 729 21 Interface Switching Capability Descriptor [GMPLS-TE] 730 22 Bandwidth Constraints [RFC4124] 732 Because sub-TLVs defined for TLV 22 can be advertised in the Inter- 733 AS Reachability TLV, the new sub-TLVs defined in this document 734 SHOULD NOT conflict with existing and/or future sub-TLV definitions 735 for TLV 22. Therefore the new sub-TLVs MUST be defined from a sub- 736 TLV registry which is shared by these two TLVs. 738 6.3. Sub-TLVs for the IS-IS Router Capability TLV 740 This document defines the following new sub-TLV types, described in 741 Sections 3.3.4 and 3.3.5, of top-level TLV 242 (which is defined in 742 [ISIS-CAP]) that need to be registered in the ISIS sub-TLV registry 743 for TLV 242: 745 Type Description Length 746 ---- ------------------------------ -------- 747 11 IPv4 TE Router ID 4 748 12 IPv6 TE Router ID 16 750 7. Acknowledgments 752 The authors would like to thank Adrian Farrel, Jean-Louis Le Roux, 753 Christian Hopps, and Les Ginsberg for their review and comments on 754 this document. 756 8. References 758 8.1. Normative References 760 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 761 Requirement Levels", BCP 14, RFC 2119, March 1997. 763 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 764 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 765 Tunnels", RFC 3209, December 2001. 767 [ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 768 dual environments", RFC 1195, December 1990. 770 [ISIS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising 771 router information", RFC 4971, July 2007. 773 8.2. Informative References 775 [INTER-AS-TE-REQ] Zhang and Vasseur, "MPLS Inter-AS Traffic 776 Engineering Requirements", RFC4216, November 2005. 778 [PD-PATH] Ayyangar, A., Vasseur, JP., and Zhang, R., "A Per-domain 779 path computation method for establishing Inter-domain", 780 RFC 5152, February 2008. 782 [BRPC] JP. Vasseur, Ed., R. Zhang, N. Bitar, JL. Le Roux, "A 783 Backward Recursive PCE-based Computation (BRPC) procedure 784 to compute shortest inter-domain Traffic Engineering Label 785 Switched Paths", draft-ietf-pce-brpc, (work in progress) 787 [PCE] Farrel, A., Vasseur, JP., and Ash, J., "A Path Computation 788 Element (PCE)-Based Architecture", RFC4655, August 2006. 790 [ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate 791 System (IS-IS) Extensions for Traffic Engineering (TE)", 792 RFC 3784, June 2004. 794 [ISIS-TE-V3] Harrison, J., Berger, J., and Bartlett, M., "IPv6 795 Traffic Engineering in IS-IS", draft-ietf-isis-ipv6-te, 796 {work in progress}. 798 [GMPLS-TE] K.Kompella and Y.Rekhter, "IS-IS Extensions in Support of 799 Generalized Multi-Protocol Label Switching", RFC 4205, 800 October 2005. 802 [BGP] Rekhter, Li, Hares, "A Border Gateway Protocol 4 (BGP-4)", 803 RFC4271, January 2006. 805 [RFC5029] Vasseur, JP., and Previdi, S., "Definition of an IS-IS 806 Link Attribute Sub-TLV", RFC5029, September 2007. 808 [RFC4124] Le Faucheur, F. "Protocol Extensions for Support of 809 Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 810 2005. 812 [GENINFO] L. Ginsberg., S. Previdi., and M. Shand., "Advertising 813 Generic Information in IS-IS", draft-ietf-isis-genapp, 814 (work in progress). 816 Authors' Addresses 818 Mach(Guoyi) Chen 819 Huawei Technologies Co.,Ltd 820 KuiKe Building, No.9 Xinxi Rd., 821 Hai-Dian District 822 Beijing, 100085 823 P.R. China 825 Email: mach@huawei.com 827 Renhai Zhang 828 Huawei Technologies Co.,Ltd 829 KuiKe Building, No.9 Xinxi Rd., 830 Hai-Dian District 831 Beijing, 100085 832 P.R. China 834 Email: zhangrenhai@huawei.com 836 Xiaodong Duan 837 China Mobile 838 53A,Xibianmennei Ave,Xunwu District 839 Beijing, China 841 Email: duanxiaodong@chinamobile.com 843 Intellectual Property Statement 845 The IETF takes no position regarding the validity or scope of any 846 Intellectual Property Rights or other rights that might be claimed 847 to pertain to the implementation or use of the technology described 848 in this document or the extent to which any license under such 849 rights might or might not be available; nor does it represent that 850 it has made any independent effort to identify any such rights. 851 Information on the procedures with respect to rights in RFC 852 documents can be found in BCP 78 and BCP 79. 854 Copies of IPR disclosures made to the IETF Secretariat and any 855 assurances of licenses to be made available, or the result of an 856 attempt made to obtain a general license or permission for the use 857 of such proprietary rights by implementers or users of this 858 specification can be obtained from the IETF on-line IPR repository 859 at http://www.ietf.org/ipr. 861 The IETF invites any interested party to bring to its attention any 862 copyrights, patents or patent applications, or other proprietary 863 rights that may cover technology that may be required to implement 864 this standard. Please address the information to the IETF at 865 ietf-ipr@ietf.org. 867 Disclaimer of Validity 869 This document and the information contained herein are provided on 870 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 871 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 872 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 873 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 874 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 875 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 876 FOR A PARTICULAR PURPOSE. 878 Copyright Statement 880 Copyright (C) The IETF Trust (2008). 882 This document is subject to the rights, licenses and restrictions 883 contained in BCP 78, and except as set forth therein, the authors 884 retain all their rights.