Working Group Aravind Prasad Sridharan Internet-Draft DELL Intended Status: Standards Track November 17, 2014 Expires: May 21, 2015 IS-IS Reason TLV draft-aravind-isis-reason-tlv-00 Abstract This document defines a means of advertising the reasons for generation of new Link State Packet (LSP) Updates using Reason TLVs. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2014 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 Aravind Prasad Sridharan Expires May 21, 2015 [Page 1] Internet Draft IS-IS Reason TLV November 17, 2014 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1 Reduction in Processing overload at Receivers . . . . . . . 2 2.2 User Assistance . . . . . . . . . . . . . . . . . . . . . . 3 2.3 Delaying/Dampening the actions based on Reason TLVs . . . . 3 2.4 Easy Debugging . . . . . . . . . . . . . . . . . . . . . . 4 3 Reason TLV . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Backward Compatibility . . . . . . . . . . . . . . . . . . 4 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1 Normative References . . . . . . . . . . . . . . . . . . . 5 6.2 Informative References . . . . . . . . . . . . . . . . . . 5 7 Authors' Address . . . . . . . . . . . . . . . . . . . . . . . 6 1 Introduction Usually, during changes in topology or database info, a new LSP is generated by Intermediate Systems(IS) in ISIS. But currently, there are no mechanisms to showcase the reason for generation of new LSPs. The proposed Reason TLV could be viewed along the same lines as Dynamic Hostname TLVs [RFC5301]. These set of TLVs basically make the protocol more user-friendly and keeps its users well informed about the overall processing carried out by it. 1.1 Terminology 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]. 2 Use-cases 2.1 Reduction in Processing overload at Receivers Currently, the Receiving Router has to parse through the entire content of received LSPs and compare with the existing LSPs in its Database to identify the newly updated changes. But with the proposed Aravind Prasad Sridharan Expires May 21, 2015 [Page 2] Internet Draft IS-IS Reason TLV November 17, 2014 Reason TLVs, the receiver could get to know the exact set of TLVs that have been updated in received LSP and process only those set of TLVs. Hence, crucial decisions like running SPF calculations could be done more efficiently and with less processing overload. 2.2 User Assistance With reason TLVs, the root-causes that triggered the specific LSP update could be notified by the networking vendors to Users (possibly with debugs/logs). Hence, this could greatly help in overall understandability of current behavior of protocol and can also help to reassure whether the required results had been achieved. For E.g.: Consider an User configuring Overload bit in a Router. Under current scenarios, the user has to execute "show database command" at every Router in Domain (to view the LSP database) to reassure that the overload bit has been correctly sent out from originator and reflected properly in all other neighbor routers for the corresponding LSPs. But, if the User can view such info directly from LSP Update debugs at the originating and receiving ends, possible workloads could be avoided. The same applies to addition of new routes, change in protocol fields and so on. 2.3 Delaying/Dampening the actions based on Reason TLVs Depending upon the reasons that triggered the LSP Updates, the receivers can delay/postpone the corresponding actions thereby reducing unnecessary flooding/churns in network. For E.g.: The IP-Internal/External Reachability TLVs basically provides the IP reachability info in ISIS. Hence, any addition/removal of such TLVs reflect the reachability status for such IP routes. Generally, IP routes may become unreachable either due to link down states or Admin operations. In case of Link Down states, it could be possible for link to reach the UP state in a very short time. Hence, it may be useful if the receivers can delay the SPF runs to a small extent (providing a small time gap for the link to reach UP state again at originator). These decisions could be efficiently made using Reason TLVs. If the sender fills appropriate Reason Codes, the receiver can decipher such scenarios and provide a small cushion for the links in sender to reach UP state again. This can help greatly in avoiding unnecessary chaos in the Network due to sudden link flaps. Aravind Prasad Sridharan Expires May 21, 2015 [Page 3] Internet Draft IS-IS Reason TLV November 17, 2014 2.4 Easy Debugging In case of buggy scenarios, debugging could be efficiently carried out with the help of Reason TLVs. For E.g.: Consider a Router to be malfunctioning in an ISIS domain and starts generating LSPs unexpectedly. Under such scenarios, the Reason TLVs could provide the root-causes that trigger these unexpected LSP generations and could assist in problem analysis. 3 Reason TLV 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 | +-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason TLV Codes ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Reason TLV Type: TBD. Length: Total number of bytes contained in the value field. Value : TLVs that have undergone changes in LSP In addition to established TLV Codes (like Area Address, Protocols supported and so on), we could also introduce new TLV Codes for the attribute fields in LSP Header (Overload bit, Attached bit and Partition repair and so on). Also, we could use Sub TLV types since we may need to distinguish between set/clear bits (say for overload bits, attached bits). And there could be one/more Sub-TLVs in a single Reason TLV. 3.1 Backward Compatibility Since the info is provided via a new TLV, the Routers which may not recognize this TLV could ignore it thereby maintaining backward compatibility with legacy systems and help in easier deployment. Aravind Prasad Sridharan Expires May 21, 2015 [Page 4] Internet Draft IS-IS Reason TLV November 17, 2014 4 Security Considerations This document does not introduce any new security concerns to IS-IS or any other specifications referenced in this document. 5 IANA Considerations No IANA actions required. 6 References 6.1 Normative References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. [IS-IS] "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO 10589. [IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008. 6.2 Informative References [PFXATTR] "IS-IS Prefix Attributes, draft-ginsberg-isis-prefix- attributes-00(work in progress)", September 2014. [I-D.chunduri-isis-extended-sequence-no-tlv] Chunduri, U., Tian, A., and Shen, "IS-IS Extended Sequence number TLV", draft-chunduri-isis-extended- sequence-no-tlv-04 (work in progress), July 4, 2014. [RFC5301] McPherson, D., Shen, N., "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 5301, October 2008. Aravind Prasad Sridharan Expires May 21, 2015 [Page 5] Internet Draft IS-IS Reason TLV November 17, 2014 7 Authors' Address Aravind Prasad Sridharan DELL Olympia Technology Park Guindy, Chennai 600032 India Phone: +91 44 4220 8658 Email: aravind_sridharan@dell.com Aravind Prasad Sridharan Expires May 21, 2015 [Page 6]