メインコンテンツまでスキップ

1. Introduction

この節では Unreachable Prefix Announcement (UPA) の RFC 原文を保持し, IS-IS and OSPF signaling, U-Flag and UP-Flag semantics, propagation rules, IANA assignments, security considerations を含めます.

1.  Introduction

Link-state Interior Gateway Protocols (IGPs) like Intermediate System
to Intermediate System (IS-IS) [ISO10589], Open Shortest Path First
version 2 (OSPFv2)) [RFC2328], and Open Shortest Path First version 3
(OSPFv3) [RFC5340] are primarily used to distribute routing
information between routers belonging to a single Autonomous System
(AS) and to calculate the reachability for IPv4 or IPv6 prefixes
advertised by the individual nodes inside the AS. Each node
advertises the state of its local adjacencies, connected prefixes,
capabilities, etc. The collection of these states from all the
routers inside the area form a Link State Database (LSDB) that
describes the topology of the area and holds additional state
information about the prefixes, router capabilities, etc.

The growth of networks running a link-state routing protocol results
in the addition of more state, which leads to scalability and
convergence challenges. The organization of networks into levels/
areas and IGP domains helps limit the scope of link-state information
within certain boundaries. However, the state related to prefix
reachability often requires propagation across a multi-area/level
and/or multi-domain IGP network. IGP summarization is a network
engineering technique for combining multiple smaller, contiguous IP
networks into a single, larger summary route. Techniques such as
summarization have been used to address the scaling challenges
associated with advertising prefix state outside of the local area/
domain. However, this results in suppression of the individual
prefix state that is useful for triggering fast-convergence
mechanisms outside of the IGPs -- e.g., Border Gateway Protocol (BGP)
Prefix-Independent Convergence (PIC) [BGP-PIC].

Similarly, when a router needs to be taken out of service for
maintenance, the traffic is drained from the node before taking it
down. This is typically achieved by setting the OVERLOAD bit
together with using a high metric for all prefixes advertised by the
node in IS-IS. The mechanisms available for that purpose are (in
OSPFv2) using the cost of MaxLinkMetric for all non-stub links in the
router-LSA [RFC6987] or using the H-bit [RFC8770], or (in OSPFv3
[RFC5340]) using the R-bit.

When prefixes from such nodes are summarized by an Area Border Router
(ABR) or Autonomous System Boundary Router (ASBR), nodes outside of
the area or domain are unaware of these summarized prefixes becoming
unreachable. This document proposes protocol extensions to carry
information about such prefixes in a backward-compatible manner.

This document does not define how to advertise a prefix that is not
reachable for routing. That has been defined for IS-IS in [RFC5305]
and [RFC5308], for OSPFv2 in [RFC2328], and for OSPFv3 in [RFC5340].

This document defines a method to signal a specific reason for which
the prefix was advertised with the metric that excludes it from the
route calculation. This is done to distinguish it from any other
possible cases, where such metric advertisement may be used.

IGPs typically only advertise the reachability of the prefix. A
prefix that was previously advertised as reachable is made
unreachable just by withdrawing the previous advertisement of the
prefix. Some of the use cases mentioned earlier in this section
require that unreachability be signaled for a prefix for which the
reachability was not explicitly signaled previously, because it was
covered by the reachability of the summary prefix.

This document defines two new flags in IS-IS, OSPFv2, and OSPFv3.
These flags provide the support for advertising prefix
unreachability, together with the reason for which the unreachability
is advertised. The functionality being described is called
Unreachable Prefix Announcement (UPA).

This document also defines how the UPA is propagated across IS-IS
levels and OSPF areas.

The term "OSPF" in this document is used to cover both OSPFv2 and
OSPFv3 protocols.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.