LSR Working Group                                                A. Wang
Internet-Draft                                             China Telecom
Intended status: Standards Track                               G. Mishra
Expires: December 9, 2022                                   Verizon Inc.
                                                                   Z. Hu
                                                                 Y. Xiao
                                                     Huawei Technologies
                                                            June 7, 2022

                    Prefix Unreachable Announcement


   This document describes a mechanism to solve an existing issue with
   Longest Prefix Match (LPM), that exists where an operator domain is
   divided into multiple areas or levels where summarization is
   utilized.  This draft addresses a fail-over issue related to a multi
   areas or levels domain, where a link or node down event occurs
   resulting in an LPM component prefix being omitted from the FIB
   resulting in black hole sink of routing and connectivity loss.  This
   draft introduces a new control plane convergence signaling mechanism
   using a negative prefix called Prefix Unreachable Announcement
   Mechanism(PUAM), utilized to detect a link or node down event and
   signal the RIB that the event has occurred to force immediate control
   plane convergence.

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 December 9, 2022.

Wang, et al.            Expires December 9, 2022                [Page 1]

Internet-Draft                    PUAM                         June 2022

Copyright Notice

   Copyright (c) 2022 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Scenario Description  . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Inter-Area Node Failure Scenario  . . . . . . . . . . . .   4
     3.2.  Inter-Area Links Failure Scenario . . . . . . . . . . . .   4
   4.  PUAM (Prefix Unreachable Advertisement Mechanism) Procedures    5
   5.  MPLS and SRv6 LPM based BGP Next-hop Failure Application  . .   5
   6.  PUAM Capabilities Announcement  . . . . . . . . . . . . . . .   6
   7.  Implementation Consideration  . . . . . . . . . . . . . . . .   7
   8.  Deployment Considerations . . . . . . . . . . . . . . . . . .   7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   9
   12. Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   As part of an operator optimized design criteria, a critical
   requirement is to limit Shortest Path First (SPF) churn which occurs
   within a single OSPF area or ISIS 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 ISIS have a default and summary route mechanism which is
   performed on the OSPF area border router or ISIS L1-L2 node.  The
   OSPF summary route is triggered to be advertised conditionally when
   at least one component prefix exists within the non-zero area.  ISIS
   Level-L1-L2 node as well generate a summary prefix into the level-2
   backbone area for Level 1 area prefixes that is triggered to be

Wang, et al.            Expires December 9, 2022                [Page 2]

Internet-Draft                    PUAM                         June 2022

   advertised conditionally when at least a single component prefix
   exists within the Level-1 area.  ISIS L1-L2 node with attach bit set
   also generates a default route into each Level-1 area along with
   summary prefixes generated for other Level-1 areas.

   Operators have historically relied on MPLS architecture which is
   based on exact match host route FEC binding for single area.
   [RFC5283] LDP inter-area extension provides the ability to LPM, so
   now the RIB match can now be a summary match and not an exact 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.  When operators start to migrate from MPLS LSP
   based host route bootstrapped FEC binding, to SRv6 routing framework,
   the IGP LPM now comes into play with summarization which will
   influence the forwarding of traffic when a link or node event occurs
   for a component prefix within the summary range resulting in black
   hole routing of traffic.

   The motivation behind this draft is based on either MPLS LPM FEC
   binding, or SRv6 BGP service overlay using traditional unicast
   routing (uRIB) LPM forwarding plane where the IGP domain has been
   carved up into OSPF or ISIS areas and summarization is utilized.  In
   this scenario where a failure conditions result in a black hole of
   traffic where multiple ABRs exist and either the area is partitioned
   or other link or node failures occur resulting in the component
   prefix host route missing within the summary range.  Summarization of
   inter-area types routes propagated into the backbone area for flood
   reduction are made up of component prefixes.  It is these component
   prefixes that the PUAM tracks to ensure traffic is not black hole
   sink routed due to a PE or ABR failure.  PUAM ensures immediate
   control plane convergence with ABR or PE node switchover when area is
   partitioned or ABR has services down to avoid black hole of traffic.

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119] .

