datatracker.ietf.org
Sign in
Version 5.6.4.p1, 2014-10-20
Report a bug

Three-Way Handshake for IS-IS Point-to-Point Adjacencies
RFC 5303

Document type: RFC - Proposed Standard (October 2008; Errata)
Obsoletes RFC 3373
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 5303 (Proposed Standard)
Responsible AD: Ross Callon
Send notices to: isis-chairs@tools.ietf.org, draft-ietf-isis-rfc3373bis@tools.ietf.org

Network Working Group                                            D. Katz
Request for Comments: 5303                              Juniper Networks
Obsoletes: 3373                                                R. Saluja
Category: Standards Track                             Tenet Technologies
                                                         D. Eastlake 3rd
                                                    Eastlake Enterprises
                                                            October 2008

        Three-Way Handshake for IS-IS Point-to-Point Adjacencies

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   The IS-IS routing protocol (Intermediate System to Intermediate
   System, ISO 10589) requires reliable protocols at the link layer for
   point-to-point links.  As a result, it does not use a three-way
   handshake when establishing adjacencies on point-to-point media.
   This paper defines a backward-compatible extension to the protocol
   that provides for a three-way handshake.  It is fully interoperable
   with systems that do not support the extension.

   Additionally, the extension allows the robust operation of more than
   256 point-to-point links on a single router.

   This extension has been implemented by multiple router vendors; this
   paper is provided to the Internet community in order to allow
   interoperable implementations to be built by other vendors.

Katz, et al.                Standards Track                     [Page 1]
RFC 5303             Three-Way Handshake for IS-IS          October 2008

Table of Contents

   1. Introduction ....................................................2
      1.1. Terminology ................................................3
   2. Overview of Extensions ..........................................3
      2.1. Handshaking ................................................3
      2.2. More than 256 Interfaces ...................................4
   3. Details .........................................................5
      3.1. Syntax .....................................................5
      3.2. Elements of Procedure ......................................6
   4. IANA Considerations .............................................8
   5. Security Considerations .........................................9
   6. Changes from RFC 3373 ...........................................9
   7. Acknowledgements ................................................9
   8. Normative References ............................................9
   9. Informative References ..........................................9

1.  Introduction

   The IS-IS protocol [ISIS] assumes certain requirements stated in ISO
   10589 (section 6.7.2) for the operation of IS-IS over point-to-point
   links and hence provides only a two-way handshake when establishing
   adjacencies on point-to-point links.  The protocol does not operate
   correctly if these subnetwork requirements for point-to-point links
   are not met.  The basic mechanism defined in the standard is that
   each side declares the other side to be reachable if a Hello packet
   is heard from it.  Once this occurs, each side then sends a Complete
   Sequence Number PDU (CSNP) to trigger database synchronization.

   Three failure modes are known.  First, if the link goes down and then
   comes back up, or one of the systems restarts, and the CSNP packet is
   lost, and the network has a cut set of one through the link, the link
   state databases on either side of the link will not synchronize for a
   full Link State Protocol Data Unit (LSP) refresh period (up to 18
   hours).

   A second, more serious failure is that if the link fails in only one
   direction, the failure will only be detected by one of the systems.
   Normally only one of the two systems will announce the adjacency in
   its link state packets, and the SPF algorithm will thus ignore the
   link.  However, if there are two parallel links between systems and
   one of them fails in one direction, SPF will still calculate paths
   between the two systems, and the system that does not notice the
   failure will attempt to pass traffic down the failed link (in the
   direction that does not work).

   The third issue is that on some physical layers, the
   interconnectivity between endpoints can change without causing a

Katz, et al.                Standards Track                     [Page 2]
RFC 5303             Three-Way Handshake for IS-IS          October 2008

[include full document text]