Internet DRAFT - draft-wang-lsr-prefix-unreachable-annoucement

draft-wang-lsr-prefix-unreachable-annoucement







LSR Working Group                                                A. Wang
Internet-Draft                                             China Telecom
Intended status: Standards Track                                   Z. Hu
Expires: 22 December 2023                            Huawei Technologies
                                                                  J. Sun
                                                         ZTE Corporation
                                                                  C. Lin
                                                    New H3C Technologies
                                                            20 June 2023


                    Prefix Unreachable Announcement
            draft-wang-lsr-prefix-unreachable-annoucement-12

Abstract

   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 communication endpoint is unreachabe to force the
   overlay service headend switchover immediately.

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 https://datatracker.ietf.org/drafts/current/.

   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 22 December 2023.





Wang, et al.            Expires 22 December 2023                [Page 1]

Internet-Draft                    PUAM                         June 2023


Copyright Notice

   Copyright (c) 2023 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 (https://trustee.ietf.org/
   license-info) 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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised 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.  PUAM Capabilities Announcement  . . . . . . . . . . . . . . .   5
   6.  Implementation Consideration  . . . . . . . . . . . . . . . .   6
   7.  Deployment Considerations . . . . . . . . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   8
   11. Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

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.






Wang, et al.            Expires 22 December 2023                [Page 2]

Internet-Draft                    PUAM                         June 2023


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











Wang, et al.            Expires 22 December 2023                [Page 3]

Internet-Draft                    PUAM                         June 2023


     +---------------------+------+--------+-----+--------------+
     | +--+        +--+   ++-+   ++-+    +-++   + -+        +--+|
     | |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 via LPM match to prefix Pt2 and will be dropped
   on the ABR 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.

3.2.  Inter-Area Links Failure Scenario

   In a link failure scenario, if the links 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 prefix of
   Pt2, other nodes in area 0 and area 1 will still send traffic to T2
   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) being
   selected as the next hop to reach prefix Pt2.








Wang, et al.            Expires 22 December 2023                [Page 4]

Internet-Draft                    PUAM                         June 2023


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 OSPF ABR or IS-IS L1-L2 border node detects link or node down,
   the ABR should announce one new summary LSA or LSP which includes the
   information about the down prefix, with the prefix originator sub-TLV
   set to NULL(0.0.0.0).  The LSA or LSP will be propagated with
   standard flooding procedures.

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

   When only some of the ABRs can't reach the failure node/link, as that
   described in Section 3.2, along with the PUAM message for the
   associated prefixe from these ABRs, the ABR that can reach the PUAM
   prefix should advertise the specific route to this prefix.  The
   internal routers within another area can then bypass the ABRs that
   can't reach the PUAM prefix, to reach the prefix that advertised in
   PUAM message.

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





Wang, et al.            Expires 22 December 2023                [Page 5]

Internet-Draft                    PUAM                         June 2023


   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|                             |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      where:
         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 announcements, 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.



Wang, et al.            Expires 22 December 2023                [Page 6]

Internet-Draft                    PUAM                         June 2023


   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.






Wang, et al.            Expires 22 December 2023                [Page 7]

Internet-Draft                    PUAM                         June 2023


         +------------+------------------+-------------+
         | 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

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998,
              <https://www.rfc-editor.org/info/rfc2328>.

   [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,
              <https://www.rfc-editor.org/info/rfc5283>.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, DOI 10.17487/RFC5305, October
              2008, <https://www.rfc-editor.org/info/rfc5305>.





Wang, et al.            Expires 22 December 2023                [Page 8]

Internet-Draft                    PUAM                         June 2023


   [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
              DOI 10.17487/RFC5308, October 2008,
              <https://www.rfc-editor.org/info/rfc5308>.

   [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, <https://www.rfc-editor.org/info/rfc7770>.

   [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, <https://www.rfc-editor.org/info/rfc7794>.

   [RFC7981]  Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
              for Advertising Router Information", RFC 7981,
              DOI 10.17487/RFC7981, October 2016,
              <https://www.rfc-editor.org/info/rfc7981>.

   [RFC9084]  Wang, A., Lindem, A., Dong, J., Psenak, P., and K.
              Talaulikar, Ed., "OSPF Prefix Originator Extensions",
              RFC 9084, DOI 10.17487/RFC9084, August 2021,
              <https://www.rfc-editor.org/info/rfc9084>.

Authors' Addresses

   Aijun Wang
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   102209
   China
   Email: wangaj3@chinatelecom.cn


   Zhibo Hu
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing
   100095
   China
   Email: huzhibo@huawei.com









Wang, et al.            Expires 22 December 2023                [Page 9]

Internet-Draft                    PUAM                         June 2023


   Jinsong
   ZTE Corporation
   No. 68, Ziijnhua Road
   Nanjing
   210012
   China
   Email: sun.jinsong@zte.com.cn


   Changwang
   New H3C Technologies
   Beijing
   China
   Email: linchangwang.04414@h3c.com





































Wang, et al.            Expires 22 December 2023               [Page 10]