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]
