Internet DRAFT - draft-aravind-isis-reason-tlv

draft-aravind-isis-reason-tlv



 



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]