idnits 2.17.1 draft-ietf-isis-udl-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 28, 2014) is 3589 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' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5306 (Obsoleted by RFC 8706) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group L. Ginsberg 3 Internet-Draft S. Mirtorabi 4 Intended status: Standards Track S. Previdi 5 Expires: December 30, 2014 A. Roy 6 Cisco Systems 7 June 28, 2014 9 IS-IS Support for Unidirectional Links 10 draft-ietf-isis-udl-02.txt 12 Abstract 14 This document defines support for the operation of IS-IS over 15 Unidirectional Links without the use of tunnels or encapsulation of 16 IS-IS Protocol Data Units. Adjacency establishment when the return 17 path from the router at the receive end of a unidirectional link to 18 the router at the transmit end of the unidirectional link is via 19 another unidirectional link is supported. The extensions defined 20 here are backwards compatible - only the routers directly connected 21 to a unidirectional link need to be upgraded. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on December 30, 2014. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Encoding Extensions . . . . . . . . . . . . . . . . . . . . 3 77 2.1. UDL LSPs and the UDL-TLV . . . . . . . . . . . . . . . . 4 78 2.2. UDL Intermediate System Neighbors sub-TLV . . . . . . . . 4 79 2.2.1. UDL Point-to-Point Intermediate System Neighbor Sub- 80 TLV . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 2.2.2. UDL LAN Intermediate System Neighbor Sub-TLV . . . . 5 82 2.2.3. Sub-TLVs Associated w an IS Neighbor . . . . . . . . 6 83 2.3. UDL Manual Area Addresses sub-TLV . . . . . . . . . . . . 9 84 3. Adjacency Establishment . . . . . . . . . . . . . . . . . . . 10 85 3.1. Adjacency Establishment in Point-to-Point Mode . . . . . 10 86 3.2. Adjacency Establishment in Broadcast Mode . . . . . . . . 11 87 3.3. UDL link metric configuration . . . . . . . . . . . . . . 12 88 4. Adjacency Maintenance . . . . . . . . . . . . . . . . . . . . 12 89 4.1. Adjacency Maintenance by IS-T . . . . . . . . . . . . . . 12 90 4.2. Adjacency Maintenance by IS-R . . . . . . . . . . . . . . 13 91 4.3. Use of BFD . . . . . . . . . . . . . . . . . . . . . . . 14 92 4.4. Graceful Restart Support . . . . . . . . . . . . . . . . 14 93 5. Operation of the Update Process on a UDL . . . . . . . . . . 14 94 6. Support for UDL on the Return Path . . . . . . . . . . . . . 15 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 97 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 99 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 100 10.2. Informational References . . . . . . . . . . . . . . . . 18 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 103 1. Introduction 105 Operation of IS-IS depends upon two-way connectivity. Adjacencies 106 are formed by exchanging hellos on a link, flooding of the link state 107 database is made reliable by exchanges between neighbors on a link, 108 etc. However, there are deployments where operation of the protocol 109 is desired over links which are unidirectional i.e., one end of the 110 link can only send Protocol Data Units (PDUs) and one end of the link 111 can only receive PDUs. Traditional methods of supporting 112 Unidirectional Links (UDLs) have involved establishing a tunnel from 113 the Intermediate System (IS) at the receive end of the UDL to the IS 114 at the transmit end of the UDL, encapsulating/decapsulating the IS-IS 115 PDUs as they enter/exit the tunnel, and associating the PDUs received 116 via the tunnel with the UDL at the transmit end. This typically 117 requires static configuration and may introduce Maximum Transmission 118 Unit (MTU) issues due to the required encapsulation. 120 This specification defines extensions to the protocol which support 121 correct and reliable operation of IS-IS over UDLs without the need 122 for tunnels or any form of encapsulation. 124 2. Encoding Extensions 126 Although the IS at the transmit end of a UDL link (IS-T) can send IS- 127 IS PDUs normally on the link, the IS at the receive end of a UDL link 128 (IS-R) requires assistance from other ISs in the network to pass the 129 information it would normally send directly to IS-T. The Update 130 Process as defined in [IS-IS] allows information generated by one IS 131 in the network to be reliably flooded to all other ISs in the network 132 using Link State PDUs (LSPs). The extensions defined here utilize 133 LSPs to allow IS-R to send information normally sent in hellos (IIHs) 134 or sequence number PDUs (SNPs) to IS-T in LSPs. As LSPs are flooded 135 to all ISs in an area/sub-domain, care is taken to minimize the LSP 136 churn necessary to support adjacency establishment and maintenance 137 between IS-T and IS-R. 139 2.1. UDL LSPs and the UDL-TLV 141 Routers on the receive end of a UDL MUST reserve at least one LSP 142 (for each level supported on the UDL) to advertise the UDL 143 information described below. Such LSPs are referred to as UDL-LSPs 144 although the only distinction between a UDL-LSP and other LSPs is in 145 the TLV information which is present in such an LSP. LSP #0 MUST NOT 146 be used to send UDL information. UDL-LSPs have the following special 147 characteristics: 149 1. The only TLV which may be advertised in UDL-LSPs is the UDL TLV 150 described below and (optionally) an Authentication TLV and/or 151 Purge Originator Identification TLV [RFC6232] . This requirement 152 is enforced by the originator of the UDL-LSP but is not checked 153 by receiving systems i.e., other TLVs which are included in a 154 UDL-LSP are processed normally. The reason for the restriction 155 is to minimize the number of LSPs which have UDL information 156 content. 158 2. Routers on the transmit side of a UDL flood UDL-LSPs regardless 159 of the existence of an adjacency in the UP state on that circuit. 160 Flooding of UDL-LSPs on circuits other than a UDL is as specified 161 in [IS-IS] i.e., no special handling. 163 A new TLV is defined in which UDL specific information appears. All 164 information in a UDL-TLV is encoded in sub-TLVs. UDL sub-TLVs are 165 formatted as specified in [RFC5305]. The format of the UDL-TLV is 166 therefore: 168 No. of octets 169 +---------------------------+ 170 | Type (11) | 1 171 | (To be assigned by IANA) | 172 +---------------------------+ 173 | Length | 1 174 +---------------------------+ 175 | Sub-TLVs | 3 - 255 176 : : 177 +---------------------------+ 179 2.2. UDL Intermediate System Neighbors sub-TLV 181 UDL links may operate in Point-to-Point mode or in broadcast mode 182 (assuming the subnetwork is a broadcast subnetwork). There are 183 therefore two types of Intermediate System Neighbors sub-TLVs 184 defined. A UDL-TLV MUST NOT contain more than one Intermediate 185 System Neighbors sub-TLV. If multiple Intermediate System Neighbors 186 sub-TLVs appear in a UDL-TLV all information in that UDL-TLV MUST be 187 ignored. 189 2.2.1. UDL Point-to-Point Intermediate System Neighbor Sub-TLV 191 The UDL Point-to-Point Intermediate System Neighbor Sub-TLV describes 192 an adjacency on a UDL which is operating in Point-to-Point mode i.e. 193 either a Point-to-Point subnetwork or a LAN subnetwork operating in 194 Point-to-Point mode as described in [RFC5309]. The information 195 encoded follows the format for the Point-to-Point Three-Way Adjacency 196 TLV as defined in [RFC5303] but may also include the local LAN 197 address when the underlying subnetwork is a LAN. 199 No. of octets 200 +---------------------------+ 201 | Type (240) | 1 202 | (To be assigned by IANA) | 203 +---------------------------+ 204 | Length (9 + ID Length) | 1 205 | to (15 + ID Length) | 206 +---------------------------+ 207 | Adjacency 3-way state | 1 208 +---------------------------+ 209 | Extended Local Circuit ID | 4 210 +---------------------------+ 211 | Neighbor System ID | ID Length 212 +---------------------------+ 213 | Neighbor Extended Local | 4 214 | Circuit ID | 215 +---------------------------+ 216 | Local LAN Address | 6 217 +---------------------------+ 219 2.2.2. UDL LAN Intermediate System Neighbor Sub-TLV 221 The UDL LAN Intermediate System Neighbor sub-TLV describes an 222 adjacency on a UDL operating in broadcast mode on a LAN subnetwork. 224 No. of octets 225 +---------------------------+ 226 | Type (6) | 1 227 | (To be assigned by IANA) | 228 +---------------------------+ 229 | Length (7 + ID Length) | 1 230 +---------------------------+ 231 | Neighbor LAN ID | ID Length + 1 232 +---------------------------+ 233 | Local LAN Address | 6 234 +---------------------------+ 236 2.2.3. Sub-TLVs Associated w an IS Neighbor 238 A number of sub-TLVs require the presence of a UDL IS-Neighbor sub- 239 TLV (either Point-to-Point or LAN) in the UDL-TLV in order to provide 240 appropiate context for the information being advertised. These sub- 241 TLVs are described in the sub-sections below. 243 2.2.3.1. UDL LSP Range sub-TLV 245 The content of this sub-TLV describes a range of LSPs for which the 246 originating router requires an update. Only the neighbor specified 247 in the associated UDL IS-Neighbor sub-TLV processes the LSP range 248 mentioned in this sub-TLV. 250 No. of octets 251 +---------------------------+ 252 | Type (8) | 1 253 | (To be assigned by IANA) | 254 +---------------------------+ 255 | Length (ID Length + 2)* 2 | 1 256 +---------------------------+ 257 | Start LSP ID | ID Length + 2 258 +---------------------------+ 259 | End LSP ID | ID Length + 2 260 +---------------------------+ 262 2.2.3.2. UDL LSP Entry sub-TLV 264 The content of this sub-TLV describes LSPs for which the originating 265 router requires an update. Only the neighbor specified in the 266 associated UDL IS-Neighbor sub-TLV processes the LSP entries 267 specified in this sub-TLV. 269 No. of octets 270 +---------------------------+ 271 | Type (9) | 1 272 | (To be assigned by IANA) | 273 +---------------------------+ 274 | Length (10 + ID Length)*N | 1 275 +---------------------------+ 276 : LSP Entries : 277 +---------------------------+ 279 Each LSP Entry has the following format: 281 +---------------------------+ 282 | Remaining Lifetime | 2 283 +---------------------------+ 284 | LSP ID | ID Length + 2 285 +---------------------------+ 286 | LSP Sequence Number | 4 287 +---------------------------+ 288 | Checksum | 2 289 +---------------------------+ 291 2.2.3.3. Protocols Supported sub-TLV 293 This sub-TLV specifies the set of Network Layer Protocol Identifiers 294 (NLPIDs) that the originating system is capable of forwarding as 295 defined in [RFC1195]. 297 No. of octets 298 +---------------------------+ 299 | Type (129) | 1 300 | (To be assigned by IANA) | 301 +---------------------------+ 302 | Length | Number of NLPIDs 303 +---------------------------+ 304 : NLPIDs : 1 octet/NLPID 305 +---------------------------+ 307 2.2.3.4. IP Address sub-TLV 309 This sub-TLV specifies the set of IP addresses configured on the 310 interface as defined in [RFC1195]. 312 No. of octets 313 +---------------------------+ 314 | Type (132) | 1 315 | (To be assigned by IANA) | 316 +---------------------------+ 317 | Length | 4 * # of addresses 318 +---------------------------+ 319 : IP Address(es) : 4 octets/address 320 +---------------------------+ 322 2.2.3.5. Multi-Topology sub-TLV 324 This sub-TLV specifies the set of topology identifiers supported as 325 defined in [RFC5120]. 327 No. of octets 328 +---------------------------+ 329 | Type (229) | 1 330 | (To be assigned by IANA) | 331 +---------------------------+ 332 | Length | 2 * # of MTIDs 333 +---------------------------+ 334 : MTIDs : 2 octets/MTID 335 +---------------------------+ 337 NOTE: All flag bits defined in [RFC5120] MUST be transmitted as 0 338 and ignored on receipt. 340 2.2.3.6. IPv6 Interface Address sub-TLV 342 This sub-TLV specifies the set of IPv6 addresses assigned on the 343 local interface as defined in [RFC5308]. Addresses MUST be link 344 local addresses. 346 No. of octets 347 +---------------------------+ 348 | Type (232) | 1 349 | (To be assigned by IANA) | 350 +---------------------------+ 351 | Length | 16 * # of IPv6 addresses 352 +---------------------------+ 353 : IPv6 Addresses : 16 octets/Address 354 +---------------------------+ 356 2.2.3.7. IPv6 Global Interface Address sub-TLV 358 This sub-TLV specifies the set of global IPv6 addresses assigned on 359 the local interface as defined in [RFC6119]. . Addresses MUST be 360 global or unique local addresses. 362 No. of octets 363 +---------------------------+ 364 | Type (233) | 1 365 | (To be assigned by IANA) | 366 +---------------------------+ 367 | Length | 16 * # of IPv6 addresses 368 +---------------------------+ 369 : IPv6 Addresses : 16 octets/Address 370 +---------------------------+ 372 2.3. UDL Manual Area Addresses sub-TLV 374 This sub-TLV specifies the set of manualAreaAddresses of the 375 originating system. No other sub-TLVs are allowed in a UDL-TLV which 376 has this sub-TLV. Any other sub-TLVs in such a UDL-TLV are ignored 377 on receipt. 379 No. of octets 380 +---------------------------+ 381 | Type (1) | 1 382 | (To be assigned by IANA) | 383 +---------------------------+ 384 | Length | 1 385 +---------------------------+ 386 : Area Address(es) : 387 +---------------------------+ 389 Each Area Address has the following format: 391 +---------------------------+ 392 | Address Length | 1 393 +---------------------------+ 394 | Area Address | Address Length 395 +---------------------------+ 397 3. Adjacency Establishment 399 An adjacency over a UDL link may be established over a link operating 400 in Point-to-Point mode (including a LAN subnetwork configured to 401 operate in Point-to-Point mode) or a link operating in broadcast 402 mode. Operation in either mode is identical except for some 403 differences in the manner of adjacency establishment as specified in 404 the following sub-sections. 406 IS-T utilizes the set of manualAreaAddresses advertised by IS-R in a 407 UDL Manual Area Address sub-TLV in combination with the UDL 408 Intermediate System Neighbor sub-TLV(s) to IS-T advertised by IS-R to 409 determine the level(s) associated with any adjacency to IS-R. 411 3.1. Adjacency Establishment in Point-to-Point Mode 413 Adjacency establishment makes use of Three Way Handshake as defined 414 in [RFC5303] when operating in Point-to-Point mode. When operating 415 over a LAN subnetwork, the use of point-to-point operation over LAN 416 as defined in [RFC5309] is also used. 418 IS-T initiates adjacency establishment by sending Point-to-Point IIHs 419 over the UDL as normal i.e., including Three-Way Handshake TLV. Note 420 that the local circuit ID specified by IS-T need only be unique among 421 the set of Point-to-Point UDL links supported by IS-T on which IS-T 422 is at the transmit end. 424 Upon receipt of a Point-to-Point IIH IS-R creates an adjacency in the 425 INIT state with IS-T and advertises the existence of the adjacency in 426 its UDL-LSP(s) utilizing the UDL Point-to-Point Intermediate System 427 Neighbor sub-TLV. The Local LAN address is included if the link is a 428 LAN subnetwork operating in Point-to-Point mode. UDL-LSPs of the 429 appropriate level(s) are generated according to the type of the 430 adjacency with IS-T. 432 When IS-T receives the UDL-LSP(s) generated by IS-R containing the 433 UDL Point-to-Point Intermediate System Neighbor sub-TLV it validates 434 the 3 way information and, if valid, transitions its adjacency to UP 435 state. In subsequent Point-to-Point IIHs IS-T includes IS-R's 436 circuit ID information as indicated in the UDL Point-to-Point IS 437 Neighbor sub-TLV in its 3 way handshake TLV. A complete set of CSNPs 438 is sent to IS-R for the level(s) appropriate for the type of 439 adjacency. LSPs which are updated as a result of the existence of 440 the adjacency to IS-R are sent to IS-R, but IS-T does NOT propagate 441 its full LSP Database. This is done to minimize the amount of 442 redundant flooding. 444 IS-R uses normal adjacency bring up rules based on the 3 way 445 handshake information it receives in Point-to-Point IIHs from IS-T 446 and advertises its IS neighbor to IS-T in the usual manner i.e. in an 447 LSP other than a UDL-LSP. Following transition of the adjacency to 448 IS-T to the UP state IS-R MAY request IS-T to flood its complete LSP 449 Database by sending an LSP Range sub-TLV to IS-T in a UDL-LSP. 451 3.2. Adjacency Establishment in Broadcast Mode 453 IS-T initiates adjacency establishment by sending LAN IIHs of the 454 appropriate level(s) over the UDL as normal. IS-T specifies itself 455 in the LAN ID field of the IIH, including a non-zero circuit ID. 456 Note that the local circuit ID specified by IS-T need only be unique 457 among the set of LAN UDL links supported by IS-T on which IS-T is at 458 the transmit end. This is because pseudo-node LSPs will never be 459 generated for a UDL. Operation in broadcast mode supports a UDL with 460 a single IS-T and multiple IS-Rs. 462 Upon receipt of a LAN IIH PDU IS-R creates an adjacency in the INIT 463 state with IS-T and advertises the existence of the adjacency in its 464 UDL-LSP(s) utilizing the UDL LAN Intermediate System Neighbor sub- 465 TLV. UDL-LSPs of the appropriate level(s) are generated according to 466 the levels supported by IS-R and IS-T. 468 When IS-T receives the UDL-LSP(s) generated by IS-R containing the 469 UDL LAN Intermediate System Neighbor sub-TLV(s) it validates the 470 LANID and, if valid, transitions its adjacency to UP state. In 471 subsequent LAN IIH PDUs, IS-T includes IS-R's LAN Address as 472 indicated in the UDL LAN IS Neighbor info. A complete set of CSNPs 473 for the appropriate level is sent over the circuit. LSPs which are 474 updated as a result of the existence of the adjacency to IS-R are 475 sent to IS-R, but IS-T does NOT propagate its full LSP Database. 476 This is done to minimize the amount of redundant flooding. 478 IS-R uses normal adjacency bring up rules based on the IS Neighbor 479 LAN Address information it receives in LAN IIH PDUs from IS-T and 480 advertises its IS neighbor to IS-T in an LSP other than a UDL-LSP. 481 Note that there is no pseudo-node on a UDL LAN circuit - therefore 482 both IS-T and IS-R MUST advertise an IS Neighbor TLV to each other, 483 not to a pseudo-node. This is identical to what is done on a Point- 484 to-Point subnetwork. Following transition of the adjacency to IS-T 485 to the UP state IS-R MAY request IS-T to flood its complete LSP 486 Database by sending an LSP Range sub-TLV to IS-T in a UDL-LSP. 488 3.3. UDL link metric configuration 490 What metrics are configured on a UDL depend upon the intended use of 491 the UDL. If the UDL is to be used for unicast forwarding, then IS-T 492 should be configured with the value appropriate to its intended 493 preference in the network topology and IS-R should be configured with 494 maximum link metric (2^24 -1) as defined in [RFC5305] (assuming wide 495 metrics are in use). If the UDL is to be used for building a 496 multicast Reverse Path Forwarding tree, then IS-R should be 497 configured with the value appropriate to its intended preference in 498 the network topology and IS-T should be configured with maximum link 499 metric (2^24 -1).If the link is to be used for both unicast 500 forwarding and multicast, then it is necessary to have two different 501 metric configurations and perform two different SPF calculations. 502 This may be achieved through the use of multi-topology extensions as 503 defined in [RFC5120]. Note that the configured link metrics have no 504 bearing on adjacency establishment - they only affect the building of 505 a Shortest Path Tree (SPT). 507 4. Adjacency Maintenance 509 This section defines how adjacencies are maintained once established. 510 Adjacency maintenance is defined without the need to send periodic 511 UDL-LSP updates as this would be a significant burden on the entire 512 network. 514 4.1. Adjacency Maintenance by IS-T 516 IS-T sends IIH PDUs as normal on a UDL. As IS-R does NOT send IIH 517 PDUs to IS-T, IS-T maintains the adjacency to IS-R so long as all of 518 the following conditions are TRUE: 520 o IS-T has a valid UDL-LSP from IS-R which includes Point-to-Point 521 UDL IS Neighbor information or LAN UDL IS Neighbor information (as 522 appropriate) regarding the adjacency IS-R has with IS-T on the 523 UDL. 525 o IS-T can calculate a return path rooted at IS-R to IS-T which does 526 not traverse the UDL on which the adjacency is associated 528 When either of the above conditions becomes FALSE, IS-T brings down 529 its adjacency to IS-R. Note that the return path calculation is only 530 required when a topology change occurs in the network. It therefore 531 need only be done in conjunction with a normal event driven SPF 532 calculation. 534 NOTE: Immediately after the adjacency to IS-R has come up, if the 535 only available return path traverses a UDL link on which the 536 adjacency is still in the process of coming UP, the return path check 537 will fail. This is possible because we bypass normal flooding rules 538 to allow the UDL-LSP to be flooded even when the adjacency is not UP 539 on a UDL link (as described later in this document). If IS-T 540 immediately brings the adjacency to IS-R down in this case, a 541 circular dependency condition arises. To avoid this, if the return 542 path check fails immediately after the adjacency comes up, a timer Tp 543 is started. The timer is cancelled when a return path check 544 succeeds. If the timer expires, IS-T brings down the adjacency to 545 IS-R. A recommended value for the timer Tp is a small multiple 546 (e.g., "twice") of the estimated time necessary to propagate LSPs 547 across the entire domain. 549 Although it is unorthodox to bring up an adjacency without confirmed 550 two way connectivity, the extension is well grounded because the 551 receipt of IS-R's UDL-LSP by IS-T is indicative of the existence of a 552 return path even though it cannot yet be confirmed by examination of 553 the LSP database. This unconfirmed two way connectivity is a 554 condition which we do not want to persist indefinitely - hence the 555 use of timer Tp. 557 4.2. Adjacency Maintenance by IS-R 559 IS-R maintains its adjacency with IS-T based on receipt of IIHs from 560 IS-T as normal. So long as IS-T follows the rules for adjacency 561 maintenance described in the previous section this is sufficient. 563 Further protection against pathological behavior on the part of IS-T 564 (e.g., failure to perform the return path calculation after a 565 topology change) MAY be implemented by IS-R. When IS-R receives a 566 CSNP from IS-T which contains an SNP entry identifying an LSP which 567 is not in IS-R's Link State Database (LSDB) a timer Tf is started for 568 each such LSP. This includes entries which are older than, newer 569 than, or non-existent in IS-R's LSDB.The timer Tf is cancelled if: 571 o The associated LSP is received by IS-R on any circuit by normal 572 operation of the Update process or 574 o A subsequent set of CSNPs received from IS-T does not include the 575 LSP entry 577 If any timer Tf expires IS-R brings down the adjacency with IS-T. 579 In the absence of pathological behavior by IS-T the Tf extension is 580 not required. Its use is therefore optional. 582 4.3. Use of BFD 584 A multi-hop BFD session [RFC5883] MAY be established between IS-T and 585 IS-R. This can be used to provide fast failure detection. If used, 586 this would also make the calculation by IS-T of a return path from 587 IS-R to IS-T optional. 589 Support for [RFC6213] requires that the BFD session come up before 590 the IS-IS adjacency comes up when both neighbors advertise BFD 591 support. In the event that there is a UDL link on the return path 592 from IS-R to IS-T and the adjacency on that link is also in the 593 process of coming up this could introduce a circular dependency 594 between the state of the BFD sessions and the state of the UDL 595 adjacencies. Therefore [RFC6213] is NOT supported on UDLs. 597 4.4. Graceful Restart Support 599 Graceful restart as defined in [RFC5306] is NOT supported on UDLs. 601 In the event IS-R is restarting, signaling of restart state would 602 require IS-R to regenerate UDL-LSPs prior to synchronization of the 603 LSPDB. In the event IS-T is restarting, LSPDB synchronization would 604 require the sending of CSNPs from IS-R to IS-T - which is not 605 supported. 607 5. Operation of the Update Process on a UDL 609 For purposes of LSP propagation IS-T views the UDL as if it were a 610 broadcast subnetwork where IS-T is the Designated Intermediate System 611 (DIS). This is true regardless of the mode of operation of the 612 circuit (point-to-point or broadcast). Therefore, IS-T propagates 613 new LSPs on the UDL as they arrive but after sending an LSP on the 614 UDL the SRM flag for that LSP is cleared i.e. no acknowledgement for 615 the LSP is required or expected. IS-T also sends periodic CSNPs on 616 the UDL. 618 IS-R cannot propagate LSPs to IS-T on the UDL. IS-R also cannot 619 acknowledge LSPs received from IS-T on the UDL. In this respect IS-R 620 operates on the UDL in a manner identical to a non-DIS on a broadcast 621 circuit. If an LSP entry in a CSNP received from IS-T identifies an 622 LSP which is "newer than" an LSP in IS-R's LSDB, IS-R MAY request the 623 LSP from IS-T by sending a UDL-LSP with an LSP entry as described 624 above. Since IS-R's UDL-LSP(s) will be propagated throughout the 625 network even though the information is only of use to IS-Ts, it is 626 recommended that some small delay occur between the receipt of a CSNP 627 from IS-T and the generation of a UDL-LSP with an updated LSP entry 628 by IS-R so as to allow for the possible receipt of the LSP either 629 from IS-T or on another link. 631 If the number of LSP entries to be requested exceeds the space 632 available in the UDL TLV associated with the adjacency to IS-T, IS-R 633 MUST NOT generate multiple UDL TLVs associated with the same 634 adjacency. Instead it should maintain the state of SSN flags 635 appropriately for the LSP entries that require updates and send 636 additional LSP entries (if necessary) in a subsequent UDL-LSP after 637 the previously requested updates arrive. 639 Use of the LSP Range sub-TLV by IS-R allows more efficient encoding 640 of a request for multiple LSPs. This could be especially useful 641 following an adjacency UP event on a UDL. As described in Section 3, 642 IS-T does NOT propagate its full LSP database following transition of 643 an adjacency to IS-R to the UP state. This is consistent with IS-T 644 operating in the role of DIS on a broadcast circuit. If IS-R has 645 neighbors on other circuits it is possible that it will have received 646 LSPs from other neighbors. In such a case flooding of the full LSP 647 database by IS-T would be redundant. It is therefore left to the 648 discretion of IS-R to request those portions of the LSP database 649 which are not current. This is consistent with IS-R operating as a 650 non-DIS on a broadcast circuit. 652 On receipt of a UDL-LSP generated by IS-R, IS-T checks the neighbor 653 information in each UDL-TLV. If the information matches an existing 654 adjacency that IS-T has with IS-R then IS-T sets SRM flag on the UDL 655 for any LSPs in its LSDB which are "newer" than the corresponding 656 entries IS-R sent in LSP Entry sub-TLVs in UDL TLVs. SRM flags are 657 also set on the UDL for LSPs which fall in the ranges specified in 658 LSP Range sub-TLVs in UDL TLVs. UDL-TLVs associated with adjacencies 659 to routers other than IS-T are ignored by IS-T. 661 6. Support for UDL on the Return Path 663 If all return paths from IS-R to IS-T traverse a UDL, then in order 664 to bring up the adjacency between IS-T and IS-R at least one of the 665 adjacencies on a return path UDL must already be UP. This is 666 required because IS-T relies on receiving the UDL-LSP(s) generated by 667 IS-R in order to bring up its adjacency. In order to overcome a 668 circular dependency in the case where multiple pairs of UDL neighbors 669 are trying to bring up an adjacency at the same time, an extension to 670 LSP propagation rules is required. 672 When a new UDL-LSP is received by any IS which has one or more active 673 UDLs on which it is operating as an IS-T, the set of neighbors other 674 than the local system which are advertised in UDL-TLVs in the 675 received UDL-LSP is extracted - call this UDL-LSP-ISN-SET. A return 676 path from the originating IS-R to each neighbor in the UDL-LSP-ISN- 677 SET is calculated. If there is no return path to one or more 678 neighbors in this set periodic propagation of that UDL-LSP on all 679 UDLs on which the local system acts as IS-T is initiated regardless 680 of the state of an adjacency on that UDL. Periodic transmission of 681 that UDL-LSP continues until a return path to all neighbors in the 682 UDL-LSP-ISN-SET exists. This calculation is redone whenever the UDL- 683 LSP is updated and when a topology change in the network occurs as a 684 result of updates to the LSDB. Note that periodic retransmission is 685 only done on UDLs on which the local system acts as IS-T. 687 If the network is partitioned the lack of a return path from a given 688 IS-R to a given IS-T may persist. It is therefore recommended that 689 the periodic retransmission employ an exponential backoff timer such 690 that when the partition persists the periodic retransmission period 691 is long enough so as to not represent a significant burden. It is 692 recommended that the periodic retransmission be initially set to the 693 locally configured CSNP interval. Note that periodic retransmission 694 is only performed on UDL links and if an IS-R has previously received 695 the same UDL-LSP it will silently ignore the retransmission since the 696 UDL-LSP will already be in its LSDB. Unnecessary reflooding of the 697 retransmitted UDL-LSP beyond the UDL does not occur. 699 IS-R MUST accept and propagate UDL-LSPs received on a UDL even when 700 there is no adjacency in the UP state on the UDL circuit. Flooding 701 of UDL-LSPs by IS-R uses normal flooding rules. LSPs received by 702 IS-R on the UDL which do NOT include UDL TLVs are discarded unless 703 the adjacency is UP (normal processing). 705 This extension allows establishment of an adjacency on a UDL even 706 when the return path transits another UDL which is also in the 707 process of bringing up an adjacency. The periodic nature of the 708 flooding is meant to compensate for the unreliability of the 709 flooding. After the adjacency is UP, IS-R can request LSPs from IS-T 710 by putting LSP entries into UDL-LSPs - but that ability is not 711 available until the adjacency is UP. 713 7. IANA Considerations 715 This document requires the definition of a new IS-IS TLV to be 716 reflected in the "IS-IS TLV Codepoints" registry: 718 Type Description IIH LSP SNP Purge 719 ---- ------------ --- --- --- ----- 720 11 Unidirectional Link Information N Y N Y 722 This document requires that a new IANA registry be created to control 723 the assignment of sub-TLV code points to be advertised within a 724 Unidirectional Link Information TLV. The registration procedure is 725 "Expert Review" as defined in [RFC5226]. The following sub-TLVs are 726 defined by this document. Values are suggested values subject to 727 assignment by IANA. 729 Value Description 730 ----- ------------------------------ 731 1 Manual Area Addresses 732 6 LAN IS Neighbor 733 8 LSP Range 734 9 LSP Entry 735 129 Protocols Supported 736 132 IP Interface Address 737 229 Multi-topology 738 232 IPv6 Interface Address 739 233 IPv6 Global Interface Address 740 240 Point-to-Point IS Neighbor 742 8. Security Considerations 744 Security concerns for IS-IS are addressed in [IS-IS], [RFC5304], and 745 [RFC5310]. 747 9. Acknowledgements 749 The idea of supporting IS-IS on UDLs without using tunnels or 750 encapsulation was originally introduced in the US patent "Support of 751 unidirectional link in IS-IS without IP encapsulation and in presence 752 of unidirectional return path" (patent number: 7,957,380), by Sina 753 Mirtorabi, Abhay Kumar Roy, Lester Ginsberg. 755 10. References 757 10.1. Normative References 759 [IS-IS] "Intermediate system to Intermediate system intra-domain 760 routeing information exchange protocol for use in 761 conjunction with the protocol for providing the 762 connectionless-mode Network Service (ISO 8473), ISO/IEC 763 10589:2002, Second Edition.", Nov 2002. 765 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 766 dual environments", RFC 1195, December 1990. 768 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 769 Requirement Levels", BCP 14, RFC 2119, March 1997. 771 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 772 Topology (MT) Routing in Intermediate System to 773 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 775 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 776 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 777 May 2008. 779 [RFC5303] Katz, D., Saluja, R., and D. Eastlake, "Three-Way 780 Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, 781 October 2008. 783 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 784 Engineering", RFC 5305, October 2008. 786 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 787 2008. 789 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 790 Engineering in IS-IS", RFC 6119, February 2011. 792 10.2. Informational References 794 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 795 Authentication", RFC 5304, October 2008. 797 [RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", 798 RFC 5306, October 2008. 800 [RFC5309] Shen, N. and A. Zinin, "Point-to-Point Operation over LAN 801 in Link State Routing Protocols", RFC 5309, October 2008. 803 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 804 and M. Fanto, "IS-IS Generic Cryptographic 805 Authentication", RFC 5310, February 2009. 807 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 808 (BFD) for Multihop Paths", RFC 5883, June 2010. 810 [RFC6213] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC 811 6213, April 2011. 813 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 814 Originator Identification TLV for IS-IS", RFC 6232, May 815 2011. 817 Authors' Addresses 819 Les Ginsberg 820 Cisco Systems 821 510 McCarthy Blvd. 822 Milpitas, CA 95035 823 USA 825 Email: ginsberg@cisco.com 827 Sina Mirtorabi 828 Cisco Systems 829 3800 Zankar Road 830 San Jose, CA 95134 831 USA 833 Email: smirtora@cisco.com 835 Stefano Previdi 836 Cisco Systems 837 Via Del Serafico 200 838 Rome 0144 839 Italy 841 Email: sprevidi@cisco.com 843 Abhay Roy 844 Cisco Systems 845 560 McCarthy Blvd. 846 Milpitas, CA 95135 847 USA 849 Email: akr@cisco.com