RSVP Setup Retry - BCP
draft-ravisingh-teas-rsvp-setup-retry-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2015-03-09
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
TEAS Working Group                                           Ravi Singh 
 Internet Draft                                            Yakov Rekhter 
 Intended status: Informational                      Vishnu Pavan Beeram 
                                                        Juniper Networks 
                                                              Rob Shakir 
                                                         British Telecom 
                                                              Tarek Saad 
                                                           Cisco Systems 
      
 Expires: September 09, 2015                              March 09, 2015 
                                         
      
                       RSVP Setup Retry - BCP 
              draft-ravisingh-teas-rsvp-setup-retry-00 

 Status of this Memo 

    This Internet-Draft is submitted 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/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 09, 2015. 
         
 Copyright Notice 

    Copyright (c) 2015 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 
      
      
      
      
 Ravi Singh            Expires September 09, 2015               [Page 1] 
 

 Internet-Draft             RSVP Setup Retry                  March 2015 
         

    respect to this document.  Code Components extracted from this 
    document must 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. 
          
 Abstract 

    This document discusses the best current practices associated with 
    the implementation of RSVP setup-retry timer.  

 Conventions used in this document 

    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]. 
        

 Table of Contents 

    1. Introduction...................................................2 
    2. Setup-Retry Timer..............................................3 
    3. Possible ill-effects due to implementation choices.............3 
    4. Causes of the above ill-effects................................5 
    5. Solution to the implementation issues..........................5 
    6. Security Considerations........................................6 
    7. IANA Considerations............................................6 
    8. Normative References...........................................6 
    9. Acknowledgments................................................6 
    10. Authors' Addresses............................................6 
    Contributors......................................................7 
         
 1. Introduction 

    In an RSVP-TE network with a very large number of LSPs, link/node 
    failure(s) may produce a noticeable increase in RSVP-TE control 
    traffic. As a result, RSVP-TE messages might get delayed by virtue 
    of being stuck in a queue that is overwhelmed with messages to be 
    sent or they might get lost forever. For example, a Path message 
    intended to be sent by a transit router might be stuck in the output 
    queue to be sent to the next-hop. Alternately, it might have got 
    dropped on the receive side due to queue overflows. The same could 
    happen for a Resv message in the reverse direction. Also, in the 
    absence of reliable delivery of Path-Error messages [RFC2961], an 
    error that gets generated at transit/egress for an LSP that is in 
    the process of being setup may never make it to the ingress. 
        
      
      
      
 Ravi Singh            Expires September 09, 2015               [Page 2] 
Show full document text