Internet DRAFT - draft-madhukar-ospf-agr-asymmetric

draft-madhukar-ospf-agr-asymmetric



 



INTERNET-DRAFT                                            Madhukar Anand
                                                           Hasmit Grover
                                                               Abhay Roy
Intended Status: Proposed Standard                         Cisco Systems
Expires: Nov 16, 2013                                        Jun 16, 2013


                       Asymmetric OSPF Hold Timer
                 draft-madhukar-ospf-agr-asymmetric-01


Abstract

   Current OSPF standard requires that the HELLO/Dead interval be
   symmetric on either side of the link in order to maintain adjacency.
   There are many scenarios in which this may not be desirable. This
   memo describes a technique to allow OSPF adjacency to be maintained
   with asymmetric values of the OSPF Dead interval.


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) 2013 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
 


Anand et al.              Expires Jul 25, 2013                  [Page 1]

INTERNET DRAFT         Asymmetric OSPF Hold Timer           <Issue Date>


   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
   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  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  Proposed Solution . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1 Sending HELLOs with Asymmetric Hold Timers.  . . . . . . . .  4
     2.2 Receiving HELLOs with Asymmetric Hold Timer Values.  . . . .  5
   4  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . .  7
   6  Backward Compatibility  . . . . . . . . . . . . . . . . . . . .  8
   7  Security Considerations . . . . . . . . . . . . . . . . . . . .  9
   8  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  9
   9  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1  Normative References  . . . . . . . . . . . . . . . . . . .  9
     9.2  Informative References  . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9





















 


Anand et al.              Expires Jul 25, 2013                  [Page 2]

INTERNET DRAFT         Asymmetric OSPF Hold Timer           <Issue Date>


1  Introduction

   With networking infrastructure becoming critical for businesses, many
   networking vendors now design their routing software implementations
   to deliver high availability and built-in redundancy. To meet these
   requirements, routing processes support features such as crash
   recovery and in-service software upgrades.  For control plane
   protocols such as OSPF, this typically translates to recovering and
   restoring state across process restarts.  Crash recovery and upgrades
   via state restoration has advantages over graceful restart in that,
   there is no control traffic between neighbors, and there is no
   requirement of the topology being intact during this window. 

   One of the implications of such busy periods of state restoration in
   a process is that, the process may not be able to sustain the rate of
   sending HELLOs across all its interfaces.  In a controlled restart
   scenario (such as OSPF Graceful restart), the router is able to ask
   for a grace period by flooding out opaque LSAs indicating that it is
   restarting.  In case of upgrades and restarts with state restoration,
   (i.e., not involving a graceful restart), this is not possible.  

   An alternative, in these situations, is for the router to be able to
   send HELLOs at a reduced frequency during this window, and resume the
   normal (configured) functionality after its recovery or upgrade. If
   this alternative is to be supported, OSPF routers in the network
   would have to relax the requirement that HELLO and dead intervals be
   the same on either side of the network.  

   Yet another scenario where such asymmetric HELLO intervals may be
   desirable would be the case where routers of disparate load and
   configuration form an adjacency. For example, the number of
   adjacencies in a stub area router, and an adjacent ABR can
   potentially differ by an order of magnitude. Another example is in
   the case of a hub and spoke topology. The hub router is definitely
   more loaded than the spoke router. Further, in such topologies it may
   be desirable that the failure of a non-central (leaf node) router is
   to be detected faster, so that the routers in the center of the
   topology can possibly reroute traffic.  This could be  supported, for
   instance, by having the non-central routers send HELLOs at a much
   faster rate than the central routers. 

   Finally, OSPFv3 Auto-configuration [OSPFV3-AUTOCONFIG] calls for
   flexibility in OSPFv3 HELLO and Dead intervals (See Sec 3 of [OSPFV3-
   AUTOCONFIG]). These requirements can be easily met by implementing
   the proposal here.


1.1  Terminology
 


Anand et al.              Expires Jul 25, 2013                  [Page 3]

INTERNET DRAFT         Asymmetric OSPF Hold Timer           <Issue Date>


   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  Proposed Solution

   We expect that OSPF interface on which an asymmetric hold timer is to
   be supported have appropriate CLI configuration to accept the normal
   (symmetric), and alternate (potentially asymmetric) values of Dead
   interval. Alternatively, the asymmetric value of Dead interval could
   also be derived through other means. Henceforth, we refer to the
   (potentially) asymmetric dead interval advertised by a router as the
   OSPF hold interval for that router on the receiving link. 

   Another requirement is that, all routers in the network that form an
   OSPF adjacency have this capability, i.e., understand and support the
   changes proposed in this document. The latter requirement would
   prevent OSPF routers not supporting this feature from forming
   adjacencies with routers that are already running with asymmetric
   DEAD intervals, and adjacency down would be detected. 

2.1 Sending HELLOs with Asymmetric Hold Timers. 

   Routers that wish to set asymmetric hold timer in OSPF  would make
   use of the LLS block (RFC 4813) attached to the HELLO packet, with
   the following changes. 

   1. The router will set the L-bit indicating the presence of the LLS
   block. The router will also set the LLS type to 0 (reserved), and use
   the following extended options bit (0x00000003) in the EO-TLV,
   introduced for this purpose. 

   Extended Options Bit      Name                        Reference
   0x00000003              Asymmetric Hello capability   draft-madhukar-
   ospf-asymmetric-01 

   2. The value of the hold timer would be specified in a LLS TLV. Note
   that the LLS TLV types are maintained by the IANA, and this document
   proposes the introduction of a new TLV. The type field of the new TLV
   is proposed to be 18, the length of the value is 4 bytes.

   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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |              18               |               4               |
 


