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]
