Internet-Draft PUAM July 2022
Wang, et al. Expires 12 January 2023 [Page]
LSR Working Group
Intended Status:
Standards Track
A. Wang
China Telecom
G. Mishra
Verizon Inc.
Z. Hu
Huawei Technologies
Y. Xiao
Huawei Technologies

Prefix Unreachable Announcement


This document describes a mechanism that can trigger the switchover of the services which rely on the reachability of the peer endpoints, for example the BGP or the tunnel services. It is mainly used in the scenarios that the summary prefixes are advertised at the border routers whereas the services endpoints are located in different IGP areas or levels, whose reachabilities are covered by the summary prefixes.

It introduces a new signaling mechanism using a negative prefix announcement called Prefix Unreachable Announcement Mechanism(PUAM), utilized to detect a link or node down event and signal the overlay services that the event has occurred to force immediate switchover.

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 12 January 2023.

Table of Contents

1. Introduction

As part of an operator optimized design, a critical requirement is to limit Shortest Path First (SPF) churn which occurs within a single OSPF area or IS-IS level. This is accomplished by sub-dividing the IGP domain into multiple areas for flood reduction of intra area prefixes so they are contained within each discrete area to avoid domain wide flooding.

OSPF and IS-IS have a default and summary route mechanism which is performed on the OSPF area border router or IS-IS L1-L2 node. The summary route is triggered to be advertised conditionally when at least one component prefix exists within the attached area or Level.

Operators have historically relied on MPLS architecture which is based on exact match host route for single area. LDP inter-area extension [RFC5283] provides the ability to LPM(Longest Prefix Match), so now it can be a summary match of a host route of the egress PE for an inter-area LSP to be instantiated.

SRV6 routing framework utilities the IPv6 data plane standard IGP LPM, such summarization will influence the forwarding of traffic when a link or node failure event occurs for a component prefix within the summary range, result in black hole routing of traffic.

The motivation behind this draft is for either MPLS LPM FEC binding, SRv6 etc. tunnel ,or BGP overlay service that are using LPM forwarding plane where the IGP domain has been carved up into OSPF areas or IS-IS levels and summarization is utilized. In such scenario, a link or node failure can result in a black hole of traffic when the summary advertisement that covers the failure prefixes still exists.

PUAM can track the unreachabilities of the important component prefixes to ensure traffic is not black hole sink routed for the above overlay services.

2. Conventions used in this document

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

3. Scenario Description

Figure 1 illustrates the topology scenario when OSPF or IS-IS is running in multi areas or levels. R0-R4 are routers in backbone area, S1-S4,T1-T4 are internal routers in area 1 and area 2 respectively. R1 and R3 are area border routers or IS-IS Level 1-2 border nodes between area 0 and area 1. R2 and R4 are area border routers between area 0 and area 2.

S1/S4 and T2/T4 PEs peer to customer CEs for overlay VPNs. Ps1/Ps4 is the loopback0 address of S1/S4 and Pt2/Pt4 is the loopback0 address of T2/T4.

 | +--+        +--+   ++-+   ++-+    +-++   + -+        +--+|
 | |S1+--------+S2+---+R1+---|R0+----+R2+---+T1+--------+T2||
 | +-++Ps1     +-++   ++-+   +--+    +-++   ++++    Pt2 +-++|
 |   |           |     |               |     ||           | |
 |   |           |     |               |     ||           | |
 | +-++Ps4     +-++   ++-+           +-++   ++++     Pt4+-++|
 | |S4+--------+S3+---+R3+-----------+R4+---+T3+--------+T4||
 | +--+        +--+   ++-+           +-++   ++-+        +--+|
 |                     |               |                    |
 |                     |               |                    |
 |         Area 1      |     Area 0    |      Area 2        |

Figure 1: OSPF Inter-Area Prefix Unreachable Announcement Scenario

3.1. Inter-Area Node Failure Scenario

If the area border router R2/R4 does the summary action, then one summary address that cover the prefixes of area 2 will be announced to area 0 and area 1, instead of the detail address.

When the node T2 is down, Pt2 becomes unreachable while the summary prefix continues to be advertised into the backbone area. Except the border router R2/R4, the other routers within area 0 and area 1 do not know the unreachable status of the Pt2 prefix. Traffic will continue to forward LPM match to prefix Pt2 and will be dropped on the ABR or Level 1-2 border node, resulting in black hole routing and connectivity loss. Even the customer overlay VPN are dual homed to both S1/S4 and T2/R4, traffic will not be able to fail-over to alternate egress PE T4 due to the summarization.

4. PUAM (Prefix Unreachable Advertisement Mechanism) Procedures

[RFC7794] and [RFC9084] define sub-TLV to announce the originator information of the one prefix from a specified node. This draft utilizes such sub-TLV for OSPF and IS-IS to signal the negative prefix in the perspective PUAM when a link or node goes down.

