Network Working Group W. Lu Internet-Draft A. Tian Intended status: Standards Track Ericsson Expires: September 6, 2012 March 5, 2012 ISIS Transaction TLV draft-lu-isis-transaction-tlv-00 Abstract ISIS local updates may require multiple LSPs to convey. Receiving routers, whose decision processes are without such knowledge, may generate incorrect routing table updates based on the partial set of LSPs it receives and hence the traffic outage before they are corrected by another run of the decision process. This memo describes a method that makes the decision process more informed so that the interim results can be minimized or avoided. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 6, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Lu & Tian Expires September 6, 2012 [Page 1] Internet-Draft ISIS Transaction TLV March 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Implicit Purging . . . . . . . . . . . . . . . . . . . . . 3 1.4. PDU Transaction Knowledge . . . . . . . . . . . . . . . . 4 2. Transaction TLV . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. LSP Transaction Set . . . . . . . . . . . . . . . . . . . 5 2.2. TLV Format . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. T-TLV Count . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Transaction ID . . . . . . . . . . . . . . . . . . . . . . 6 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Originator . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Receiver . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Opening the Transaction . . . . . . . . . . . . . . . 7 3.2.2. Invalid Transaction . . . . . . . . . . . . . . . . . 8 3.2.3. Processing T-TLV . . . . . . . . . . . . . . . . . . . 8 3.2.4. Closing the Transaction . . . . . . . . . . . . . . . 8 3.2.5. Aborting the Transaction . . . . . . . . . . . . . . . 9 3.2.6. Exit Transaction . . . . . . . . . . . . . . . . . . . 9 3.2.7. Timer Expiry . . . . . . . . . . . . . . . . . . . . . 9 3.2.8. TID Wrap . . . . . . . . . . . . . . . . . . . . . . . 9 4. Multiple Transaction Sets . . . . . . . . . . . . . . . . . . 9 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Avoid Unwanted Purging . . . . . . . . . . . . . . . . . . 10 5.2. Allow reordering of TLVs in GR case . . . . . . . . . . . 10 5.3. Help Precise SPF Scheduling . . . . . . . . . . . . . . . 10 5.4. Other than SPFs . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Lu & Tian Expires September 6, 2012 [Page 2] Internet-Draft ISIS Transaction TLV March 2012 1. Introduction Link state protocols run on the knowledge of the entire topology. Incomplete topology information, even temporary, can result in traffic outage or routing loop. While transitional routing changes are inevitable and common to both OSPF [RFC2328] and ISIS [RFC1195][ISO.10589.1992], impacts to unchanged network connectivity are unnecessary and should be minimized if not totally avoidable. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2. Acronyms IS-IS - Intermediate System to Intermediate System OSPF - Open Shortest Path First TLV - Type Length Value PDU - Protocol Data Unit LSP - Link State PDU SPF - Shortest Path First 1.3. Implicit Purging Compared to OSPF, these impacts are unique to ISIS. There are two reasons. One is that ISIS LSPs use implicit TLV purging. Although LSPs do have age field which can be used for purging purpose, ISIS does not have the age granularity down to TLV level which is the atomic unit of ISIS link state information. If for some reason a TLV needs to be relocated to a different LSP fragment (e.g. TLV-B in Figure 1 and Figure 2), this TLV can be perceived as being purged from the original LSP fragment. And if the receiving ISIS starts its decision process before it sees the second LSP fragment, the reachability via this TLV, if any, will be lost. Lu & Tian Expires September 6, 2012 [Page 3] Internet-Draft ISIS Transaction TLV March 2012 LSP-Foo.00-00 LSP-Foo.00-01 -------------------------------- ------------------------------- | ............ | TLV-A | TLV-B | | ........... | TLV-X | ----- | -------------------------------- ------------------------------- Figure 1: Frag 00 Almost Full LSP-Foo.00-00 LSP-Foo.00-01 -------------------------------- ------------------------------- | ............ | TLV-A | - | | ........... | TLV-X | TLV-B | -------------------------------- ------------------------------- Figure 2: TLV-A grow out TLV-B The second reason is that operating directly on data link layer, ISIS cannot extend the LSP size beyond the MTU limit as opposed to OSPF which can leverage the IP fragmentation capability to extend its LSU size. The consequence is that when an LSP fragment is full or nearly full, if some of its TLVs need to expand, they will have to be relocated to other LSP fragment. Alternatively some other TLVs can be moved out of this LSP fragment to make room for the needy. Either way an implicit purge condition is created. 1.4. PDU Transaction Knowledge The above issues can be mitigated if the receiving routers are provided with LSP transaction information. In other words, if the receivers know how many LSPs they should expect from a particular originating Intermediate System, so that they acquire complete topology updates from that System, the receivers should be able to avoid running their decision process based on the incomplete transitional link state information. There can be many ways to accomplish the purpose. However to be practical the solution should meet following requirements: 1. It must be backward compatible. Adding a new TLV can easily fulfill this; 2. The TLV should be simple and short, that it does not take significant LSP space; 3. The solution should be fallback-able. That is, in case of errors or mistakes, it can fallback to the operation state without such solution; Lu & Tian Expires September 6, 2012 [Page 4] Internet-Draft ISIS Transaction TLV March 2012 4. It can be implemented easily without adding much burden on the originator and its update process. In particular it should not delay or change the timing of LSP flooding; 5. On the receiver side, the new logic should be simple and can be easily integrated to the existing logic, such as SPF scheduler. Performance wise, the new addition should be negligible. This document describes a transaction knowledge based TLV that can be used by the receiving routers to make informed decision. 2. Transaction TLV A new TLV is introduced to indicate that the carrying LSP needs additional LSPs to complement. For example, in Figure 2 LSPs "00" and "01" both have to be included in the SPF to reflect the correct change. If the receiver kicks off its SPF right after receiving LSP "00" and before seeing LSP "01", the reachability pertaining to TLV-B will be incorrectly removed, cause temporary traffic loss. The TLV is called Transaction TLV as it provides the transaction knowledge of the changes in which a set of LSPs are involved. 2.1. LSP Transaction Set LSPs which are coherent in contents are called LSP Transaction Set. These LSPs must be processed atomically by the receiver's decision process to avoid incorrect result. In Figure 2, LSPs "00" and "01" form the LSP transaction set. The LSP transaction set is a subset of all LSPs originated by an IS. In other words, the transaction set belongs to a single IS, and shares the same LSP ID which is the System ID plus the pseudo node ID. 2.2. TLV Format Figure 3 describes the Transaction TLV data fields: Lu & Tian Expires September 6, 2012 [Page 5] Internet-Draft ISIS Transaction TLV March 2012 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Len | TID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Count | +-+-+-+-+-+-+-+-+ Figure 3: Transaction TLV Format Type 1 byte, value TBD (T-TLV); Len 1 byte, 4 or 5; TID 4 bytes, Transaction ID; Count 1 byte, optional. The TLV can appear at most once in an LSP (fragment). Each LSP in an LSP transaction set is encoded with the same TLV except the last LSP which MUST include the "count" in this TLV to tell the total number LSPs in this transaction set. 2.3. T-TLV Count The count field is of 1 byte size, same as the size for LSP number field. The first "count-1" LSPs use the shorter T-TLV which has length 4. The last LSP use the longer T-TLV which contains the count field which counts in itself. This design is to make the originator easy to encode the TLV without having to know the count beforehand. 2.4. Transaction ID Along the time, an IS may generate and flood a number of LSP transaction sets. To differentiate one set from another, a monotonically increased Transaction ID (TID) is used. Each IS maintains and manages its TID. If an IS is also a DIS in one or more of its interfaces, each pseudo node has its own TID which is independent of the TID of the non-pseudo node, or other pseudo node. In case of TID conflict (due to race condition in flooding, or errors), the higher TID invalidates the lower TID. When a TID reaches the maximum, the TID wrap mechanism is used, which is detailed in Section 3.2.8. Lu & Tian Expires September 6, 2012 [Page 6] Internet-Draft ISIS Transaction TLV March 2012 3. Operation 3.1. Originator When an IS decides that its update process will have to use multiple LSPs to convey some information atomically, it labels these LSPs with the T-TLV and follows the procedures below: 1. The T-TLV should be used for SPF-sensitive changes only; 2. It starts a new TID number which is per LSP ID based. How to choose the initial TID number is a local decision though the natural choice would be 1. The number MUST be incremented from the existing one, and monotonically increased ever since; 3. T-TLV is recommended to be added to the end of an LSP. The TID is stored in the LSP set space (containing all LSP fragments), as opposed to the individual LSP space; 4. Repeat step 3 until there is no more to pack, at which time a T-TLV with count field is inserted to this last LSP in the transaction set. 3.2. Receiver Per ISIS protocol nature, if the receiver does not understand and support the T-TLV, the TLV is silently ignored. This ensures the backward compatibility. Otherwise the receiving IS enters into the transaction procedure. An IS will not engage its decision process into such procedure for T-TLVs whose carrying LSPs are already installed in the database. In other words, the procedure is activated only upon the receiving of the T-TLVs whose carrying LSPs are new. 3.2.1. Opening the Transaction When a T-TLV is received, the receiving IS enters the LSP transaction procedure. Type The TID is recorded to indicate that the current TID is active; Len A protection timer is started to prevent the error case where the transaction cannot close in time; Lu & Tian Expires September 6, 2012 [Page 7] Internet-Draft ISIS Transaction TLV March 2012 TID LSPs in a transaction set may not arrive in the order they are sent. Whichever arrives the first opens the transaction; Count The transaction record (TID/count/status) is maintained under the LSP set space (SystemID + PseudoNodeID). 3.2.2. Invalid Transaction The transaction is invalid, and MUST be aborted (exit) if: Type TID is outdated. This occurs if a higher TID is found, or the same TID is closed in the past transaction; Len more than one T-TLV is found in an LSP; TID more than one T-TLV with count field is found in an LSP transaction set; 3.2.3. Processing T-TLV When a T-TLV is received, following rules apply: Type Open the transaction if not yet, also increment the corresponding local count. If the received TLV contains the count, note down the announced count. Len If the local count equals the announced count, close the transaction. 3.2.4. Closing the Transaction If the received T-TLV causes the local count to match the announced count: Type Change the current transaction TID from active to closed; Len Cancel the protection timer; Lu & Tian Expires September 6, 2012 [Page 8] Internet-Draft ISIS Transaction TLV March 2012 Len Exit the transaction. Note that any T-TLV can close the transaction as long as it causes the match of counters. Implementation should not assume that the T-TLV with count field comes the last. 3.2.5. Aborting the Transaction Any error condition can abort the current transaction. The handling procedure is the same as the one in Section 3.2.4. 3.2.6. Exit Transaction A transaction can be terminated normally (closing) or abnormally due to error conditions. Closing and aborting the transaction are technically the same operation. The difference is that closing the transaction fulfills the purpose of T-TLVs for avoiding unnecessary packet loss. Either way after the transaction is terminated, the decision process MUST no longer block its SPF and should start the computation immediately or follow whatever SPF scheduling mandates. 3.2.7. Timer Expiry The expiry of the protection timer indicates that some transaction error has occurred. The receiving IS MUST abort the transaction. The length of the timer is a local decision. 3.2.8. TID Wrap When a TID reaches the maximum (0xFFFFFFFF), the originating IS will have to refrain from using T-TLV for LSP maximum age (21 minutes usually). The logic is similar to that of LSP sequence number wrapping. 4. Multiple Transaction Sets The count field is of 1 byte size, same as the size for LSP number field. The first "count-1" LSPs use the shorter T-TLV which has length 4. The last LSP use the longer T-TLV which contains the count field which counts in itself. This design is to make the originator easy to encode the TLV without having to know the count beforehand. Lu & Tian Expires September 6, 2012 [Page 9] Internet-Draft ISIS Transaction TLV March 2012 5. Use Cases The count field is of 1 byte size, same as the size for LSP number field. The first "count-1" LSPs use the shorter T-TLV which has length 4. The last LSP use the longer T-TLV which contains the count field which counts in itself. This design is to make the originator easy to encode the TLV without having to know the count beforehand. 5.1. Avoid Unwanted Purging The unwanted purging described in Section 1.3 can be avoided using T-TLVs. The originator can add T-TLV to LSP-Foo.00-00 and T-TLV (count=2) to LSP-Foo.00-01. The receivers will withhold the SPF till both LSPs are received. The missing TLV-B in the first LSP as shown in Figure 2 will not be treated as an implicit purging, as it will be found in the second LSP. 5.2. Allow reordering of TLVs in GR case If an IS advertises lots of redistributed routes in its LSPs, it is not trivial to maintain its TLV (like TLV 135) orders. This is especially true when an IS has just gone through the graceful restart process. Because the RIB does not necessary supply the redistributed routes the same order in the Pre-Restart time, reconstruct LSPs will result in LSPs with TLVs reordered. And if the number of redistributed routes is high, they spread over multiple LSPs. When the set of LSPs reaches other ISes, the same issue of 5.1 can arise, even if there is no change to redistributed routes at all. It is not impossible for the originating IS to use sophisticated means to keep those TLVs in their original order. Nevertheless this issue can easily be addressed with the T-TLVs. The restarting IS can add T-TLVs to all LSPs that are subject to TLV reordering, and transmit them upon exit of its graceful restart process. Thus the receiving ISes will not mistakenly purge some IS external reachability prefixes. 5.3. Help Precise SPF Scheduling As a link state protocol, ISIS has to two conflict goals. One is to be fast responsive to the network changes. The other is the network stability. If the SPF is scheduled too swiftly, the system (and even the Lu & Tian Expires September 6, 2012 [Page 10] Internet-Draft ISIS Transaction TLV March 2012 network) can melt down for some storm activities. On the other hand if there is lot of delays, the network becomes too slow adapting changes. For example, if an IS receives a burst of redistributed routes from BGP, it may send out dozens of LSPs for advertising all those routes. The receiving ISes, upon received first several LSPs, usually start the decision process to compute the new routing table. The routing table is incomplete and will be soon overwritten by another SPF run. If the number of routes (and hence LSPs) is high, most such SPF runs will be useless and wasteful. Only the last SPF will contribute to the final and correct routing table. The T-TLV if used will provide guidance to the receiving ISes to run SPF only when all LSPs are in place. This SPF is equivalent to the final SPF mentioned above. Therefore it saves a lot of SPF runs and network churns. What is more is that the T-TLV driven SPF can be kick started immediately, compared to the final SPF which usually has some amount of delay. 5.4. Other than SPFs The T-TLV may also be used for some non-SPF related operation. For example, the receiving ISes may choose to defer its TE database uploading process until all LSPs that carry the TE information are received. 6. Security Considerations This proposal does not introduce additional issues on security condition. 7. IANA Considerations A new ISIS T-TLV is introduced. The type is TBD by IANA. 8. Acknowledgements TBD 9. References Lu & Tian Expires September 6, 2012 [Page 11] Internet-Draft ISIS Transaction TLV March 2012 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [ISO.10589.1992] International Organization for Standardization, "Intermediate system to intermediate system intra-domain- routing routine information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO Standard 10589, 1992. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. Authors' Addresses Wenhu Lu Ericsson 300 Holger Way San Jose, California 95134 USA Email: Wenhu.Lu@ericsson.com Albert Tian Ericsson 300 Holger Way San Jose, California 95134 USA Email: Albert.Tian@ericsson.com Lu & Tian Expires September 6, 2012 [Page 12]