< draft-ietf-ospf-hitless-restart-07.txt   draft-ietf-ospf-hitless-restart-08.txt >
Network Working Group J. Moy (Sycamore Networks) Network Working Group J. Moy (Sycamore Networks)
Internet Draft Padma Pillay-Esnault (Juniper Networks) Internet Draft Padma Pillay-Esnault (Juniper Networks)
Expiration Date: October 2003 Acee Lindem, Editor (Redback Networks) Expiration Date: December 2003 Acee Lindem, Editor (Redback Networks)
File name: draft-ietf-ospf-hitless-restart-07.txt March 2003 File name: draft-ietf-ospf-hitless-restart-08.txt July 2003
Graceful OSPF Restart Graceful OSPF Restart
draft-ietf-ospf-hitless-restart-07.txt draft-ietf-ospf-hitless-restart-08.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 20 skipping to change at page 2, line 20
2.1 Entering graceful restart .............................. 4 2.1 Entering graceful restart .............................. 4
2.2 When to exit graceful restart .......................... 5 2.2 When to exit graceful restart .......................... 5
2.3 Actions on exiting graceful restart .................... 6 2.3 Actions on exiting graceful restart .................... 6
3 Operation of helper neighbor ........................... 6 3 Operation of helper neighbor ........................... 6
3.1 Entering helper mode ................................... 7 3.1 Entering helper mode ................................... 7
3.2 Exiting helper mode .................................... 8 3.2 Exiting helper mode .................................... 8
4 Backward compatibility ................................. 9 4 Backward compatibility ................................. 9
5 Unplanned outages ...................................... 9 5 Unplanned outages ...................................... 9
6 Interaction with Traffic Engineering .................. 10 6 Interaction with Traffic Engineering .................. 10
7 Possible Future Work .................................. 10 7 Possible Future Work .................................. 10
References ............................................ 10 8 Intellectual Property ................................. 10
A Grace-LSA format ...................................... 11 References ............................................ 11
B Configurable Parameters ............................... 13 A Grace-LSA format ...................................... 12
C Change log ............................................ 14 B Configurable Parameters ............................... 14
Security Considerations ............................... 15 Security Considerations ............................... 15
Authors' Addresses .................................... 15 Authors' Addresses .................................... 15
1. Overview 1. Overview
Today many Internet routers implement a separation of control and Today many Internet routers implement a separation of control and
forwarding functions. Certain processors are dedicated to control forwarding functions. Certain processors are dedicated to control
and management tasks such as OSPF routing, while other processors and management tasks such as OSPF routing, while other processors
perform the data forwarding tasks. This separation creates the perform the data forwarding tasks. This separation creates the
possibility of maintaining a router's data forwarding capability possibility of maintaining a router's data forwarding capability
skipping to change at page 3, line 25 skipping to change at page 3, line 25
operation of this router during graceful restart, including how the operation of this router during graceful restart, including how the
router enters and leaves graceful restart, is the subject of Section router enters and leaves graceful restart, is the subject of Section
2. Then there are the router's neighbors, which must cooperate in 2. Then there are the router's neighbors, which must cooperate in
order for the restart to be graceful. During graceful restart we say order for the restart to be graceful. During graceful restart we say
that the neighbors are executing in "helper mode". Section 3 covers that the neighbors are executing in "helper mode". Section 3 covers
the responsibilities of a router executing in helper mode, including the responsibilities of a router executing in helper mode, including
entering and leaving helper mode. entering and leaving helper mode.
1.1. Acknowledgments 1.1. Acknowledgments
The authors wish to thank John Drake, Vishwas Manral, The authors wish to thank John Drake, Vishwas Manral, Kent Wong,
Kent Wong, and Don Goodspeed for their helpful comments. and Don Goodspeed for their helpful comments. We also wish
to thank Alex Zinin and Bill Fenner for their thorough review.
2. Operation of restarting router 2. Operation of restarting router
After the router restarts/reloads, it must change its OSPF After the router restarts/reloads, it must change its OSPF
processing somewhat until it re-establishes full adjacencies with processing somewhat until it re-establishes full adjacencies with
all its previously fully-adjacent neighbors. This time period, all its previously fully-adjacent neighbors. This time period,
between the restart/reload and the reestablishment of adjacencies, between the restart/reload and the reestablishment of adjacencies,
is called "graceful restart". During graceful restart: is called "graceful restart". During graceful restart:
(1) The restarting router does not originate LSAs with LS types (1) The restarting router does not originate LSAs with LS types
skipping to change at page 7, line 36 skipping to change at page 7, line 36
all other segment types X is identified by the grace- all other segment types X is identified by the grace-
LSA's Advertising Router field. LSA's Advertising Router field.
(2) There have been no changes in content to the link-state (2) There have been no changes in content to the link-state
database (LS types 1-5,7) since router X restarted. This database (LS types 1-5,7) since router X restarted. This
is determined as follows. Router Y examines the link- is determined as follows. Router Y examines the link-
state retransmission list for X over the associated state retransmission list for X over the associated
network segment. If there are any LSAs with LS types network segment. If there are any LSAs with LS types
1-5,7 on the list, then they all must be periodic 1-5,7 on the list, then they all must be periodic
refreshes. If there are instead LSAs on the list whose refreshes. If there are instead LSAs on the list whose
contents have changed (see Section 3.3 of [8]), Y must contents have changed (see Section 3.3 of [7]), Y must
refuse to enter helper mode. refuse to enter helper mode. Router Y may optionally
disallow graceful restart with Router X on other network
segments. Determining whether changed LSAs have been
successfully flooded to router Y on other network
segments is feasible but beyond the scope of this
document.
(3) The grace period has not yet expired. This means that the (3) The grace period has not yet expired. This means that the
LS age of the grace-LSA is less than the grace period LS age of the grace-LSA is less than the grace period
specified in the body of the grace-LSA (Appendix A). specified in the body of the grace-LSA (Appendix A).
(4) Local policy allows Y to act as the helper for X. (4) Local policy allows Y to act as the helper for X.
Examples of configured policies might be a) never act as Examples of configured policies might be a) never act as
helper, b) never allow the grace period to exceed a Time helper, b) never allow the grace period to exceed a Time
T, c) only help on software reloads/upgrades, or d) never T, c) only help on software reloads/upgrades, or d) never
act as a helper for certain specific routers (specified act as a helper for certain specific routers (specified
by OSPF Router ID). by OSPF Router ID).
(5) Router Y is not in the process of graceful restart.
There is one exception to the above requirements. If Y was There is one exception to the above requirements. If Y was
already helping X on the associated network segment, the new already helping X on the associated network segment, the new
grace-LSA should be accepted and the grace period should be grace-LSA should be accepted and the grace period should be
updated accordingly. updated accordingly.
Note that Router Y may be helping X on some network segments, Note that Router Y may be helping X on some network segments,
and not on others. However, that circumstance will probably lead and not on others. However, that circumstance will probably lead
to the premature termination of X's graceful restart, as Y will to the premature termination of X's graceful restart, as Y will
not continue to advertise adjacencies on the segments where it not continue to advertise adjacencies on the segments where it
is not helping (see Section 2.2). is not helping (see Section 2.2).
skipping to change at page 8, line 43 skipping to change at page 9, line 14
(3) A change in link-state database contents indicates a (3) A change in link-state database contents indicates a
network topology change, which forces termination of a network topology change, which forces termination of a
graceful restart. Specifically, if router Y installs a graceful restart. Specifically, if router Y installs a
new LSA in its database with LS types 1-5,7 and having new LSA in its database with LS types 1-5,7 and having
the following two properties, it should cease helping X. the following two properties, it should cease helping X.
The two properties of the LSA are a) the contents of the The two properties of the LSA are a) the contents of the
LSA have changed; this includes LSAs with no previous LSA have changed; this includes LSAs with no previous
link-state database instance and the flushing of LSAs link-state database instance and the flushing of LSAs
from the database, but excludes periodic LSA refreshes from the database, but excludes periodic LSA refreshes
(see Section 3.3 of [8]), and b) the LSA would have (see Section 3.3 of [7]), and b) the LSA would have
been flooded to X, had Y and X been fully adjacent. As an been flooded to X, had Y and X been fully adjacent. As an
example of the second property, if Y installs a changed example of the second property, if Y installs a changed
AS-external-LSA, it should not terminate a helping AS-external-LSA, it should not terminate a helping
relationship with a neighbor belonging to a stub area, as relationship with a neighbor belonging to a stub area, as
that neighbor would not see the AS-external-LSA in any that neighbor would not see the AS-external-LSA in any
case. An implementation MAY provide a configuration case. An implementation MAY provide a configuration
option to disable link-state database options from option to disable link-state database options from
terminating graceful restart. Such an option will, terminating graceful restart. Such an option will,
however, increase the risk of routing loops and however, increase the risk of routing loops and
black holes. black holes.
skipping to change at page 10, line 34 skipping to change at page 11, line 5
The operation of the Traffic Engineering Extensions to OSPF [4] The operation of the Traffic Engineering Extensions to OSPF [4]
during OSPF Graceful Restart is specified in [6]. during OSPF Graceful Restart is specified in [6].
7. Possible Future Work 7. Possible Future Work
Devise a less conservative algorithm for graceful restart Devise a less conservative algorithm for graceful restart
helper termination that provides a comparable level of helper termination that provides a comparable level of
black hole and routing loop avoidance. black hole and routing loop avoidance.
8. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Normative References Normative References
[1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[2] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July [2] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July
1998. 1998.
Informative References Informative References
[3] Murphy, S., M. Badger and B. Wellington, "OSPF with Digital [3] Murphy, S., M. Badger and B. Wellington, "OSPF with Digital
Signatures", RFC 2154, June 1997. Signatures", RFC 2154, June 1997.
[4] Katz, D., D. Yeung and K. Kompella, "Traffic Engineering [4] Katz, D., D. Yeung and K. Kompella, "Traffic Engineering
Extensions to OSPF", work in progress. Extensions to OSPF", work in progress.
[5] Coltun, R., V. Fuller and P. Murphy, "The OSPF NSSA Option", [5] Murphy, P., "The OSPF NSSA Option", RFC 3101, January 2003.
work in progress.
[6] Kompella, K., et. al., "Routing Extensions in Support of [6] Kompella, K., et. al., "Routing Extensions in Support of
Generalized MPLS", work in progress. Generalized MPLS", work in progress.
[7] Moy, J., "Extending OSPF to Support Demand Circuits", RFC [7] Moy, J., "Extending OSPF to Support Demand Circuits", RFC
1793, April 1995. 1793, April 1995.
[8] Fenner, W., "Internet Group Membership Protocol, Version 2", [8] Fenner, W., "Internet Group Membership Protocol, Version 2",
RFC 2236, November 1997. RFC 2236, November 1997.
skipping to change at page 11, line 47 skipping to change at page 12, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number | | LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length | | LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- TLVs -+ +- TLVs -+
| ... | | ... |
The format of the TLVs within the body of a grace-LSA is the same as The format of the TLVs within the body of a grace-LSA is the same as
the TLV format used by the Traffic Engineering Extensions to OSPF the format used by the Traffic Engineering Extensions to OSPF [4].
[4]. The TLV header consists of a 16-bit Type field and a 16-bit The LSA payload consists of one or more nested Type/Length/Value
length field, and is followed by zero or more bytes of value. The (TLV) triplets for extensibility. The format of each TLV is:
length field indicates the length of the value portion in bytes. The
value portion is padded to four-octet alignment, but the padding is 0 1 2 3
not included in the length field. For example, a one byte value 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length field defines the length of the value portion in octets
(thus a TLV with no value portion would have a length of zero). The
TLV is padded to four-octet alignment; padding is not included in
the length field (so a three octet value would have a length of
three, but the total size of the TLV would be eight octets). Nested
TLVs are also 32-bit aligned. For example, a one byte value
would have the length field set to 1, and three bytes of padding would have the length field set to 1, and three bytes of padding
would be added to the end of the value portion of the TLV. would be added to the end of the value portion of the TLV.
Unrecognized types are ignored.
The following is the list of TLVs that can appear in the body of a The following is the list of TLVs that can appear in the body of a
grace-LSA. grace-LSA.
o Grace Period (Type=1, length=4). The number of seconds that the o Grace Period (Type=1, length=4). The number of seconds that the
router's neighbors should continue to advertise the router as router's neighbors should continue to advertise the router as
fully adjacent, regardless of the the state of database fully adjacent, regardless of the the state of database
synchronization between the router and its neighbors. Since this synchronization between the router and its neighbors. Since this
time period began when grace-LSA's LS age was equal to 0, the time period began when grace-LSA's LS age was equal to 0, the
grace period terminates when either a) the LS age of the grace- grace period terminates when either a) the LS age of the grace-
skipping to change at page 13, line 5 skipping to change at page 13, line 47
where the helper uses the IP interface address to identify the where the helper uses the IP interface address to identify the
restarting router (see Section 3.1). restarting router (see Section 3.1).
DoNotAge is never set in a grace-LSA, even if the grace-LSA is DoNotAge is never set in a grace-LSA, even if the grace-LSA is
flooded over a demand circuit [7]. This is because the grace-LSA's flooded over a demand circuit [7]. This is because the grace-LSA's
LS age field is used to calculate the extent of the grace period. LS age field is used to calculate the extent of the grace period.
Grace-LSAs have link-local scope because they only need to be seen Grace-LSAs have link-local scope because they only need to be seen
by the router's direct neighbors. by the router's direct neighbors.
Additional Grace-LSA TLVs must be described in an Internet Draft
and will be subject to the expert review of the OSPF Working Group.
B. Configurable Parameters B. Configurable Parameters
OSPF graceful restart parameters are suggested below. Section OSPF graceful restart parameters are suggested below. Section
B.1 contains a minimum subset of parameters that should be B.1 contains a minimum subset of parameters that should be
supported. B.2 includes some additional configuration parameters supported. B.2 includes some additional configuration parameters
an implementation may choose to support. an implementation may choose to support.
B.1 Global Parameters (Minimum subset) B.1 Global Parameters (Minimum subset)
RestartSupport RestartSupport
skipping to change at page 14, line 5 skipping to change at page 15, line 5
RestartHelperStrictLSAChecking RestartHelperStrictLSAChecking
Indicates whether or not an OSPF restart helper should Indicates whether or not an OSPF restart helper should
terminate graceful restart when there is a change to an LSA terminate graceful restart when there is a change to an LSA
that would be flooded to the restarting router or when there that would be flooded to the restarting router or when there
is a changed LSA on the restarting router's retransmission list is a changed LSA on the restarting router's retransmission list
when graceful restart is initiated. The suggested default is when graceful restart is initiated. The suggested default is
enabled. enabled.
C. Change Log (To be removed prior to publication)
Changes from 02 to 03 version:
1. Add Padma Pillay-Esnault and Acee Lindem as authors to help
finish up the draft.
Changes from 03 to 04 version:
1. Add change log (Appendix B).
2. Document that the grace period is restricted to
LSRefreshTime (Section 2.1).
3. Document an alternative to saving cryptographic sequence
numbers in non-volatile storage (Section 2.1).
4. Document that an implementation may aggregate multiple
adjacencies with a restarting router when entering or exiting
helper mode (Section 3.1 and 3.2).
5. Document that an implementation may disable graceful
restart helper termination when the link-state database
changes (Section 3.2).
6. In the case of an unplanned restart, document that
grace LSAs should be flooded to AllSPFRouters on
broadcast networks (Section 5).
7. Remove MOSPF from future work. Add Vishwas's suggested
technique for less conservative helper mode termination as
possible future work (Section 7).
8. Change references and citations to meet prevailing IETF
standards.
Changes from 04 to 05 version:
1. Add Appendix B (Configurable Parameters) and make the Change
Log Appendix C.
Changes from 05 to 06 version:
1. Change from "hitless restart" to "graceful restart" to be
consistent with other protocol documents.
Changes from 06 to 07 version:
1. Add clarification that a missing pre-restart LSA causes
the restarting router to terminate graceful restart.
Security Considerations Security Considerations
One of the ways to attack a link-state protocol such as OSPF is to One of the ways to attack a link-state protocol such as OSPF is to
inject false LSAs into, or corrupt existing LSAs in, the link-state inject false LSAs into, or corrupt existing LSAs in, the link-state
database. Injecting a false grace-LSA would allow an attacker to database. Injecting a false grace-LSA would allow an attacker to
spoof a router that, in reality, has been withdrawn from service. spoof a router that, in reality, has been withdrawn from service.
The standard way to prevent such corruption of the link-state The standard way to prevent such corruption of the link-state
database is to secure OSPF protocol exchanges using the database is to secure OSPF protocol exchanges using the
Cryptographic authentication specified in [1]. An even stronger cryptographic authentication specified in [1]. An even stronger
way of securing link-state database contents has been proposed in way of securing link-state database contents has been proposed in
[3]. [3].
When crytographic authentication [1] is used on the restarting
router the preservation of receive sequence numbers in
non-volatile storage is not mandatory. There is a risk that a
replayed Hello packet could cause neighbor state for a deceased
neighbor to be created. However, the risk is no greater than
during normal operation.
Authors' Addresses Authors' Addresses
J. Moy J. Moy
Sycamore Networks, Inc. Sycamore Networks, Inc.
150 Apollo Drive 150 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
Phone: (978) 367-2505 Phone: (978) 367-2505
Fax: (978) 256-4203 Fax: (978) 256-4203
email: jmoy@sycamorenet.com email: jmoy@sycamorenet.com
 End of changes. 15 change blocks. 
65 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/