When ABR or IS-IS L1-L2 border node detects link or node down, the ABR will announce one new summary LSA or LSP which includes the information about the down prefix, with the prefix originator sub-TLV set to NULL( The LSA or LSP will be propagated with standard flooding procedures.

If the nodes in the area receive the PUAM message from all of its ABR routers, they will start overlay services switchover process if such services rely on the prefix within PUAM message. Without the PUAM forced switchover, the summary prefix will yield black hole routing and loss of connectivity.

When only some of the ABRs can't reach the failure node/link, as that described in Section 3.2, the ABR that can reach the PUAM prefix should advertise one specific route to this PUAM prefix. The internal routers within another area can then bypass the ABRs that can't reach the PUAM prefix, to reach the PUAM prefix.

5. PUAM Capabilities Announcement

When not all of the nodes in one area support the PUAM information, there are possibilities the nodes misbehavior when they don't support the received PUAM message.

To avoid this happen, the ABR should know the capabilities of each node within one area via the newly defined capabilities bits, and advertise PUAM message with some additional information when necessary.

For OSPFv2, this bit (Bit number TBD, suggest bit 6, 0x20) should be carried in "OSPF Router-LSA Option", as that described in [RFC2328].

For OSPFv3, one bit (Bit number TBD, suggest bit 8) should be defined to indicate the router's capabilities to support PUAM that described in this draft, the defined bit should be carried in "OSPF Router Informational Capabilities" TLV, which is described in [RFC7770].

For IS-IS, one new sub-TLV(Type TBD, suggest 29), PUAM Capabilities sub-TLV, which is included in the "IS-IS Router CAPABILITY TLV" [RFC7981] is defined in the followings:

   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
   |   Type        |     Length    |            Flags              |
   Type: TBD, Suggested value 29, to be assigned by IANA
   Length: 2
   Flags: 2 octets
   The following flags are defined:
           0                   1
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
           |P|                             |
      P-flag: If set, the router supports PUAM information.

   Figure 2: PUAM Capabilities sub-TLV format

If not all of nodes within one area support the PUAM capabilities, the PUAM message should be advertised with the associated prefix cost set to LSInfinity. According to the description in [RFC2328], [RFC5305] and [RFC5308], the prefix advertised with such metric value will not be considered during the normal SPF computation, then such additional information will avoid the misbehavior of the nodes when they don't recognize the PUAM message.

If all of nodes within one area support the PUAM capabilites, the PUAM message can be safely advertised without the additional LSInfinity metric information.

6. Implementation Consideration

Considering the balances of reachable information and unreachable information announcement capabilities, the implementation of this mechanism should set one MAX_Address_Announcement (MAA) threshold value that can be configurable. Then, the ABR should make the following decisions to announce the prefixes:

1. If the number of unreachable prefixes is less than MAA, the ABR should advertise the summary address and the PUAM.

2. If the number of reachable address is less than MAA, the ABR should advertise the detail reachable address only.

3. If the number of reachable prefixes and unreachable prefixes exceed MAA, then advertise the MAA unreachable prefixes, and also the summary address with MAX(LSInfiity-1) metric. At the same time, the ABR should notify the operators there are severe incident occurs within the network.

7. Deployment Considerations

To support the PUAM advertisement, the ABRs should be upgraded according to the procedures described in Section 4. The nodes that want to accomplish the services switchover should also be upgraded to act upon the receive of the PUAM message. Other nodes within the network can ignore such PUAM message if they don't care or don't support it.

As described in Section 4, the ABR will advertise the PUAM message once it detects there is link or node down within the summary address. In order to reduce the unnecessary advertisements of PUAM messages on ABRs, the ABRs should support the configuration of the tracked prefixes. Based on such information, the ABR will only advertise the PUAM message when the tracked prefixes(for example, the loopback addresses of PEs that run BGP) that within the summary address is missing.

The advertisement of PUAM message should only last one configurable period to allow the services that run on the failure prefixes are switchovered. If one prefix is missed before the PUAM takes effect, the ABR will not declare its absence via the PUAM.

8. Security Considerations

Advertisement of PUAM information follow the same procedure of traditional LSA. The action based on the PUAM is depended on the overlay services and is out of the scope of this document.

There is no changes to the forward behavior of other internal routers.

9. IANA Considerations

IANA is requested to register the following in the "OSPF Router Properties Registry" and "OSPF Router Informational Capability Bits Registry" respectively.

   | Bit Number | Capability Name  |  Reference  |
   | TBD(0x20)  | OSPF PUAM Support|this document|
   Table 1: P-Bit in OSPFv2 Router-LSA Option

   | Bit Number | Capability Name  |  Reference  |
   | TBD(bit 8) | OSPF PUAM Support|this document|
  Table 2: OSPFv3 Router PUAM Capability Support Bit

   IANA is requested to register the following in "Sub-TLVs for

   Type: 29 (Suggested - to be assigned by IANA)

   Description: PUAM Support Capabilities

10. Acknowledgement

Thanks Peter Psenak, Les Ginsberg, Bruno Decraene, Acee Lindem, Shraddha Hegde, Robert Raszuk, Tony Li, Jeff Tantsura and Tony Przygienda for their suggestions and comments on this draft.

11. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, , <>.
Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension for Inter-Area Label Switched Paths (LSPs)", RFC 5283, DOI 10.17487/RFC5283, , <>.
Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix Distribution with Two-Level IS-IS", RFC 5302, DOI 10.17487/RFC5302, , <>.
Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, , <>.
Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, , <>.
Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, , <>.
Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, DOI 10.17487/RFC5709, , <>.
Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, , <>.
Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, , <>.
Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, , <>.
Wang, A., Lindem, A., Dong, J., Psenak, P., and K. Talaulikar, Ed., "OSPF Prefix Originator Extensions", RFC 9084, DOI 10.17487/RFC9084, , <>.

Authors' Addresses

Aijun Wang
China Telecom
Beiqijia Town, Changping District
Gyan Mishra
Verizon Inc.
Zhibo Hu
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Yaqun Xiao
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.