< draft-minei-mpls-ldp-planned-restart-00.txt   draft-minei-mpls-ldp-planned-restart-01.txt >
Network Working Group Ina Minei
Network Working Group Ina Minei INTERNET DRAFT Rahul Aggarwal
INTERNET DRAFT Rahul Aggarwal Expiration Date: April 2005 Juniper Networks
Expiration Date: August 2004 Juniper Networks Albert Tian
Albert Tian Redback Networks
Redback Networks Vasile Radoaca
Nortel Networks, Inc.
Jason Rusmisel
Alcatel
LDP graceful restart for planned outages LDP graceful restart for planned outages
draft-minei-mpls-ldp-planned-restart-00.txt draft-minei-mpls-ldp-planned-restart-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, we certify that any applicable patent
or other IPR claims of which we are aware have been disclosed, or will
be disclosed, and any of which we become aware will be disclosed, in
accordance with RFC 3668.
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.'' or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society 2003. All Rights Reserved.
Abstract Abstract
This document proposes an enhancement to the LDP graceful restart This document proposes an enhancement to the LDP graceful restart
procedures defined in RFC 3478. The proposed extension allows operators procedures defined in RFC 3478. The proposed extension allows operators
to apply graceful restart only when the restart is planned (as oppossed to apply graceful restart only when the restart is planned (as opposed
to both planned and unplanned restart). to both planned and unplanned restart).
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1. Introduction 1. Introduction
Graceful restart assumes that the restarting LSR could preserve its Graceful restart assumes that the restarting LSR could preserve its
MPLS forwarding state across the restart of its control plane. Under MPLS forwarding state across the restart of its control plane. Under
this assumption, RFC 3478 describes the procedures used in order to this assumption, RFC 3478 describes the procedures used in order to
avoid perturbing the LSPs going through the LSR whose control plane avoid perturbing the LSPs going through the LSR whose control plane
skipping to change at page 2, line 24 skipping to change at page 2, line 27
restarting LSR (LSRA) and of the neighbor of the restarting LSR restarting LSR (LSRA) and of the neighbor of the restarting LSR
(LSRB) is changed. Most importantly for this discussion, LSRB needs (LSRB) is changed. Most importantly for this discussion, LSRB needs
to maintain the session with LSRA, and help LSRA recover its state to maintain the session with LSRA, and help LSRA recover its state
from before the restart. To accomplish this, LSRB needs to know 1) if from before the restart. To accomplish this, LSRB needs to know 1) if
LSRA is graceful restart capable, 2) what is the upper bound on the LSRA is graceful restart capable, 2) what is the upper bound on the
time it will take LSRA to reestablish the peering and 3) what is the time it will take LSRA to reestablish the peering and 3) what is the
time that LSRB needs to maintain LSRA's stale state. time that LSRB needs to maintain LSRA's stale state.
The graceful restart capabilities and parameters are negotiated in The graceful restart capabilities and parameters are negotiated in
the Fault Tolerant (FT) Session TLV optional parameter in the session the Fault Tolerant (FT) Session TLV optional parameter in the session
initialization message [RFC3479]. Thus, a change in the graceful initialization message [RFC3479]. Thus, a change in the graceful
restart capabilities requires resetting the LDP session, since the restart capabilities requires resetting the LDP session, since the
new information needs to be signaled in a new initialization message. new information needs to be signaled in a new initialization message.
A control plane restart may be an unplanned event such as a router A control plane restart may be an unplanned event such as a router
crash, or a planned event, such as planned downtime. An operator may crash, or a planned event, such as planned downtime. An operator may
choose to use graceful restart selectively, for planned restarts choose to use graceful restart selectively, for planned restarts
only, for example in order to achieve smooth software upgrades. only, for example in order to achieve smooth software upgrades.
However, if toggling the graceful functionality resets the session, However, if toggling the graceful functionality resets the session,
the usefulness of graceful restart in such scenarios is defeated. the usefulness of graceful restart in such scenarios is defeated.
The proposed extension allows operators to apply graceful restart The proposed extension allows operators to apply graceful restart
only when the restart is planned, without having to reset the session only when the restart is planned, without having to reset the session
first. first. From a functionality point of view, the extensions described
in this document add the capability to do controlled shutdown and
restart of the control plane described in [RFC3479], to LSRs running
the graceful restart procedures described in [RFC3478]. This
capability is attractive to network operators since: a) it allows in-
service software upgrades for networks where graceful restart is not
part of the normal operation mode and b) it allows network operators
to gain experience and confidence with graceful restart in a
controlled environment.
2. LDP extensions 2. LDP extensions
A new Optional Parameter is defined for use in notification messages. The FT Session TLV defined in RFC 3479 is added as an Optional
Parameter for use in notification messages.
Optional Parameter Type Length Value The FT Session TLV is used in notification messages with Shutdown
GR Data TLV TBD 16 see below Status Code. By virtue of the settings of the U and F bits in the FT
Session TLV, an LSR receiving a shutdown notification with the
optional FT Session TLV parameter, which does not support it, will
ignore the FT Session TLV parameter but process the notification.
The type of the GR(Graceful Restart) Data TLV is not yet assigned, The values filled in the FT Session TLV follow the requirements from
but will be such that the U-bit is 1 and the F-bit is 0. Thus, an RFC 3478.
LSR receiving this TLV and which doesn't support it, will simply
ignore the TLV, but process the message that carried it.
The value field of the GR Data TLV contains an FT Session TLV as A new flag P is defined for use in the FT Session TLV that is
defined in RFC 3479. The values filled in the FT Session TLV follow exchanged in the initialization message. The new flag is part of the
the requirements from RFC 3478. "Flags" field of the FT Session TLV and is used to indicate whether
the LSR supports graceful restart for planned outages, as described
in this draft. The value of the flag is not yet assigned.
The GR Data optional parameter will only show up in notification The P flag is only used in conjunction with the L flag, when using
messages with Shutdown Status Code. By virtue of the settings of the the FT Session TLV as described in [RFC3478].
U and F bits in the GR Data TLV, an LSR receiving a shutdown
notification with the optional GR Data TLV parameter, which does not Using the P flag, the LSR determines which of its neighbors supports
support it, will ignore the GR Data TLV paramter but process the the extensions described in this document. This knowledge is not
notification. needed for the correct operation of the extensions described here.
However, it brings value from a network operations point of view.
Before issuing a planned restart, the network operator will want to
verify that all the neighbors of the restarting LSR can provide the
behavior described in this document. Thus, the operator can determine
if he will get the expected benefits of doing a planned restart.
Rather than individually checking all neighbors, the operator can
obtain this information from the LSR that is the candidate for
planned restart.
3. Operation 3. Operation
In the discussion below, LSRA is the restarting LSR, and LSRB is the In the discussion below, LSRA is the restarting LSR, and LSRB is the
neighbor of LSRA. The goal is for LSRA to do graceful restart only neighbor of LSRA. The goal is for LSRA to do graceful restart only
for planned restarts, and do ungraceful restarts in all other cases. for planned restarts, and do ungraceful restarts in all other cases.
Both LSRA and LSRB set the P flag in the FT Session TLV that is
exchanged at session initialization time, to indicate that they
support the extensions described in this document.
3.1. Changes for the LSR doing a planned restart 3.1. Changes for the LSR doing a planned restart
When performing a planned restart, LSRA MUST send a notification When performing a planned restart, LSRA MUST send a notification
message with Shutdown Status Code and with optional parameter GR message with Shutdown Status Code and with optional parameter FT
Data TLV. The values filled in the FT Session TLV included in the GR Session TLV. The values in the FT Session TLV are: a) the Reconnect
Data TLV MUST be as follows: a) the Reconnect Time is non-zero and Time MUST be non-zero and long enough to allow the LDP component on
long enough to allow the LDP component on LSRA to reach the stage LSRA to reach the stage where it can exchange LDP messages, b) the
where it can exchange LDP messages. b) the Recovery Time is zero. Recovery Time MUST be zero, and c) The P bit SHOULD be set.
The values filled in the FT Session TLV in the initialization message The values filled in the FT Session TLV in the initialization message
MUST be set as follows: a) the Reconnect Time is zero b) the Recovery MUST be set as follows: a) the Reconnect Time is zero, b) the
Time is set according to whether LSRA could preserve its state after Recovery Time is set according to whether LSRA could preserve its
the restart, state after the restart, and c) the P bit is set.
3.2. Changes for the neighbor of the LSR doing a planned restart 3.2. Changes for the neighbor of the LSR doing a planned restart
When the neighbor LSRB receives a notification with Shutdown Status When the neighbor LSRB receives a notification with Shutdown Status
Code and with the optional parameter GR Data TLV, LSRB SHOULD do the Code and with the optional parameter FT Session TLV, LSRB SHOULD do
following: the following:
Read the values in the FT Session TLV and update the graceful restart Read the values in the FT Session TLV and update the graceful restart
state for the session as if these values were received in the state for the session as if these values were received in the
initialization message. From this point on, LSRB will do the initialization message. From this point on, LSRB will do the
appropriate graceful restart procedures as defined in RFC 3478. appropriate graceful restart procedures as defined in RFC 3478.
The procedures above yield the following behaviour: The procedures above yield the following behaviour:
If the neighbor doesn't support graceful restart helper mode - If the neighbor doesn't support graceful restart helper mode -
ungraceful restart will take place. ungraceful restart will take place.
If the neighbor supports graceful restart helper mode, then there are If the neighbor supports graceful restart helper mode, then there are
two cases: a) the neighbor supports the extensions defined here - two cases: a) the neighbor supports the extensions defined here -
graceful restart will be performed, assuming LSRA could maintain its graceful restart will be performed, assuming LSRA could maintain its
state across the restart. b) the neighbor doesn't support the state across the restart. b) the neighbor doesn't support the
extensions defined here - ungraceful restart will be performed (since extensions defined here - ungraceful restart will be performed (since
the reconnect time advertised at init time is zero) the reconnect time advertised at initialization time is zero)
4. Security considerations 4. Security considerations
The security considerations pertaining to the original LDP protocol The security considerations pertaining to the original LDP protocol
[RFC3036] remain relevant. [RFC3036] remain relevant.
5. Intellectual Property Considerations 5. Intellectual Property Statement
Juniper Networks may have intellectual property rights claimed in The IETF takes no position regarding the validity or scope of any
regard to some of the specification contained in this document. Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
6. Acknowledgments Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
6. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Additional copyright notices are not permitted in IETF Documents
except in the case where such document is the product of a joint
development effort between the IETF and another standards development
organization or the document is a republication of the work of
another standards organization. Such exceptions must be approved on
an individual basis by the IAB.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
7. Acknowledgments
This work is the outcome of discussions with Kireeti Kompella, Yakov This work is the outcome of discussions with Kireeti Kompella, Yakov
Rekhter and Arthi Ayyangar. The authors would like to thank them for Rekhter and Arthi Ayyangar. The authors would like to thank them for
their suggestions and insight. their suggestions and insight.
7. References 8. References
8.1. Normative References
[RFC1700] Reynolds, J., Postel, J., "Assigned numbers", RFC 1700, [RFC1700] Reynolds, J., Postel, J., "Assigned numbers", RFC 1700,
October 1994 October 1994
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC3036] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP [RFC3036] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP
Specification", RFC 3036, January 2001 Specification", RFC 3036, January 2001
[RFC3478] Leelanivas M., Rekhter Y., Aggarwal R., "Graceful Restart [RFC3478] Leelanivas M., Rekhter Y., Aggarwal R., "Graceful Restart
Mechanism for Label Distribution Protocol" Mechanism for Label Distribution Protocol"
[RFC3479] Farrel A., " Fault Tolerance for the Label Distribution [RFC3479] Farrel A., " Fault Tolerance for the Label Distribution
Protocol (LDP)" Protocol (LDP)"
8. Authors' Addresses 9. Authors' Addresses
Ina Minei Ina Minei
Juniper Networks Juniper Networks
1194 N.Mathilda Ave 1194 N.Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
e-mail: ina@juniper.net e-mail: ina@juniper.net
phone: 408.745.2000
Rahul Aggarwal Rahul Aggarwal
Juniper Networks Juniper Networks
1194 N.Mathilda Ave 1194 N.Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
e-mail: rahul@juniper.net e-mail: rahul@juniper.net
phone: 408.745.2000
Albert Tian Albert Tian
Redback Networks, Inc. Redback Networks, Inc.
300 Holger Way 300 Holger Way
San Jose, CA 95134 San Jose, CA 95134
Email: tian@redback.com Email: tian@redback.com
Vasile Radoaca
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821 USA
Email: vasile@nortelnetworks.com
Jason Rusmisel
Alcatel
600 March Road,
Kanata, Ontario,
Canada, K2K 2E6
Email: jason.rusmisel@alcatel.com
 End of changes. 29 change blocks. 
56 lines changed or deleted 122 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/