draft-ietf-ospf-link-overload-15.txt   draft-ietf-ospf-link-overload-16.txt 
Open Shortest Path First IGP S. Hegde Open Shortest Path First IGP S. Hegde
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Intended status: Standards Track P. Sarkar Intended status: Standards Track P. Sarkar
Expires: August 4, 2018 Arrcus, Inc. Expires: August 8, 2018 Arrcus, Inc.
H. Gredler H. Gredler
Individual Individual
M. Nanduri M. Nanduri
ebay Corporation ebay Corporation
L. Jalil L. Jalil
Verizon Verizon
January 31, 2018 February 4, 2018
OSPF Graceful Link shutdown OSPF Graceful Link shutdown
draft-ietf-ospf-link-overload-15 draft-ietf-ospf-link-overload-16
Abstract Abstract
When a link is being prepared to be taken out of service, the traffic When a link is being prepared to be taken out of service, the traffic
needs to be diverted from both ends of the link. Increasing the needs to be diverted from both ends of the link. Increasing the
metric to the highest value on one side of the link is not sufficient metric to the highest value on one side of the link is not sufficient
to divert the traffic flowing in the other direction. to divert the traffic flowing in the other direction.
It is useful for the routers in an OSPFv2 or OSPFv3 routing domain to It is useful for the routers in an OSPFv2 or OSPFv3 routing domain to
be able to advertise a link as being in a graceful-shutdown state to be able to advertise a link as being in a graceful-shutdown state to
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
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 time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 4, 2018. This Internet-Draft will expire on August 8, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Flooding Scope . . . . . . . . . . . . . . . . . . . . . . . 4 3. Flooding Scope . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4
4.1. OSPFv2 graceful-link-shutdown sub-TLV . . . . . . . . . . 4 4.1. OSPFv2 graceful-link-shutdown sub-TLV . . . . . . . . . . 4
4.2. Remote IPv4 Address Sub-TLV . . . . . . . . . . . . . . . 5 4.2. Remote IPv4 Address Sub-TLV . . . . . . . . . . . . . . . 4
4.3. Local/Remote Interface ID Sub-TLV . . . . . . . . . . . . 6 4.3. Local/Remote Interface ID Sub-TLV . . . . . . . . . . . . 5
4.4. OSPFv3 Graceful-Link-Shutdown sub-TLV . . . . . . . . . . 6 4.4. OSPFv3 Graceful-Link-Shutdown sub-TLV . . . . . . . . . . 6
4.5. BGP-LS Graceful-Link-Shutdown TLV . . . . . . . . . . . . 7 4.5. BGP-LS Graceful-Link-Shutdown TLV . . . . . . . . . . . . 6
4.6. Distinguishing parallel links . . . . . . . . . . . . . . 7 4.6. Distinguishing parallel links . . . . . . . . . . . . . . 7
5. Elements of procedure . . . . . . . . . . . . . . . . . . . . 8 5. Elements of procedure . . . . . . . . . . . . . . . . . . . . 8
5.1. Point-to-point links . . . . . . . . . . . . . . . . . . 9 5.1. Point-to-point links . . . . . . . . . . . . . . . . . . 9
5.2. Broadcast/NBMA links . . . . . . . . . . . . . . . . . . 10 5.2. Broadcast/NBMA links . . . . . . . . . . . . . . . . . . 9
5.3. Point-to-multipoint links . . . . . . . . . . . . . . . . 10 5.3. Point-to-multipoint links . . . . . . . . . . . . . . . . 10
5.4. Unnumbered interfaces . . . . . . . . . . . . . . . . . . 10 5.4. Unnumbered interfaces . . . . . . . . . . . . . . . . . . 10
5.5. Hybrid Broadcast and P2MP interfaces . . . . . . . . . . 11 5.5. Hybrid Broadcast and P2MP interfaces . . . . . . . . . . 10
6. Backward compatibility . . . . . . . . . . . . . . . . . . . 11 6. Backward compatibility . . . . . . . . . . . . . . . . . . . 10
7. Applications . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Applications . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Pseudowire Services . . . . . . . . . . . . . . . . . . . 11 7.1. Overlay Network . . . . . . . . . . . . . . . . . . . . . 11
7.2. Controller based Traffic Engineering Deployments . . . . 12 7.2. Controller based Deployments . . . . . . . . . . . . . . 12
7.3. L3VPN Services and sham-links . . . . . . . . . . . . . . 13 7.3. L3VPN Services and sham-links . . . . . . . . . . . . . . 13
7.4. Hub and spoke deployment . . . . . . . . . . . . . . . . 14 7.4. Hub and spoke deployment . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
When a node is being prepared for a planned maintenance or upgrade, This document describes a mechanism for gracefully taking a link out
[RFC6987] provides mechanisms to advertise the node being in a of service while allowing it to be used if no other path is
graceful-shutdown state by setting all outgoing link costs to available.It also provides a mechanism to divert the traffic from
MaxLinkMetric (0xffff). These procedures are specific to the both directions of the link.
maintenance activity on a node and cannot be used when a single link
on a node requires maintenance.
In traffic-engineering deployments, LSPs need to be diverted from the
link without disrupting the services. [RFC5817] describes
requirements and procedures for graceful shutdown of MPLS links. It
is useful to be able to advertise the impending maintenance activity
on the link and to have LSP re-routing policies at the ingress to
route the LSPs away from the link.
Many OSPFv2 or OSPFv3 deployments run on overlay networks provisioned Many OSPFv2 or OSPFv3 deployments run on overlay networks provisioned
by means of pseudo-wires or L2-circuits. Prior to devices in the by means of pseudo-wires or L2-circuits. Prior to devices in the
underlying network going offline for maintenance, it is useful to underlying network going offline for maintenance, it is useful to
divert the traffic away from the node before the maintenance is divert the traffic away from the node before the maintenance is
actually performed. Since the nodes in the underlying network are actually performed. Since the nodes in the underlying network are
not visible to OSPF, the existing stub router mechanism described in not visible to OSPF, the existing stub router mechanism described in
[RFC6987] cannot be used. In a service provider's network, there may [RFC6987] cannot be used. In a service provider's network, there may
be many CE-to-CE connections that run over a single PE. It is be many CE-to-CE connections that run over a single PE. It is
cumbersome to change the metric on every CE-to-CE connection in both cumbersome to change the metric on every CE-to-CE connection in both
directions. This document provides a mechanism to change the metric directions. This document provides a mechanism to change the metric
of the link on remote side and also use the link as a last-resort- of the link on remote side and also use the link as a last-resort-
link if no alternate paths are available. An application specific to link if no alternate paths are available. An application specific to
this use case is described in detail in Section 7.1. this use case is described in detail in Section 7.1.
The procedures described in this draft may be used to divert the
traffic away from the link in scenarios other than link-shutdown or
link-replacement activity.
This document provides mechanisms to advertise graceful-link-shutdown This document provides mechanisms to advertise graceful-link-shutdown
state in the flexible encodings provided by OSPFv2 Prefix/Link state in the flexible encodings provided by OSPFv2 Prefix/Link
Attribute Advertisement [RFC7684] and E-Router-LSA Attribute Advertisement [RFC7684] and E-Router-LSA
[I-D.ietf-ospf-ospfv3-lsa-extend] fr OSPFv3. Throughout this [I-D.ietf-ospf-ospfv3-lsa-extend] fr OSPFv3. Throughout this
document, OSPF is used when the text applies to both OSPFv2 and document, OSPF is used when the text applies to both OSPFv2 and
OSPFv3. OSPFv2 or OSPFv3 is used when the text is specific to one OSPFv3. OSPFv2 or OSPFv3 is used when the text is specific to one
version of the OSPF protocol. version of the OSPF protocol.
2. Motivation 2. Motivation
skipping to change at page 5, line 40 skipping to change at page 5, line 22
| Remote IPv4 address | | Remote IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Remote IPv4 Address Sub-TLV Figure 2: Remote IPv4 Address Sub-TLV
Type : TBA (suggested value 8) Type : TBA (suggested value 8)
Length: 4 Length: 4
Value: Remote IPv4 address. The remote IPv4 address is used to Value: Remote IPv4 address. The remote IPv4 address is used to
identify the particular link on remote side when there are multiple identify a particular link on the remote side when there are multiple
parallel links between two nodes. parallel links between two nodes.
4.3. Local/Remote Interface ID Sub-TLV 4.3. Local/Remote Interface ID Sub-TLV
This sub-TLV specifies local and remote interface identifiers. It is This sub-TLV specifies local and remote interface identifiers. It is
advertised in the Extended Link TLV as defined in [RFC7684]. This advertised in the Extended Link TLV as defined in [RFC7684]. This
sub-TLV is optional and MAY be advertised in an area-scoped Extended sub-TLV is optional and MAY be advertised in an area-scoped Extended
Link Opaque LSA to identify the link when there are multiple parallel Link Opaque LSA to identify the link when there are multiple parallel
unnumbered links between two nodes. The local interface-id is unnumbered links between two nodes. The local interface-id is
generally readily available. One of the mechanisms to obtain remote generally readily available. One of the mechanisms to obtain remote
skipping to change at page 7, line 21 skipping to change at page 6, line 47
Figure 4: Graceful-Link-Shutdown sub-TLV for OSPFv3 Figure 4: Graceful-Link-Shutdown sub-TLV for OSPFv3
Type : TBA (Suggested value 7) Type : TBA (Suggested value 7)
Length: 0 Length: 0
4.5. BGP-LS Graceful-Link-Shutdown TLV 4.5. BGP-LS Graceful-Link-Shutdown TLV
BGP-LS as defined in [RFC7752] is a mechanism to distribute network BGP-LS as defined in [RFC7752] is a mechanism to distribute network
information to the external entities using BGP routing protocol. information to the external entities using BGP routing protocol.
Graceful-link-shutdown is an imporatant link information that the Graceful-link-shutdown is an important link information that the
external entities can use for various use cases as defined in external entities can use for various use cases as defined in
Section 7. BGP Link NLRI is used to carry the link information. A Section 7. BGP Link NLRI is used to carry the link information. A
new TLV called Graceful-Link-Shutdown is defined to describe the link new TLV called Graceful-Link-Shutdown is defined to describe the link
attribute corresponding to graceful-link-shutdown state. The TLV attribute corresponding to graceful-link-shutdown state. The TLV
format is as described in [RFC7752] sec 3.1. There is no value field format is as described in [RFC7752] sec 3.1. There is no value field
and length field is set to zero for this TLV. and length field is set to zero for this TLV.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 8 skipping to change at page 8, line 33
[RFC7684] for OSPFv2 and Router-Link TLV of E-Router-LSA for OSPFv3. [RFC7684] for OSPFv2 and Router-Link TLV of E-Router-LSA for OSPFv3.
The Graceful-Link-Shutdown sub-TLV indicates that the link identified The Graceful-Link-Shutdown sub-TLV indicates that the link identified
by the sub-TLV is subjected to maintenance. by the sub-TLV is subjected to maintenance.
For the purposes of changing the metric OSPFv2 and OSPFv3 Router-LSAs For the purposes of changing the metric OSPFv2 and OSPFv3 Router-LSAs
need to be re-orignated and for Traffic Engineering metric, TE Opaque need to be re-orignated and for Traffic Engineering metric, TE Opaque
LSAs [RFC3630] in OSPFv2 and Intra-area-TE-LSA [RFC5329]in OSPFv3 LSAs [RFC3630] in OSPFv2 and Intra-area-TE-LSA [RFC5329]in OSPFv3
need to be re-originated. need to be re-originated.
The Graceful-Link-Shutdown information is advertised as a property of The Graceful-Link-Shutdown information is advertised as a property of
the link and is flooded across the area. This information can be the link and is flooded through the area. This information can be
used by ingress routers or controllers to take special actions. An used by ingress routers or controllers to take special actions. An
application specific to this use case is described in Section 7.2. application specific to this use case is described in Section 7.2.
When a link is ready to carry traffic, the Graceful-Lnk-Shutdown sub-
TLV MUST be removed from the Extended Link TLV/Router-Link TLV and
the corresponding LSAs MUST be readvertised. Similarly, metric MUST
be set to original values and corresponding LSAs MUST be
readvertised.
The procedures described in this draft may be used to divert the
traffic away from the link in scenarios other than link-shutdown or
link-replacement activity.
The precise action taken by the remote node at the other end of the The precise action taken by the remote node at the other end of the
link identified for graceful-shutdown depends on the link type. link identified for graceful-shutdown depends on the link type.
When a link is ready to carry traffic, the Graceful-Lnk-Shutdown sub-
TLV should be removed from the Extended Link TLV/Router-Link TLV and
the corresponding LSAs MUST be readvertised.
5.1. Point-to-point links 5.1. Point-to-point links
The node that has the link to be taken out of service MUST set metric The node that has the link to be taken out of service MUST set metric
of the link to MaxLinkMetric (0xffff) and re-originate its router- of the link to MaxLinkMetric (0xffff) and re-originate its router-
LSA. The Traffic Engineering metric of the link SHOULD be set to LSA. The Traffic Engineering metric of the link SHOULD be set to
(0xffffffff) and the node SHOULD re-originate the corresponding TE (0xffffffff) and the node SHOULD re-originate the corresponding TE
Link Opaque LSAs. When a Graceful-Link-Shutdown sub-TLV is received Link Opaque LSAs. When a Graceful-Link-Shutdown sub-TLV is received
for a point-to-point link, the remote node MUST identify the local for a point-to-point link, the remote node MUST identify the local
link which corresponds to the graceful-shutdown link and set its link which corresponds to the graceful-shutdown link and set its
metric to MaxLinkMetric (0xffff) and the remote node MUST re- metric to MaxLinkMetric (0xffff) and the remote node MUST re-
originate its router-LSA with the changed metric. When TE is originate its router-LSA with the changed metric. When TE is
enabled, the Traffic Engineering metric of the link SHOULD be set to enabled, the Traffic Engineering metric of the link SHOULD be set to
(0xffffffff) and the TE opaque LSA for the link SHOULD be re- (0xffffffff) and follow procedures of [RFC5817]. Similarly, the
originated with new value.Similarly, the remote node SHOULD set the remote node SHOULD set the Traffic Engineering metric of the link to
Traffic Engineering metric of the link to 0xffffffff and SHOULD re- 0xffffffff and SHOULD re-originate the TE Link Opaque LSA for the
originate the TE Link Opaque LSA for the link with the new value. link with the new value.
The Extended link opaque LSAs and the Extended link TLV are not The Extended link opaque LSAs and the Extended link TLV are not
scoped for multi-topology [RFC4915]. In multi-topology deployments scoped for multi-topology [RFC4915]. In multi-topology deployments
[RFC4915], the Graceful-Link-Shutdown sub-TLV advertised in an [RFC4915], the Graceful-Link-Shutdown sub-TLV advertised in an
Extended Link opaque LSA corresponds to all the topologies which Extended Link opaque LSA corresponds to all the topologies which
include the link. The receiver node SHOULD change the metric in the include the link. The receiver node SHOULD change the metric in the
reverse direction for all the topologies which include the remote reverse direction for all the topologies which include the remote
link and re-originate the router-LSA as defined in [RFC4915]. link and re-originate the router-LSA as defined in [RFC4915].
When the originator of the Graceful-Link-Shutdown sub-TLV purges the When the originator of the Graceful-Link-Shutdown sub-TLV purges the
skipping to change at page 10, line 41 skipping to change at page 10, line 23
Operation for the point-to-multipoint links is similar to the point- Operation for the point-to-multipoint links is similar to the point-
to-point links. When a Graceful-Link-Shutdown sub-TLV is received to-point links. When a Graceful-Link-Shutdown sub-TLV is received
for a point-to-multipoint link the remote node MUST identify the for a point-to-multipoint link the remote node MUST identify the
neighbour which corresponds to the graceful-shutdown link and set its neighbour which corresponds to the graceful-shutdown link and set its
metric to MaxLinkMetric (0xffff). The remote node MUST re-originate metric to MaxLinkMetric (0xffff). The remote node MUST re-originate
the router-LSA with the changed metric for the correponding neighbor. the router-LSA with the changed metric for the correponding neighbor.
5.4. Unnumbered interfaces 5.4. Unnumbered interfaces
Unnumbered interface do not have a unique IP address and borrow their Unnumbered interfaces do not have a unique IP address and borrow
address from other interfaces. [RFC2328] describes procedures to their address from other interfaces. [RFC2328] describes procedures
handle unnumbered interfaces in the context of the router-LSA. We to handle unnumbered interfaces in the context of the router-LSA. We
apply a similar procedure to the Extended Link TLV advertising the apply a similar procedure to the Extended Link TLV advertising the
Graceful-Link-Shutdown sub-TLV in order to handle unnumbered Graceful-Link-Shutdown sub-TLV in order to handle unnumbered
interfaces. The link-data field in the Extended Link TLV includes interfaces. The link-data field in the Extended Link TLV includes
the Local interface-id instead of the IP address. The Local/Remote the Local interface-id instead of the IP address. The Local/Remote
Interface ID sub-TLV MUST be advertised when there are multiple Interface ID sub-TLV MUST be advertised when there are multiple
parallel unnumbered interfaces between two nodes. One of the parallel unnumbered interfaces between two nodes. One of the
mechanisms to obtain the interface-id of the remote side are defined mechanisms to obtain the interface-id of the remote side is defined
in [RFC4203]. in [RFC4203].
5.5. Hybrid Broadcast and P2MP interfaces 5.5. Hybrid Broadcast and P2MP interfaces
Hybrid Broadcast and P2MP interfaces represent a broadcast network Hybrid Broadcast and P2MP interfaces represent a broadcast network
modeled as P2MP interfaces. [RFC6845] describes procedures to handle modeled as P2MP interfaces. [RFC6845] describes procedures to handle
these interfaces. Operation for the Hybrid interfaces is similar to these interfaces. Operation for the Hybrid interfaces is similar to
the P2MP interfaces. When a Graceful-Link-Shutdown sub-TLV is the P2MP interfaces. When a Graceful-Link-Shutdown sub-TLV is
received for a hybrid link, the remote node MUST identify the received for a hybrid link, the remote node MUST identify the
neighbor which corresponds to the graceful-shutdown link and set its neighbor which corresponds to the graceful-shutdown link and set its
skipping to change at page 11, line 31 skipping to change at page 11, line 13
Link-Shutdown sub-TLV as well as the node at the remote end of the Link-Shutdown sub-TLV as well as the node at the remote end of the
graceful-shutdown link support the extensions described herein for graceful-shutdown link support the extensions described herein for
the traffic to diverted from the graceful-shutdown link. If the the traffic to diverted from the graceful-shutdown link. If the
remote node doesn't support the capability, it will still use the remote node doesn't support the capability, it will still use the
graceful-shutdown link but there are no other adverse effects. In graceful-shutdown link but there are no other adverse effects. In
the case of broadcast links using two-part metrics, the backward the case of broadcast links using two-part metrics, the backward
compatibility procedures as described in [RFC8042] are applicable. compatibility procedures as described in [RFC8042] are applicable.
7. Applications 7. Applications
7.1. Pseudowire Services 7.1. Overlay Network
Many service providers offer pseudo-wire services to customers using Many service providers offer L2 services to a customer connecting
L2 circuits. The IGP protocol that runs in the customer network different locations. The customer's IGP protocol creates a seamless
would also run over the pseudo-wire to create a seamless private private network (overlay network) across the locations for the
network for the customer. Service providers want to offer graceful- customer. Service providers want to offer graceful-shutdown
shutdown functionality when the PE device is taken-out for functionality when the PE device is taken-out for maintenance. There
maintenance. The provider should guarantee that the PE is taken out can be large number of customers attached to a PE node and the remote
for maintenance, only after the service is successfully diverted on end-points for these L2 attachments circuits are spread across the
an alternate path. There can be large number of customers attached service provider's network. It is a tedious and error-prone process
to a PE node and the remote end-points for these pseudo-wires are to change the metric for all corresponding L2 circuits in both
spread across the service provider's network. It is a tedious and
error-prone process to change the metric for all pseudo-wires in both
directions. The graceful-link-shutdown feature simplifies the directions. The graceful-link-shutdown feature simplifies the
process by increasing the metric on the link in the reverse direction process by increasing the metric on the CE-CE overlay link so that
as well so that traffic in both directions is diverted away from the traffic in both directions is diverted away from the PE undergoing
PE undergoing maintenance. The Graceful-Link-Shutdown feature allows maintenance. The Graceful-Link-Shutdown feature allows the link to
the link to be used as a last resort link so that traffic is not be used as a last resort link so that traffic is not disrupted when
disrupted when alternate paths are not available. alternate paths are not available.
overlay network ------PE3---------------PE4------CE3
======================================= / \
| | / \
| |
| ------PE3---------------PE4------CE3
| / \
| / \
CE1---------PE1----------PE2---------CE2 CE1---------PE1----------PE2---------CE2
| \ \
| \ \
| ------CE4 ------CE4
| |
| |
| |
=================================
overlay network
Figure 7: Pseudowire Services Figure 7: Overlay Network
In the example shown in Figure 7, when the PE1 node is going out of In the example shown in Figure 7, when the PE1 node is going out of
service for maintenance, service providers set the PE1 to stub-router service for maintenance, a service provider sets the PE1 to stub-
state. The PE1 going in to maintenance state triggers all the CEs router state and communicates the pending maintenance action to the
connected to the PE (CE1 in this case) to set their pseudowire links overlay customer networks. The mechanisms used to communicate
passing via PE1 to graceful-link-shutdown state. The mechanisms used between PE1 and CE1 is outside the scope of this document. CE1 sets
to communicate between PE1 and CE1 is outside the scope of this the graceful-link-shutdown state on its links connecting CE3, CE2 and
document. CE1 sets the graceful-link-shutdown state on its links CE4 and changes the metric to MaxLinkMetric and re-originates the
connecting CE3, CE2 and CE4 and changes the metric to MaxLinkMetric corresponding LSA. The remote end of the link at CE3, CE2, and CE4
and re-originates the corresponding LSA. The remote end of the link also set the metric on the link to MaxLinkMetric and the traffic from
at CE3, CE2, and CE4 also set the metric on the link to MaxLinkMetric both directions gets diverted away from PE1.
and the traffic from both directions gets diverted away from the
pseudowires.
7.2. Controller based Traffic Engineering Deployments 7.2. Controller based Deployments
In controller-based deployments where the controller participates in In controller-based deployments where the controller participates in
the IGP protocol, the controller can also receive the graceful-link- the IGP protocol, the controller can also receive the graceful-link-
shutdown information as a warning that link maintenance is imminent. shutdown information as a warning that link maintenance is imminent.
Using this information, the controller can find alternate paths for Using this information, the controller can find alternate paths for
traffic which uses the affected link. The controller can apply traffic which uses the affected link. The controller can apply
various policies and re-route the LSPs away from the link undergoing various policies and re-route the LSPs away from the link undergoing
maintenance. If there are no alternate paths satisfying the traffic maintenance. If there are no alternate paths satisfying the
engineering constraints, the controller might temporarily relax those constraints, the controller might temporarily relax those constraints
constraints and put the service on a different path. Increasing the and put the service on a different path. Increasing the link metric
link metric alone does not specify the maintenance activity as the alone does not specify the maintenance activity as the metric could
metric could increase in events such as LDP-IGP synchronisation. An increase in events such as LDP-IGP synchronisation. An explicit
explicit indication from the router using the graceful-link-shutdown indication from the router using the graceful-link-shutdown sub-TLV
sub-TLV is needed to inform the Controller or head-end routers. is needed to inform the Controller or head-end routers.
_____________ _____________
| | | |
-------------| Controller |-------------- -------------| Controller |--------------
| |____________ | | | |____________ | |
| | | |
|--------- Primary Path ------------------| |--------- Primary Path ------------------|
PE1---------P1----------------P2---------PE2 PE1---------P1----------------P2---------PE2
| | | |
| | | |
skipping to change at page 15, line 4 skipping to change at page 14, line 21
BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and
Attribute TLVs [RFC7752] Attribute TLVs [RFC7752]
i)Graceful-Link-Shutdown TLV - Suggested 1121 i)Graceful-Link-Shutdown TLV - Suggested 1121
10. Acknowledgements 10. Acknowledgements
Thanks to Chris Bowers for valuable inputs and edits to the document. Thanks to Chris Bowers for valuable inputs and edits to the document.
Thanks to Jeffrey Zhang, Acee Lindem and Ketan Talaulikar for inputs. Thanks to Jeffrey Zhang, Acee Lindem and Ketan Talaulikar for inputs.
Thanks to Karsten Thomann for careful review and inputs on the Thanks to Karsten Thomann for careful review and inputs on the
applications where graceful-link-shutdown is useful. applications where graceful-link-shutdown is useful.
Thanks to Alia atlas, Deborah Brungard, Alvaro Retana and Tim Chown Thanks to Alia Atlas, Deborah Brungard, Alvaro Retana, Andrew G.
for valuable inputs. Malis and Tim Chown for valuable inputs.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-ospf-ospfv3-lsa-extend] [I-D.ietf-ospf-ospfv3-lsa-extend]
Lindem, A., Roy, A., Goethals, D., Vallem, V., and F. Lindem, A., Roy, A., Goethals, D., Vallem, V., and F.
Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3- Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3-
lsa-extend-23 (work in progress), January 2018. lsa-extend-23 (work in progress), January 2018.
skipping to change at page 15, line 43 skipping to change at page 15, line 14
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
"Traffic Engineering Extensions to OSPF Version 3", "Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, DOI 10.17487/RFC5329, September 2008, RFC 5329, DOI 10.17487/RFC5329, September 2008,
<https://www.rfc-editor.org/info/rfc5329>. <https://www.rfc-editor.org/info/rfc5329>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>. <https://www.rfc-editor.org/info/rfc5340>.
[RFC5817] Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton,
"Graceful Shutdown in MPLS and Generalized MPLS Traffic
Engineering Networks", RFC 5817, DOI 10.17487/RFC5817,
April 2010, <https://www.rfc-editor.org/info/rfc5817>.
[RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast
and Point-to-Multipoint Interface Type", RFC 6845, and Point-to-Multipoint Interface Type", RFC 6845,
DOI 10.17487/RFC6845, January 2013, DOI 10.17487/RFC6845, January 2013,
<https://www.rfc-editor.org/info/rfc6845>. <https://www.rfc-editor.org/info/rfc6845>.
[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D.
McPherson, "OSPF Stub Router Advertisement", RFC 6987, McPherson, "OSPF Stub Router Advertisement", RFC 6987,
DOI 10.17487/RFC6987, September 2013, DOI 10.17487/RFC6987, September 2013,
<https://www.rfc-editor.org/info/rfc6987>. <https://www.rfc-editor.org/info/rfc6987>.
skipping to change at page 16, line 41 skipping to change at page 16, line 19
[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the
Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Provider/Customer Edge Protocol for BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577,
June 2006, <https://www.rfc-editor.org/info/rfc4577>. June 2006, <https://www.rfc-editor.org/info/rfc4577>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007, RFC 4915, DOI 10.17487/RFC4915, June 2007,
<https://www.rfc-editor.org/info/rfc4915>. <https://www.rfc-editor.org/info/rfc4915>.
[RFC5817] Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton,
"Graceful Shutdown in MPLS and Generalized MPLS Traffic
Engineering Networks", RFC 5817, DOI 10.17487/RFC5817,
April 2010, <https://www.rfc-editor.org/info/rfc5817>.
Authors' Addresses Authors' Addresses
Shraddha Hegde Shraddha Hegde
Juniper Networks, Inc. Juniper Networks, Inc.
Embassy Business Park Embassy Business Park
Bangalore, KA 560093 Bangalore, KA 560093
India India
Email: shraddha@juniper.net Email: shraddha@juniper.net
Pushpasis Sarkar Pushpasis Sarkar
Arrcus, Inc. Arrcus, Inc.
 End of changes. 36 change blocks. 
111 lines changed or deleted 91 lines changed or added

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