3.  Scenario Description

   Figure 1 illustrates the topology scenario when OSPF or ISIS is
   running in multi areas or multi levels domain.  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 ISIS Level 1-2
   border nodes between area 0 and area 1.  R2 and R4 are area border
   routers between area 0 and area 2.

Wang, et al.            Expires December 9, 2022                [Page 3]

Internet-Draft                    PUAM                         June 2022

   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 bgp next hop becomes unreachable while the LPM
   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 bgp next hop
   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.  Customer overlay VPN dual
   homed to both S1/S4 and T2/R4, traffic will not be able to fail-over
   to alternate egress PE T4 bgp next hop Pt4 due to the summarization.

3.2.  Inter-Area Links Failure Scenario

   In a link failure scenario, if the link between T1/T2 and T1/T3 are
   down, R2 will not be able to reach node T2.  But as R2 and R4 do the
   summary announcement, and the summary address covers the bgp next hop
   prefix of Pt2, other nodes in area 0 area 1 will still send traffic
   to T2 bgp next hop prefix Pt2 via the border router R2, thus black
   hole sink routing the traffic.

   In such a situation, the border router R2 should notify other routers
   that it can't reach the prefix Pt2, and lets the other ABRs(R4) that
   can reach prefix Pt2 advertise one specific route to Pt2, then the

Wang, et al.            Expires December 9, 2022                [Page 4]

Internet-Draft                    PUAM                         June 2022

   internal routers will select R4 as the bypass router to reach prefix

4.  PUAM (Prefix Unreachable Advertisement Mechanism) Procedures

   [RFC7794] and [I-D.ietf-lsr-ospf-prefix-originator] draft both define
   one sub-tlv to announce the originator information of the one prefix
   from a specified node.  This draft utilizes such TLV for both OSPF
   and ISIS to signal the negative prefix in the perspective PUAM when a
   link or node goes down.

   ABR detects link or node down and floods PUAM negative prefix
   advertisement along with the summary advertisement according to the
   prefix-originator specification.  The ABR or ISIS L1-L2 border node
   has the responsibility to add the prefix originator information when
   it receives the Router LSA from other routers in the same area or

   When the ABR or ISIS L1-L2 border node generates the summary
   advertisement based on component prefixes, the ABR will announce one
   new summary LSA or LSP which includes the information about this down
   prefix, with the prefix originator set to NULL.  The number of PUAMs
   is equivalent to the number of links down or nodes down.  The LSA or
   LSP will be propagated with standard flooding procedures.

   If the nodes in the area receive the PUAM flood from all of its ABR
   routers, they will start BGP convergence process if there exist BGP
   session on this PUAM prefix.  The PUAM creates a forced fail over
   action to initiate immediate control plane convergence switchover to
   alternate egress PE.  Without the PUAM forced convergence the down
   prefix will yield black hole routing resulting in loss of

   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.  MPLS and SRv6 LPM based BGP Next-hop Failure Application

   In an MPLS or SR-MPLS service provider core, scalability has been a
   concern for operators which have split up the IGP domain into
   multiple areas to avoid SPF churn.  Normally, MPLS FEC binding for
   LSP instantiation is based on egress PE exact match of a host route
   Looback0.  [RFC5283] LDP inter-area extension provides the ability to
   LPM, so now the RIB match can now be a summary match and not an exact
   match of host route of the egress PE for an inter-area LSP to be

Wang, et al.            Expires December 9, 2022                [Page 5]

