Open Shortest Path First IGP S. Hegde
Internet-Draft Juniper Networks, Inc.
Intended status: Standards Track P. Sarkar
Expires: August 22, 2017 H. Gredler
M. Nanduri
Microsoft Corporation
L. Jalil
February 18, 2017

OSPF Link Overload


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 metric to the highest metric on one side of the link is not sufficient to divert the traffic flowing in the other direction.

It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be able to advertise a link being in an overload state to indicate impending maintenance activity on the link. This information can be used by the network devices to re-route the traffic effectively.

This document describes the protocol extensions to disseminate link-overload information in OSPFv2 and OSPFv3.

Requirements Language

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].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

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."

This Internet-Draft will expire on August 22, 2017.

Copyright Notice

Copyright (c) 2017 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 Provisions Relating to IETF Documents ( 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

When a node is being prepared for a planned maintenance or upgrade, [RFC6987] provides mechanisms to advertise the node being in an overload state by setting all outgoing link costs to MAX-METRIC (0xffff). These procedures are specific to the maintenance activity on a node and cannot be used when a single link attached to the node requires maintenance.

In traffic-engineering deployments, LSPs need to be diverted from the link without disrupting the services. 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 by means of pseudo-wires or L2-circuits. Prior to devices in the underlying network going offline for maintenance, it is useful to divert the traffic away from the node before the maintenance is actually scheduled. Since the nodes in the underlying network are not visible to OSPF, the existing stub router mechanism described in [RFC6987] cannot be used. An application specific to this use case is described in Section 7.1

This document provides mechanisms to advertise link-overload state in the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement([RFC7684]) and RI LSA ([RFC7770]). Throughout this 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 version of the OSPF protocol.

2. Motivation

The motivation of this document is to reduce manual intervention during maintenance activities. The following objectives help to accomplish this in a range of deployment scenarios.

  1. Advertise impending maintenance activity so that traffic from both directions can be diverted away from the link.
  2. Allow the solution to be backward compatible so that nodes that do not understand the new advertisement do not cause routing loops.
  3. Advertise the maintenance activity to other nodes in the network so that LSP ingress routers/controllers can learn of the impending maintenance activity and apply specific policies to re-route the LSPs for traffic-engineering based deployments.
  4. Allow the link to be used as last resort link to prevent traffic disruption when alternate paths are not available.

3. Flooding Scope

The link-overload information can be flooded in area scoped extended link LSA [RFC7684] or a link scoped RI LSA [RFC7770] or both based on the needs of the application. Section 7 describes applications requiring area scope as well as link scope link-overload information.

3.1. Area scope flooding

For OSPFv2, Link-Overload sub-TLV is carried in the extended Link TLV as defined in [RFC7684].

3.2. Link scope flooding

The link local scope RI LSA MAY carry the Link-Overload sub-TLV as defined in Section 4. The link local scope RI-LSA corresponds to the link on which the LSA arrives and there is no need to explicitly specify the remote IPv4 address. The remote IPv4 address field MAY be zero when the Link-Overload sub-TLV is carried in the link local RI LSA. The Link-Overload sub-TLV MAY appear in any instance of the link local RI-LSA. The Link-Overload sub-TLV is carried in the RI-LSA for both OSPFv2 and OSPFv3.

4. Link-Overload sub-TLV

4.1. OSPFv2 Link-overload sub-TLV