IS-IS for IP Internets C. Hopps
Internet-Draft L. Ginsberg
Intended status: Standards Track Cisco Systems
Expires: September 24, 2008 March 23, 2008
IS-IS BFD Enabled TLV
draft-ietf-isis-bfd-tlv-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 24, 2008.
Abstract
This document describes a TLV for use in the IS-IS routing protocol
that allows for the proper use of the Bidirectional Forwarding
Detection protocol (BFD). There exist certain scenarios in which
IS-IS will not react appropriately to a BFD detected forwarding plane
failure without use of either this TLV or some other method.
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].
Hopps & Ginsberg Expires September 24, 2008 [Page 1]
Internet-Draft IS-IS BFD Enabled TLV March 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Solution . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. State Definitions . . . . . . . . . . . . . . . . . . . . . 4
3.2. Adjacency Establishment and Maintenance . . . . . . . . . . 4
3.3. Advertisement of Topology Specific IS Neighbors . . . . . . 5
4. Transition . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . 6
6. The BFD Enabled TLV . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Hopps & Ginsberg Expires September 24, 2008 [Page 2]
Internet-Draft IS-IS BFD Enabled TLV March 2008
1. Introduction
The Bidirectional Forwarding Detection protocol [I-D.ietf-bfd-base]
is a protocol that allows for detection of a forwarding plane failure
between two routers. A router can use [I-D.ietf-bfd-base] to
validate that a peer router's forwarding ability is functioning.
One specific application of BFD as described in
[I-D.ietf-bfd-generic] is to verify the forwarding ability of an
IS-IS [RFC1195] router's adjacencies; however, the method described
in [I-D.ietf-bfd-generic] does not allow for certain failure
scenarios. We will define a TLV that will allow for proper response
to the detection of all forwarding failures where the use of BFD is
employed with IS-IS.
2. The Problem
We observe that to allow for mixed use (i.e., some routers running
BFD and some not) [I-D.ietf-bfd-generic] does not require a BFD
session be established prior to the establishment of an IS-IS
adjacency. Thus, if a router A has neighbors B and C, and B does not
support BFD, A would still form adjacencies with B and C, and would
only establish a BFD session with C.
The problem with this solution is that it assumes that the
transmission and receipt of IS-IS IIHs shares fate with forwarded
data packets. This is not a fair assumption to make given that the
primary use of BFD is to protect IPv4 (and IPv6) forwarding and IS-IS
does not utilize IPv4 or IPv6 for sending or receiving its hellos.
Thus, if we consider our previous example, and if C is currently
experiencing an IPv4 forwarding failure that allows for IS-IS IIHs to
be sent and received, when A first starts (or restarts) A will assume
that C simply does not support BFD, will form an adjacency with C,
and may incorrectly forward IPv4 traffic through C.
3. The Solution
A simple solution to this problem is for an IS-IS router to advertise
that it has BFD enabled on a given interface. It can do this through
the inclusion of a TLV in its IIHs, and indeed that is our proposal.
When sending an IIH on a BFD enabled interface, a router which
supports this extension MUST include the BFD enabled TLV in its IIH.
The contents of the TLV MUST indicate what topologies/protocols
[RFC5120] have been enabled for BFD by including the appropriate
Hopps & Ginsberg Expires September 24, 2008 [Page 3]
Internet-Draft IS-IS BFD Enabled TLV March 2008
MTID/NLPID pairs.
When sending an IIH on an interface on which BFD is NOT enabled a
router MUST NOT include the BFD enabled TLV.
3.1. State Definitions
The following definitions apply to each IS-IS neighbor:
For each locally supported MTID/NLPID pair, an
ISIS_TOPO_NLPID_BFD_REQUIRED variable is assigned. If BFD is
supported by both the local system and the neighbor for the MTID/
NLPID this variable is set to TRUE. Otherwise the variable is set to
FALSE.
For each locally supported MTID, an ISIS_TOPO_BFD_REQUIRED variable
is set to the logical OR of all ISIS_TOPO_NLPID_BFD_REQUIRED
variables associated with that MTID.
An ISIS_BFD_REQUIRED variable is set to the logical AND of all
ISIS_TOPO_BFD_REQUIRED variables.
For each locally supported MTID/NLPID pair, an ISIS_TOPO_NLPID_STATE
variable is assigned. If ISIS_TOPO_NLPID_BFD_REQUIRED is TRUE, this
variable follows the BFD session state for that MTID/NLPID (UP ==
TRUE). Otherwise the variable is set to TRUE.
For each locally supported topology (MTID), an ISIS_TOPO_USEABLE
variable is set to the logical AND of the set of
ISIS_TOPO_NLPID_STATE variables associated with that MTID.
An ISIS_NEIGHBOR_USEABLE variable is set to the logical OR of all
ISIS_TOPO_USEABLE variables.
3.2. Adjacency Establishment and Maintenance
Whenever ISIS_BFD_REQUIRED is TRUE the following extensions to the
rules for adjacency establishment and maintenance MUST apply:
o ISIS_NEIGHBOR_USEABLE MUST be TRUE before the adjacency can
transition from INIT to UP state
o When the IS-IS adjacency is UP and ISIS_NEIGHBOR_USEABLE becomes
FALSE the IS-IS adjacency MUST transition to DOWN.
o On a Point-to-Point circuit whenever ISIS_NEIGHBOR_USEABLE is
FALSE, the Three-Way adjacency state MUST be set to DOWN in the
Point-to-Point Three Way Adjacency TLV[RFC3373] in all transmitted
Hopps & Ginsberg Expires September 24, 2008 [Page 4]
Internet-Draft IS-IS BFD Enabled TLV March 2008
IIHs.
o On a LAN circuit whenever ISIS_NEIGHBOR_USEABLE is FALSE, the IS
Neighbors TLV advertising the MAC address of the neighbor MUST be
omitted in all transmitted IIHs.
3.3. Advertisement of Topology Specific IS Neighbors
The advertisement of a topology specific IS-neighbor (as well as the
use of the neighbor in the topology specific decision process) is
determined by the value of ISIS_TOPO_USEABLE for each topology. If
ISIS_TOPO_USEABLE is TRUE then the topology specific neighbor is
advertised. If ISIS_TOPO_USEABLE is FALSE then the topology specific
neighbor is NOT advertised.
4. Transition
To allow for a non-disruptive transition to the use of BFD some
amount of time should be allowed before bringing down an UP adjacency
on a BFD enabled interface when the value of ISIS_BFD_REQUIRED
becomes TRUE as a result of the introduction of the BFD TLV or the
modification (by adding a new supported MTID/NLPID) of an existing
BFD TLV in a neighbor's IIH. A simple way to do this is to not
update the adjacency hold-time when receiving such an IIH from a
neighbor with whom we have an UP adjacency until
ISIS_NEIGHBOR_USEABLE becomes TRUE.
If the value of ISIS_BFD_REQUIRED becomes FALSE as a result of the
removal the BFD TLV or the modification (by removing a supported
MTID/NLPID) of an existing BFD TLV in a neighbor's IIH then BFD
session establishment is no longer required to maintain the adjacency
or transition the adjacency to the UP state.
If a BFD session is administratively shut down [I-D.ietf-bfd-base]
and the BFD session state change impacts the value of
ISIS_NEIGHBOR_USEABLE, then IS-IS SHOULD allow time for the
corresponding MTID/NLPID to be removed from the neighbor's BFD TLV by
not updating the adjacency hold time until ISIS_BFD_REQUIRED becomes
FALSE. Note that while this allows a non-disruptive transition, it
still enforces consistency between the administrative state of the
BFD session and the MTID/NLPID(s) advertised in the BFD TLV. This is
necessary to provide consistent behavior regardless of whether the
BFD AdminDown state is introduced before or after an IS-IS adjacency
UP state has been achieved.
Hopps & Ginsberg Expires September 24, 2008 [Page 5]
Internet-Draft IS-IS BFD Enabled TLV March 2008
5. Graceful Restart
It is worth considering what if anything should be done when IS-IS is
gracefully restarting [RFC3847].
In cases where BFD shares fate with the control plane, it can be
expected that BFD session failure may occur in conjunction with the
control plane restart. In such cases premature abort of IS-IS
graceful restart as a result of BFD session failure is undesirable.
Therefore, some mechanism to ignore the BFD session failure for a
limited period of time would be beneficial. How this is implemented
is beyond the scope of this document. Consult [I-D.ietf-bfd-generic]
for further details.
6. The BFD Enabled TLV
The BFD enabled TLV is formatted as shown below. The TLV SHALL only
be included in an IS-IS IIH PDU and only when BFD is enabled for one
or more supported MTID/protocols on the interface over which the IIH
is being sent. The NLPIDs encoded in the TLV are defined in
[ISO9577]
Type 139 (suggested - to be assigned by IANA)
Length # of octets in the value field (3 to 255)
Value three octets specifying the MTID/NLPID for each
topology/data protocol for which BFD support is enabled
No. of octets
+-----------------------+
|R|R|R|R| MTID | 2
+-----------------------+
| NLPID | 1
+-----------------------+
: :
: :
+-----------------------+
|R|R|R|R| MTID | 2
+-----------------------+
| NLPID | 1
+-----------------------+
7. Security Considerations
The TLV defined within this document describes an addition to the
IS-IS Hello protocol and does not impact the security mechanism of
the IS-IS protocol.
Hopps & Ginsberg Expires September 24, 2008 [Page 6]
Internet-Draft IS-IS BFD Enabled TLV March 2008
8. IANA Considerations
The following IS-IS TLV type is defined by this draft.
Name Value IIH LSP SNP
---------------------- ----- --- --- ---
BFD Enabled TLV 139 y n n
Please update the IS-IS TLV Codepoint Registry accordingly.
Note to RFC Editor: this section may be removed on publication as an
RFC.
9. Acknowledgements
The authors wish to thank Jeffrey Haas, Matthew Jones, Dave Katz,
Jonathan Moon, Stefano Previdi, Mike Shand, Michael Shiplett and
David Ward, for various input on this document.
10. References
10.1. Normative References
[ISO9577] International Organization for Standardization, "Protocol
identification in the network layer(ISO/IEC 9577)", ISO/
IEC 9577:1999, Fourth Edition, Dec 1999.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
10.2. Informative References
[I-D.ietf-bfd-base]
Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", draft-ietf-bfd-base-07 (work in progress),
January 2008.
[I-D.ietf-bfd-generic]
Katz, D. and D. Ward, "Generic Application of BFD",
Hopps & Ginsberg Expires September 24, 2008 [Page 7]
Internet-Draft IS-IS BFD Enabled TLV March 2008
draft-ietf-bfd-generic-04 (work in progress),
January 2008.
[RFC3373] Katz, D. and R. Saluja, "Three-Way Handshake for
Intermediate System to Intermediate System (IS-IS) Point-
to-Point Adjacencies", RFC 3373, September 2002.
[RFC3847] Shand, M. and L. Ginsberg, "Restart Signaling for
Intermediate System to Intermediate System (IS-IS)",
RFC 3847, July 2004.
Authors' Addresses
Christian E. Hopps
Cisco Systems
170 W. Tasman Dr.
San Jose, California 95134
USA
Email: chopps@cisco.com
Les Ginsberg
Cisco Systems
510 McCarthy Blvd.
Milpitas, Ca. 95035
USA
Email: ginsberg@cisco.com
Hopps & Ginsberg Expires September 24, 2008 [Page 8]
Internet-Draft IS-IS BFD Enabled TLV March 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Hopps & Ginsberg Expires September 24, 2008 [Page 9]