Internet-Draft                    PUAM                         June 2022

   instantiated.  The caveat related to this feature that has prevented
   operators from using the [RFC5283] LDP inter-area extension concept
   is that when the component prefixes are now hidden in the summary
   prefix, and thus the visibility of the BGP next-hop attribute is

   In a case where a PE is down, and the [RFC5283] LDP inter-area
   extension LPM summary is used to build the LSP inter-area, the LSP
   remains partially established black hole on the ABR performing the
   summarization.  This major gap with [RFC5283] inter-area extension
   forces operators into a workaround of having to flood the BGP next-
   hop domain wide.  In a small network this is fine, however if you
   have 1000s PEs and many areas, the domain wide flooding can be
   painful for operators as far as resource usage memory consumption and
   computational requirements for RIB / FIB / LFIB label binding control
   plane state.  The ramifications of domain wide flooding of host
   routes is described in detail in [RFC5302] domain wide prefix
   distribution with 2 level ISIS Section 1.2 - Scalability.  As SRv6
   utilizes LPM, this problem exists as well with SRv6 when IGP domain
   is broken up into areas and summarization is utilized.

   PUAM is now able to provide the negative prefix component flooded
   across the backbone to the other areas along with the summary prefix,
   which is now immediately programmed into the RIB control plane.  MPLS
   LSP exact match or SRv6 LPM match over fail over path can now be
   established to the alternate egress PE.  No disruption in traffic or
   loss of connectivity results from PUAM.  Further optimizations such
   as LFA and BFD can be done to make the data plane convergence
   hitless.  The PUAM solution applies to MPLS or SR-MPLS where LDP
   inter-area extension is utilized for LPM aggregate FEC, as well a
   SRv6 IPv6 control plane LPM match summarization of BGP next hop.

6.  PUAM Capabilities Announcement

   When not all of the nodes in one area support the PUAM information,
   there are possibilities to form traffic loop.  To avoid this happen,
   the ABR should not send PUAM information to one area until it ensures
   that all of nodes in this area can parse the PUAM information.  To
   accomplish this, this draft defines the capabilities sub-TLV as the

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

Wang, et al.            Expires December 9, 2022                [Page 6]

Internet-Draft                    PUAM                         June 2022

   For ISIS, 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

7.  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 summary address with MAX metric.

8.  Deployment Considerations

   To support the PUAM advertisement, the ABRs should be upgraded
   according to the procedures described in Section 4.  The PEs that
   want to accomplish the BGP switchover that described in Section 3.1
   and Section 5 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.

Wang, et al.            Expires December 9, 2022                [Page 7]

Internet-Draft                    PUAM                         June 2022

   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
   protected prefixes.  Based on such information, the ABR will only
   advertise the PUAM message when the protected 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
   converged or switchover.  If one prefix is missed before the PUAM
   takes effect, the ABR will not declare its absence via the PUAM.

9.  Security Considerations

   Advertisement of PUAM information follow the same procedure of
   traditional LSA.  The action based on the PUAM is clearly defined in
   this document for ABR or Level1/2 router and the receiver that run

   There is no changes to the forward behavior of other internal

10.  IANA Considerations

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

Wang, et al.            Expires December 9, 2022                [Page 8]

Internet-Draft                    PUAM                         June 2022

         | 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
         TLV242(IS-IS Router CAPABILITY TLV)

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

         Description: PUAM Support Capabilities

11.  Acknowledgement

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

12.  Normative References

              Wang, A., Lindem, A., Dong, J., Psenak, P., and K.
              Talaulikar, "OSPF Prefix Originator Extensions", draft-
              ietf-lsr-ospf-prefix-originator-12 (work in progress),
              April 2021.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998,

   [RFC5283]  Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension
              for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
              DOI 10.17487/RFC5283, July 2008,

Wang, et al.            Expires December 9, 2022                [Page 9]

Internet-Draft                    PUAM                         June 2022

   [RFC5302]  Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix
              Distribution with Two-Level IS-IS", RFC 5302,
              DOI 10.17487/RFC5302, October 2008,

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,

   [RFC5709]  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, October
              2009, <>.

   [RFC7770]  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,
              February 2016, <>.

   [RFC7794]  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,
              March 2016, <>.

   [RFC7981]  Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
              for Advertising Router Information", RFC 7981,
              DOI 10.17487/RFC7981, October 2016,

Authors' Addresses

   Aijun Wang
   China Telecom
   Beiqijia Town, Changping District
   Beijing  102209


   Gyan Mishra
   Verizon Inc.


Wang, et al.            Expires December 9, 2022               [Page 10]

Internet-Draft                    PUAM                         June 2022

   Zhibo Hu
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095


   Yaqun Xiao
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095


Wang, et al.            Expires December 9, 2022               [Page 11]