Anand et al.              Expires Jul 25, 2013                  [Page 4]

INTERNET DRAFT         Asymmetric OSPF Hold Timer           <Issue Date>


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                      OSPF Hold Timer Value                    |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   3. Routers must set the HELLO and Dead interval values carried in the
   OSPF HELLO packet to zero.

   4. To stop advertising the asymmetric hold timer value, routers will
   simply revert back to advertising configured (non-zero) values of
   HELLO and dead interval in the OSPF Hello packet.

   The mechanism of sending HELLOs would remain as specified in Sec 9.5
   of RFC 2328.

2.2 Receiving HELLOs with Asymmetric Hold Timer Values. 

   The processing of an incoming HELLO packet with the L-bit set, and
   containing the extended options set for alternate HELLOs would follow
   the specification in Sec 10.5 of RFC 2328 with one modification.

   1. Routers that recognize this new extended options will set the
   value of the neighbor dead interval to the value specified in the LLS
   block TLV, but only if BOTH the HELLO and dead interval are set to
   zero in the OSPF HELLO packet.

   2. Routers that do not recognize the extended options would drop
   adjacency as it will not match with the configured (or default) HELLO
   or dead interval as specified in Sec 10.5 of RFC 2328.

   Note that, routers can stop appending the LLS block in their HELLO,
   and the neighbors will simply (re)start using the value specified in
   the HELLO packet.   














 


Anand et al.              Expires Jul 25, 2013                  [Page 5]

INTERNET DRAFT         Asymmetric OSPF Hold Timer           <Issue Date>


4  Discussion

   It is possible to use Bidirectional Forwarding Detection (BFD) [RFC
   5880] to alleviate some of the concerns in the use-cases identified
   above. Relying entirely on BFD without OSPF HELLOs is not a
   possibility given that OSPF HELLOs are still used for discovery of
   neighbors. The BFD approach has its own shortcomings such as limited
   cross-vendor and cross-platform support and also performance
   implications, especially with increasing scale requirements. In any
   case, BFD can be made to work in conjunction with the proposal in
   this document to achieve the best possible network performance. It is
   intended that the proposal for asymmetric hold timer would work
   independent of BFD deployment considerations, and could also help in
   new applications where it may be desirable to support asymmetric and
   possibly dynamic dead interval values (e.g., OSPFv3 Auto-
   Configuration, [OSPFV3-AUTOCONFIG]).
































 


Anand et al.              Expires Jul 25, 2013                  [Page 6]

INTERNET DRAFT         Asymmetric OSPF Hold Timer           <Issue Date>


5  Acknowledgements

    The authors would like to thank Paul Wells for careful review of
   this document. We would also like to thank Anton Smirnov for
   reviewing this document and bringing the BFD alternative to our
   attention.  










































 


Anand et al.              Expires Jul 25, 2013                  [Page 7]

INTERNET DRAFT         Asymmetric OSPF Hold Timer           <Issue Date>


6  Backward Compatibility

     No modifications to OSPF packet formats are proposed here. The new
   EO-TLV introduced here is standard OSPF because LLS-incapable routers
   will not consider the extra data after the packet; i.e., the LLS data
   block will be ignored by routers that do not support the LLS
   extension.









































 


Anand et al.              Expires Jul 25, 2013                  [Page 8]

INTERNET DRAFT         Asymmetric OSPF Hold Timer           <Issue Date>


7  Security Considerations

    The function described in this document does not create any new
   security issues for the OSPF protocol.


8  IANA Considerations

   Please refer to the "IANA Considerations" section of [RFC4813] for  
   more information on the Extended Options bit definitions.



9  References

9.1  Normative References

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 2434, October
              1998.


9.2  Informative References

   [OSPFV3-AUTOCONFIG]  Lindem, A., and Arkko, J., "OSPFv3 Auto-
              Configuration", draft-ietf-ospf-ospfv3-autoconfig-02.txt,
              Apr 15, 2013 (work in progress).

   [RFC4813]  Friedman, B., Nguyen, L., Roy, A., Yeung, D., and A.
              Zinin, "OSPF Link-Local Signaling", RFC 4813, March 2007.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding
              Detection", RFC 5880, June 2010.

Authors' Addresses


              Madhukar Anand
              Cisco Systems
              170 W Tasman Drive
              San Jose, CA  95138
              US

 


Anand et al.              Expires Jul 25, 2013                  [Page 9]

INTERNET DRAFT         Asymmetric OSPF Hold Timer           <Issue Date>


              Email: anandmkr@cisco.com






              Hasmit Grover
              Cisco Systems
              170 W Tasman Drive
              San Jose, CA  95138
              US

              Email: hasmit@cisco.com

              Abhay Roy
              Cisco Systems
              170 W Tasman Drive
              San Jose, CA  95138
              US

              Email: akr@cisco.com





























Anand et al.              Expires Jul 25, 2013                 [Page 10]