idnits 2.17.1 draft-ietf-isis-udl-00.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 (September 10, 2013) is 3874 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) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 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: March 14, 2014 A. Roy 6 Cisco Systems 7 September 10, 2013 9 IS-IS Support for Unidirectional Links 10 draft-ietf-isis-udl-00.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 March 14, 2014. 46 Copyright Notice 48 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Encoding Extensions . . . . . . . . . . . . . . . . . . . . . 4 77 2.1. UDL LSPs and the UDL-TLV . . . . . . . . . . . . . . . . . 4 78 2.2. UDL Intermediate System Neighbors sub-TLV . . . . . . . . 5 79 2.2.1. UDL Point-to-Point Intermediate System Neighbor 80 Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . 5 81 2.2.2. UDL LAN Intermediate System Neighbor Sub-TLV . . . . . 6 82 2.3. UDL LSP Range sub-TLV . . . . . . . . . . . . . . . . . . 7 83 2.4. UDL LSP Entry sub-TLV . . . . . . . . . . . . . . . . . . 7 84 2.5. UDL Manual Area Addresses sub-TLV . . . . . . . . . . . . 8 85 3. Adjacency Establishment . . . . . . . . . . . . . . . . . . . 9 86 3.1. Adjacency Establishment in Point-to-Point Mode . . . . . . 9 87 3.2. Adjacency Establishment in Broadcast Mode . . . . . . . . 10 88 3.3. UDL link metric configuration . . . . . . . . . . . . . . 10 89 4. Adjacency Maintenance . . . . . . . . . . . . . . . . . . . . 11 90 4.1. Adjacency Maintenance by IS-T . . . . . . . . . . . . . . 11 91 4.2. Adjacency Maintenance by IS-R . . . . . . . . . . . . . . 12 92 4.3. Use of BFD . . . . . . . . . . . . . . . . . . . . . . . . 12 93 5. Operation of the Update Process on a UDL . . . . . . . . . . . 13 94 6. Support for UDL on the Return Path . . . . . . . . . . . . . . 14 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 97 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 100 10.2. Informational References . . . . . . . . . . . . . . . . . 16 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 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 127 IS-IS PDUs normally on the link, the IS at the receive end of a UDL 128 link (IS-R) requires assistance from other ISs in the network to pass 129 the 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.3. UDL LSP Range sub-TLV 238 The content of this sub-TLV describes a range of LSPs for which the 239 originating router requires an update. A UDL Intermediate System 240 Neighbor sub-TLV MUST be included in any UDL-TLV where the UDL LSP 241 Range sub-TLV is included. This is necessary so that only the 242 specified neighbor processes the LSP range mentioned in the sub-TLV. 244 No. of octets 245 +---------------------------+ 246 | Type (8) | 1 247 | (To be assigned by IANA) | 248 +---------------------------+ 249 | Length (ID Length + 2)* 2 | 1 250 +---------------------------+ 251 | Start LSP ID | ID Length + 2 252 +---------------------------+ 253 | End LSP ID | ID Length + 2 254 +---------------------------+ 256 2.4. UDL LSP Entry sub-TLV 258 The content of this sub-TLV describes LSPs for which the originating 259 router requires an update. A UDL Intermediate System Neighbor sub- 260 TLV MUST be included in any UDL-TLV where the UDL LSP Entry sub-TLV 261 is included. This is necessary so that only the specified neighbor 262 processes the LSP entries mentioned in the sub-TLV. 264 No. of octets 265 +---------------------------+ 266 | Type (9) | 1 267 | (To be assigned by IANA) | 268 +---------------------------+ 269 | Length (10 + ID Length)*N | 1 270 +---------------------------+ 271 : LSP Entries : 272 +---------------------------+ 274 Each LSP Entry has the following format: 276 +---------------------------+ 277 | Remaining Lifetime | 2 278 +---------------------------+ 279 | LSP ID | ID Length + 2 280 +---------------------------+ 281 | LSP Sequence Number | 4 282 +---------------------------+ 283 | Checksum | 2 284 +---------------------------+ 286 2.5. UDL Manual Area Addresses sub-TLV 288 This sub-TLV specifies the set of manualAreaAddresses of the 289 originating system. No other sub-TLVs are allowed in a UDL-TLV which 290 has this sub-TLV. Any other sub-TLVs in such a UDL-TLV are ignored 291 on receipt. 293 No. of octets 294 +---------------------------+ 295 | Type (1) | 1 296 | (To be assigned by IANA) | 297 +---------------------------+ 298 | Length | 1 299 +---------------------------+ 300 : Area Address(es) : 301 +---------------------------+ 303 Each Area Address has the following format: 305 +---------------------------+ 306 | Address Length | 1 307 +---------------------------+ 308 | Area Address | Address Length 309 +---------------------------+ 311 3. Adjacency Establishment 313 An adjacency over a UDL link may be established over a link operating 314 in Point-to-Point mode (including a LAN subnetwork configured to 315 operate in Point-to-Point mode) or a link operating in broadcast 316 mode. Operation in either mode is identical except for some 317 differences in the manner of adjacency establishment as specified in 318 the following sub-sections. 320 IS-T utilizes the set of manualAreaAddresses advertised by IS-R in a 321 UDL Manual Area Address sub-TLV in combination with the UDL 322 Intermediate System Neighbor sub-TLV(s) to IS-T advertised by IS-R to 323 determine the level(s) associated with any adjacency to IS-R. 325 3.1. Adjacency Establishment in Point-to-Point Mode 327 Adjacency establishment makes use of Three Way Handshake as defined 328 in [RFC5303] when operating in Point-to-Point mode. When operating 329 over a LAN subnetwork, the use of point-to-point operation over LAN 330 as defined in [RFC5309] is also used. 332 IS-T initiates adjacency establishment by sending Point-to-Point IIHs 333 over the UDL as normal i.e., including Three-Way Handshake TLV. Note 334 that the local circuit ID specified by IS-T need only be unique among 335 the set of Point-to-Point UDL links supported by IS-T on which IS-T 336 is at the transmit end. 338 Upon receipt of a Point-to-Point IIH IS-R creates an adjacency in the 339 INIT state with IS-T and advertises the existence of the adjacency in 340 its UDL-LSP(s) utilizing the UDL Point-to-Point Intermediate System 341 Neighbor sub-TLV. The Local LAN address is included if the link is a 342 LAN subnetwork operating in Point-to-Point mode. UDL-LSPs of the 343 appropriate level(s) are generated according to the type of the 344 adjacency with IS-T. 346 When IS-T receives the UDL-LSP(s) generated by IS-R containing the 347 UDL Point-to-Point Intermediate System Neighbor sub-TLV it validates 348 the 3 way information and, if valid, transitions its adjacency to UP 349 state. In subsequent Point-to-Point IIHs IS-T includes IS-R's 350 circuit ID information as indicated in the UDL Point-to-Point IS 351 Neighbor sub-TLV in its 3 way handshake TLV. A complete set of CSNPs 352 is sent to IS-R for the level(s) appropriate for the type of 353 adjacency. LSPs which are updated as a result of the existence of 354 the adjacency to IS-R are sent to IS-R, but IS-T does NOT propagate 355 its full LSP Database. This is done to minimize the amount of 356 redundant flooding. 358 IS-R uses normal adjacency bring up rules based on the 3 way 359 handshake information it receives in Point-to-Point IIHs from IS-T 360 and advertises its IS neighbor to IS-T in the usual manner i.e. in an 361 LSP other than a UDL-LSP. Following transition of the adjacency to 362 IS-T to the UP state IS-R MAY request IS-T to flood its complete LSP 363 Database by sending an LSP Range sub-TLV to IS-T in a UDL-LSP. 365 3.2. Adjacency Establishment in Broadcast Mode 367 IS-T initiates adjacency establishment by sending LAN IIHs of the 368 appropriate level(s) over the UDL as normal. IS-T specifies itself 369 in the LAN ID field of the IIH, including a non-zero circuit ID. 370 Note that the local circuit ID specified by IS-T need only be unique 371 among the set of LAN UDL links supported by IS-T on which IS-T is at 372 the transmit end. This is because pseudo-node LSPs will never be 373 generated for a UDL. Operation in broadcast mode supports a UDL with 374 a single IS-T and multiple IS-Rs. 376 Upon receipt of a LAN IIH PDU IS-R creates an adjacency in the INIT 377 state with IS-T and advertises the existence of the adjacency in its 378 UDL-LSP(s) utilizing the UDL LAN Intermediate System Neighbor sub- 379 TLV. UDL-LSPs of the appropriate level(s) are generated according to 380 the levels supported by IS-R and IS-T. 382 When IS-T receives the UDL-LSP(s) generated by IS-R containing the 383 UDL LAN Intermediate System Neighbor sub-TLV(s) it validates the 384 LANID and, if valid, transitions its adjacency to UP state. In 385 subsequent LAN IIH PDUs, IS-T includes IS-R's LAN Address as 386 indicated in the UDL LAN IS Neighbor info. A complete set of CSNPs 387 for the appropriate level is sent over the circuit. LSPs which are 388 updated as a result of the existence of the adjacency to IS-R are 389 sent to IS-R, but IS-T does NOT propagate its full LSP Database. 390 This is done to minimize the amount of redundant flooding. 392 IS-R uses normal adjacency bring up rules based on the IS Neighbor 393 LAN Address information it receives in LAN IIH PDUs from IS-T and 394 advertises its IS neighbor to IS-T in an LSP other than a UDL-LSP. 395 Note that there is no pseudo-node on a UDL LAN circuit - therefore 396 both IS-T and IS-R MUST advertise an IS Neighbor TLV to each other, 397 not to a pseudo-node. This is identical to what is done on a Point- 398 to-Point subnetwork. Following transition of the adjacency to IS-T 399 to the UP state IS-R MAY request IS-T to flood its complete LSP 400 Database by sending an LSP Range sub-TLV to IS-T in a UDL-LSP. 402 3.3. UDL link metric configuration 404 What metrics are configured on a UDL depend upon the intended use of 405 the UDL. If the UDL is to be used for unicast forwarding, then IS-T 406 should be configured with the value appropriate to its intended 407 preference in the network topology and IS-R should be configured with 408 maximum link metric (2^24 -1) as defined in [RFC5305] (assuming wide 409 metrics are in use). If the UDL is to be used for building a 410 multicast Reverse Path Forwarding tree, then IS-R should be 411 configured with the value appropriate to its intended preference in 412 the network topology and IS-T should be configured with maximum link 413 metric (2^24 -1).If the link is to be used for both unicast 414 forwarding and multicast, then it is necessary to have two different 415 metric configurations and perform two different SPF calculations. 416 This may be achieved through the use of multi-topology extensions as 417 defined in [RFC5120]. Note that the configured link metrics have no 418 bearing on adjacency establishment - they only affect the building of 419 a Shortest Path Tree (SPT). 421 4. Adjacency Maintenance 423 This section defines how adjacencies are maintained once established. 424 Adjacency maintenance is defined without the need to send periodic 425 UDL-LSP updates as this would be a significant burden on the entire 426 network. 428 4.1. Adjacency Maintenance by IS-T 430 IS-T sends IIH PDUs as normal on a UDL. As IS-R does NOT send IIH 431 PDUs to IS-T, IS-T maintains the adjacency to IS-R so long as all of 432 the following conditions are TRUE: 434 o IS-T has a valid UDL-LSP from IS-R which includes Point-to-Point 435 UDL IS Neighbor information or LAN UDL IS Neighbor information (as 436 appropriate) regarding the adjacency IS-R has with IS-T on the 437 UDL. 439 o IS-T can calculate a return path rooted at IS-R to IS-T which does 440 not traverse the UDL on which the adjacency is associated 442 When either of the above conditions becomes FALSE, IS-T brings down 443 its adjacency to IS-R. Note that the return path calculation is only 444 required when a topology change occurs in the network. It therefore 445 need only be done in conjunction with a normal event driven SPF 446 calculation. 448 NOTE: Immediately after the adjacency to IS-R has come up, if the 449 only available return path traverses a UDL link on which the 450 adjacency is still in the process of coming UP, the return path check 451 will fail. This is possible because we bypass normal flooding rules 452 to allow the UDL-LSP to be flooded even when the adjacency is not UP 453 on a UDL link (as described later in this document). If IS-T 454 immediately brings the adjacency to IS-R down in this case, a 455 circular dependency condition arises. To avoid this, if the return 456 path check fails immediately after the adjacency comes up, a timer Tp 457 is started. The timer is cancelled when a return path check 458 succeeds. If the timer expires, IS-T brings down the adjacency to 459 IS-R. A recommended value for the timer Tp is a small multiple 460 (e.g., "twice") of the estimated time necessary to propagate LSPs 461 across the entire domain. 463 Although it is unorthodox to bring up an adjacency without confirmed 464 two way connectivity, the extension is well grounded because the 465 receipt of IS-R's UDL-LSP by IS-T is indicative of the existence of a 466 return path even though it cannot yet be confirmed by examination of 467 the LSP database. This unconfirmed two way connectivity is a 468 condition which we do not want to persist indefinitely - hence the 469 use of timer Tp. 471 4.2. Adjacency Maintenance by IS-R 473 IS-R maintains its adjacency with IS-T based on receipt of IIHs from 474 IS-T as normal. So long as IS-T follows the rules for adjacency 475 maintenance described in the previous section this is sufficient. 477 Further protection against pathological behavior on the part of IS-T 478 (e.g., failure to perform the return path calculation after a 479 topology change) MAY be implemented by IS-R. When IS-R receives a 480 CSNP from IS-T which contains an SNP entry identifying an LSP which 481 is not in IS-R's Link State Database (LSDB) a timer Tf is started for 482 each such LSP. This includes entries which are older than, newer 483 than, or non-existent in IS-R's LSDB.The timer Tf is cancelled if: 485 o The associated LSP is received by IS-R on any circuit by normal 486 operation of the Update process or 488 o A subsequent set of CSNPs received from IS-T does not include the 489 LSP entry 491 If any timer Tf expires IS-R brings down the adjacency with IS-T. 493 In the absence of pathological behavior by IS-T the Tf extension is 494 not required. Its use is therefore optional. 496 4.3. Use of BFD 498 A multi-hop BFD session [RFC5883] MAY be established between IS-T and 499 IS-R. This can be used to provide fast failure detection. If used, 500 this would also make the calculation by IS-T of a return path from 501 IS-R to IS-T optional. 503 5. Operation of the Update Process on a UDL 505 For purposes of LSP propagation IS-T views the UDL as if it were a 506 broadcast subnetwork where IS-T is the Designated Intermediate System 507 (DIS). This is true regardless of the mode of operation of the 508 circuit (point-to-point or broadcast). Therefore, IS-T propagates 509 new LSPs on the UDL as they arrive but after sending an LSP on the 510 UDL the SRM flag for that LSP is cleared i.e. no acknowledgement for 511 the LSP is required or expected. IS-T also sends periodic CSNPs on 512 the UDL. 514 IS-R cannot propagate LSPs to IS-T on the UDL. IS-R also cannot 515 acknowledge LSPs received from IS-T on the UDL. In this respect IS-R 516 operates on the UDL in a manner identical to a non-DIS on a broadcast 517 circuit. If an LSP entry in a CSNP received from IS-T identifies an 518 LSP which is "newer than" an LSP in IS-R's LSDB, IS-R MAY request the 519 LSP from IS-T by sending a UDL-LSP with an LSP entry as described 520 above. Since IS-R's UDL-LSP(s) will be propagated throughout the 521 network even though the information is only of use to IS-Ts, it is 522 recommended that some small delay occur between the receipt of a CSNP 523 from IS-T and the generation of a UDL-LSP with an updated LSP entry 524 by IS-R so as to allow for the possible receipt of the LSP either 525 from IS-T or on another link. 527 If the number of LSP entries to be requested exceeds the space 528 available in the UDL TLV associated with the adjacency to IS-T, IS-R 529 MUST NOT generate multiple UDL TLVs associated with the same 530 adjacency. Instead it should maintain the state of SSN flags 531 appropriately for the LSP entries that require updates and send 532 additional LSP entries (if necessary) in a subsequent UDL-LSP after 533 the previously requested updates arrive. 535 Use of the LSP Range sub-TLV by IS-R allows more efficient encoding 536 of a request for multiple LSPs. This could be especially useful 537 following an adjacency UP event on a UDL. As described in Section 3, 538 IS-T does NOT propagate its full LSP database following transition of 539 an adjacency to IS-R to the UP state. This is consistent with IS-T 540 operating in the role of DIS on a broadcast circuit. If IS-R has 541 neighbors on other circuits it is possible that it will have received 542 LSPs from other neighbors. In such a case flooding of the full LSP 543 database by IS-T would be redundant. It is therefore left to the 544 discretion of IS-R to request those portions of the LSP database 545 which are not current. This is consistent with IS-R operating as a 546 non-DIS on a broadcast circuit. 548 On receipt of a UDL-LSP generated by IS-R, IS-T checks the neighbor 549 information in each UDL-TLV. If the information matches an existing 550 adjacency that IS-T has with IS-R then IS-T sets SRM flag on the UDL 551 for any LSPs in its LSDB which are "newer" than the corresponding 552 entries IS-R sent in LSP Entry sub-TLVs in UDL TLVs. SRM flags are 553 also set on the UDL for LSPs which fall in the ranges specified in 554 LSP Range sub-TLVs in UDL TLVs. UDL-TLVs associated with adjacencies 555 to routers other than IS-T are ignored by IS-T. 557 6. Support for UDL on the Return Path 559 If all return paths from IS-R to IS-T traverse a UDL, then in order 560 to bring up the adjacency between IS-T and IS-R at least one of the 561 adjacencies on a return path UDL must already be UP. This is 562 required because IS-T relies on receiving the UDL-LSP(s) generated by 563 IS-R in order to bring up its adjacency. In order to overcome a 564 circular dependency in the case where multiple pairs of UDL neighbors 565 are trying to bring up an adjacency at the same time, an extension to 566 LSP propagation rules is required. 568 When a new UDL-LSP is received by any IS which has one or more active 569 UDLs on which it is operating as an IS-T, the set of neighbors other 570 than the local system which are advertised in UDL-TLVs in the 571 received UDL-LSP is extracted - call this UDL-LSP-ISN-SET. A return 572 path from the originating IS-R to each neighbor in the UDL-LSP-ISN- 573 SET is calculated. If there is no return path to one or more 574 neighbors in this set periodic propagation of that UDL-LSP on all 575 UDLs on which the local system acts as IS-T is initiated regardless 576 of the state of an adjacency on that UDL. Periodic transmission of 577 that UDL-LSP continues until a return path to all neighbors in the 578 UDL-LSP-ISN-SET exists. This calculation is redone whenever the UDL- 579 LSP is updated and when a topology change in the network occurs as a 580 result of updates to the LSDB. Note that periodic retransmission is 581 only done on UDLs on which the local system acts as IS-T. 583 If the network is partitioned the lack of a return path from a given 584 IS-R to a given IS-T may persist. It is therefore recommended that 585 the periodic retransmission employ an exponential backoff timer such 586 that when the partition persists the periodic retransmission period 587 is long enough so as to not represent a significant burden. It is 588 recommended that the periodic retransmission be initially set to the 589 locally configured CSNP interval. Note that periodic retransmission 590 is only performed on UDL links and if an IS-R has previously received 591 the same UDL-LSP it will silently ignore the retransmission since the 592 UDL-LSP will already be in its LSDB. Unnecessary reflooding of the 593 retransmitted UDL-LSP beyond the UDL does not occur. 595 IS-R MUST accept and propagate UDL-LSPs received on a UDL even when 596 there is no adjacency in the UP state on the UDL circuit. Flooding 597 of UDL-LSPs by IS-R uses normal flooding rules. LSPs received by 598 IS-R on the UDL which do NOT include UDL TLVs are discarded unless 599 the adjacency is UP (normal processing). 601 This extension allows establishment of an adjacency on a UDL even 602 when the return path transits another UDL which is also in the 603 process of bringing up an adjacency. The periodic nature of the 604 flooding is meant to compensate for the unreliability of the 605 flooding. After the adjacency is UP, IS-R can request LSPs from IS-T 606 by putting LSP entries into UDL-LSPs - but that ability is not 607 available until the adjacency is UP. 609 7. IANA Considerations 611 This document requires the definition of a new IS-IS TLV to be 612 reflected in the "IS-IS TLV Codepoints" registry: 614 Type Description IIH LSP SNP Purge 615 ---- ------------ --- --- --- ----- 616 11 Unidirectional Link Information N Y N Y 618 This document requires that a new IANA registry be created to control 619 the assignment of sub-TLV code points to be advertised within a 620 Unidirectional Link Information TLV. The registration procedure is 621 "Expert Review" as defined in [RFC5226]. The following sub-TLVs are 622 defined by this document. Values are suggested values subject to 623 assignment by IANA. 624 Value Description 625 ----- ------------------------------ 626 1 Manual Area Addresses 627 6 LAN IS Neighbor 628 9 LSP Entry 629 240 Point-to-Point IS Neighbor 631 8. Security Considerations 633 Security concerns for IS-IS are addressed in [IS-IS], [RFC5304], and 634 [RFC5310]. 636 9. Acknowledgements 638 The idea of supporting IS-IS on UDLs without using tunnels or 639 encapsulation was originally introduced in the US patent "Support of 640 unidirectional link in IS-IS without IP encapsulation and in presence 641 of unidirectional return path" (patent number: 7,957,380), by Sina 642 Mirtorabi, Abhay Kumar Roy, Lester Ginsberg. 644 10. References 646 10.1. Normative References 648 [IS-IS] "Intermediate system to Intermediate system intra-domain 649 routeing information exchange protocol for use in 650 conjunction with the protocol for providing the 651 connectionless-mode Network Service (ISO 8473), ISO/IEC 652 10589:2002, Second Edition.", Nov 2002. 654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 655 Requirement Levels", BCP 14, RFC 2119, March 1997. 657 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 658 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 659 May 2008. 661 [RFC5303] Katz, D., Saluja, R., and D. Eastlake, "Three-Way 662 Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, 663 October 2008. 665 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 666 Engineering", RFC 5305, October 2008. 668 10.2. Informational References 670 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 671 Topology (MT) Routing in Intermediate System to 672 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 674 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 675 Authentication", RFC 5304, October 2008. 677 [RFC5309] Shen, N. and A. Zinin, "Point-to-Point Operation over LAN 678 in Link State Routing Protocols", RFC 5309, October 2008. 680 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 681 and M. Fanto, "IS-IS Generic Cryptographic 682 Authentication", RFC 5310, February 2009. 684 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 685 (BFD) for Multihop Paths", RFC 5883, June 2010. 687 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 688 Originator Identification TLV for IS-IS", RFC 6232, 689 May 2011. 691 Authors' Addresses 693 Les Ginsberg 694 Cisco Systems 695 510 McCarthy Blvd. 696 Milpitas, CA 95035 697 USA 699 Email: ginsberg@cisco.com 701 Sina Mirtorabi 702 Cisco Systems 703 3800 Zankar Road 704 San Jose, CA 95134 705 USA 707 Email: smirtora@cisco.com 709 Stefano Previdi 710 Cisco Systems 711 Via Del Serafico 200 712 Rome 0144 713 Italy 715 Email: sprevidi@cisco.com 717 Abhay Roy 718 Cisco Systems 719 560 McCarthy Blvd. 720 Milpitas, CA 95135 721 USA 723 Email: akr@cisco.com