[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03

LSR Working Group                                                A. Wang
Internet-Draft                                             China Telecom
Intended status: Standards Track                                   Z. Hu
Expires: April 26, 2020                              Huawei Technologies
                                                        October 24, 2019


       Prefix Unreachable Announcement for SRv6 Fast Convergence
            draft-wang-lsr-prefix-unreachable-annoucement-00

Abstract

   This document describes the mechanism that can be used to announce
   the unreachable prefixes for SRv6 fast 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 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 April 26, 2020.

Copyright Notice

   Copyright (c) 2019 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 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.





Wang & Hu                Expires April 26, 2020                 [Page 1]


Internet-Draft                     PUA                      October 2019


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   2
   3.  Scenario Description  . . . . . . . . . . . . . . . . . . . .   3
   4.  Inter-area prefix unreachable solution  . . . . . . . . . . .   3
   5.  Intra-area prefix unreachable solution  . . . . . . . . . . .   4
   6.  Implementation Consideration  . . . . . . . . . . . . . . . .   4
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   9.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   5
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   OSPF and IS-IS have the summary route and default route mechanism on
   area border router or L1L2 border router, which can be used to
   increase the scalability of these IGP protocols.  Such summary
   mechanism can also reduce the SPF calculation time when the link
   oscillation occurs in another area.

   The summary route and the default route may cover the host route or
   link prefixes of intra area or inter area.  But in some situations,
   the router needs to know the exact reachability information about
   prefix in other area, especially when the prefix is unreachable but
   it is located within the summary range.

   With the introduction of SRv6, more and more services are migrated
   from the MPLS data plane to the IPv6 data plane.  The biggest
   difference between IPv6 and MPLS is that IPv6 has aggregation
   ability, so we need to reconsider how to know the prefix reachability
   in the case of aggregation.

   This document introduces the mechanism that can be used in such
   situation, to announce the unreachable prefixes which are located in
   the summary address range.

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








Wang & Hu                Expires April 26, 2020                 [Page 2]


Internet-Draft                     PUA                      October 2019


3.  Scenario Description

   Figure1 illustrates the topology scenario when OSPF is running in
   multi-area.  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.  Ps2 is the host address of
   S2 and Pt2 is the host address T2.

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

   Figure1: OSPF Inter-Area Prefix Unreachable Announcement Scenario

   If the area border router R1/R3 and R2/R4 does the summary action,
   then one summary address that cover the prefixes of area 0, area 1
   and area 2 will be announced to area 1 and area 2, instead of the
   detail address.  When the node S2 is down, Ps2 become unreachable.
   But there will be no change to the summary prefix.  Except the border
   router R1/R3, the other routers within area 0 and area 2 do not know
   the unreachable status of this prefix.  When these routers send
   traffic to prefix Ps2, the traffic will be dropped.

   In another situation, assume the BGP session is built between Node S2
   and T2, via Ps2 and Pt2 respectively.  If Node S2 within area 1
   become unreachable, the unreachable information can't be advertised
   to Node T2 because the summary behaviour on border router R1/R3.  The
   BGP session between S1 and T2 will be kept until the BGP keepalive
   timeout or other detection mechanism takes effect.  During this
   period, the BGP traffic to Node S2 will be in black hole.

4.  Inter-area prefix unreachable solution

   [RFC7794] and [I-D.ietf-lsr-ospf-prefix-originator] both define one
   sub-TLV "Prefix Source Router ID" to announce the originator router
   information of one prefix.  This TLV can be used to announce the
   prefix unreachable information when the link or node is down.



Wang & Hu                Expires April 26, 2020                 [Page 3]


Internet-Draft                     PUA                      October 2019


   According to the procedure described in section 5 of
   [I-D.ietf-lsr-ospf-prefix-originator], the ABR has the responsibility
   to add the prefix originator information when it receive the type 1
   LSA from other routers in the same area.  When the ABR does the
   summary work and receives one updated LSA that omits the prefix
   belong to failed link which is within the range of summary address,
   the ABR should announce one new type 3 LSA, which includes the
   information about this prefix, but with the prefix originator set to
   NULL(all 0 address).

   When one node in one area is down, the ABR has also the ability to
   detect the missing neighbor from the neighbor list.  It should then
   announce one new type 3 LSA that includes the loopback addresses of
   this node, with the prefix originator set also to NULL(all 0
   address).

   For IS-IS, the above procedure is similar.  The level-1/2 router will
   accomplish the above work when it judges that one prefix within the
   summary address range is missing.

   These LSA will be transported via the traditional flooding procedure.

   When the routers in other area receives such LSA, they will generate
   automatically one black-hole route, with the prefix as the
   destination, and the next hop be set to Null.

5.  Intra-area prefix unreachable solution

   In the intra-area scenario, like S1 illustrated in Figure 1, it will
   learn two types of prefixes, one is summary route, another is host
   route.  When node S2 is down, S2 will withdraw the host route.  But
   S1 can still match the summary route via the longest mask matching.
   For this scenario, when node S2 is down, S1 needs to keep the S2 host
   route for a period of time but updates S2 host route to black hole
   route.  S1 will match the black hole route via the longest mask
   matching.  Such mechanism can be used to trigger a SRv6 VPN for PE
   switching, or SRv6 TE mid-point protection.

   The period for keeping the black hole route should be configured, to
   ensure the related protocols or services be converged.

6.  Implementation Consideration

   The above procedures will only be triggered under the following
   conditions:

   1.  The ABR or Level 1/2 router do the summary work.




Wang & Hu                Expires April 26, 2020                 [Page 4]


Internet-Draft                     PUA                      October 2019


   2.  The link prefix within the summary address range become
   unreachable.

   3.  The node whose loopback address is within the summary address
   become unreachable.

   The Summary LSA that includes the unreachable prefix, with the prefix
   originator set to NULL value, will be announced across the ABR
   router, reach the routers in other areas.  It's behavior is still the
   same as that defined in OSPFv2 [RFC2328] or OSPFv3 [RFC5340]

7.  Security Considerations

   Security concerns for OSPF are addressed in [RFC5709]

   Advertisement of the additional information defined in this document
   introduces no new security concerns

8.  IANA Considerations

   TBD

9.  Acknowledgement

   TBD

10.  Normative References

   [I-D.ietf-lsr-ospf-prefix-originator]
              Wang, A., Lindem, A., Dong, J., Psenak, P., and K.
              Talaulikar, "OSPF Prefix Originator Extension", draft-
              ietf-lsr-ospf-prefix-originator-04 (work in progress),
              September 2019.

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

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
              <https://www.rfc-editor.org/info/rfc5340>.





Wang & Hu                Expires April 26, 2020                 [Page 5]


Internet-Draft                     PUA                      October 2019


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

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

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 & Hu                Expires April 26, 2020                 [Page 6]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/