Skip to main content

Route Redistribution Credibility ID for Avoiding Routing Loop
draft-wang-lsr-redistribution-credibility-id-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author WANG QIANG
Last updated 2023-03-02
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-wang-lsr-redistribution-credibility-id-00
Network Working Group                                            Q. Wang
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                            2 March 2023
Expires: 3 September 2023

     Route Redistribution Credibility ID for Avoiding Routing Loop
            draft-wang-lsr-redistribution-credibility-id-00

Abstract

   The route redistribution is often deployed in current network between
   two different protocols domain or instance/process, such as the ISIS
   domain redistribute to OSPF domain, the OSPF domain redistribute to
   BGP domain, IS-IS redistribute to another IS-IS instance/process and
   so on.  The existing network have more complex multiple IGP domains
   architecture.  Therefore, bidirectional route redistribution
   deployment is more complex for different protocols or instances/
   processes to learn routes from each other.  In recent years, these
   route redistributions have had many routing loops cases that cause
   network incident.

   This document proposes a simplified method to positively avoid
   routing loop, and introduces new sub-TLVs to support advertisement
   IPv4 and IPv6 prefix extended attribute as Redistribution Credibility
   ID, while redistributing route from one protocol domain or instance/
   process to another.

Requirements Language

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

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

Wang                    Expires 3 September 2023                [Page 1]
Internet-Draft              Abbreviated-Title                 March 2023

   This Internet-Draft will expire on 3 September 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Route Redistribution Credibility ID . . . . . . . . . . . . .   3
     3.1.  IS-IS Redistribution Credibility ID Sub-TLV . . . . . . .   3
     3.2.  OSPF Redistribution Credibility ID Sub-TLV  . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   Due to network scope, architecture or network management requirement,
   many existing network have multiple different IGP protocol domains,
   including multiple routing protocol and multiple routing instance/
   process with same protocol.  These IGP domains boundary routers need
   to deploy bidirectional route redistribution to learn routing prefix
   information for each other.  Because of reliability design
   consideration, these route redistribution configuration have been
   deployed at least two routers, or even more boundary routers between
   these adjacent IGP domain.

   However, there is no routing loop prevention mechanism in multiple
   routing protocol domain or instance/process scenario.  As traditional
   method, these redistribution routers must be configured complex route
   control policies, using IP prefix, cost and preference/
   administrative distance (AD) and etc., to avoid routing loops and
   nonoptimal routing problems.

Wang                    Expires 3 September 2023                [Page 2]
Internet-Draft              Abbreviated-Title                 March 2023

   As the network scale grows and irregular distribution, these multiple
   Route Redistribution node configuration become more and more
   difficult to control.  Maybe any network change have to adjust these
   route redistribution configuration.  The manually configured routing
   policy adjustment mode have more complex and high risky that cannot
   meet the requirements of the current network.  As a result, many
   serious network loop accidents occur and service traffic had been
   affected.  A simple and low-cost Layer 3 routing loop prevention
   solution is urgently needed.

2.  Terminology

   IS-IS: Intermediate System to Intermediate System

   OSPF: Open Shortest Path First

   TTR: Times-to-Redistribution

   Cred route-type: Credibility route-type

3.  Route Redistribution Credibility ID

   This document defines a new Route Redistribution Credibility ID sub-
   TLV to solve the Layer 3 routing loop problem.  The Route
   Redistribution Credibility ID indicates the Route Credit Rating when
   this routing prefix has been propagated across multiple routing
   protocol domain or instance/process.  The Route Redistribution
   Credibility ID is automatically attenuated when the routing prefix
   cross redistribution node.  If a route is redistributed more times,
   this route’s risk probability of routing loop is higher and its
   Credibility is lower.

3.1.  IS-IS Redistribution Credibility ID Sub-TLV

   This section describes the Route Redistribution Credibility ID Sub-
   TLV for IS-IS.

      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      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Redistribution Credibility ID                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Figure 1: IS-IS Route Redistribution Credibility ID Sub-TLV

   where:

Wang                    Expires 3 September 2023                [Page 3]
Internet-Draft              Abbreviated-Title                 March 2023

   Type: TBD

   Length: (1 octet), the length value is 4 octets

   Redistribution Credibility ID: (4 octets), it has the following
   Field:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      TTR      |Cred route-type|           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Figure 2: Route Redistribution Credibility ID Field

   where:

   TTR: Times-to-Redistribution (called TTR, 1 octet), it indicates the
   number of redistribution times, the value from 0 to 255 is used as
   quantity of routing domain (means different routing protocol domain
   or instance/process) to be traveled across from the routing prefix
   original node to this route redistribution node.  For example, each
   time the route is redistributed, the Times-to-Redistribution (called
   TTR) value decreases by 1, the route with greater Times-to-
   Redistribution (called TTR) value can be preferred.  This indicate
   that the route is more closed to the route original node.  When the
   Times-to-Redistribution (called TTR) value is 0, it indicate the
   route is not trusted.

   Cred route-type: Credibility route-type (called Cred route-type, 1
   octet), it indicate that the route is internal or external Cred route
   type according to network administration scope.  For the routing
   prefix with same Times-to-Redistribution(called TTR) value scenario,
   the internal Cred route-type that network administration scope
   identification is the same as local, can be preferred rather than
   external Cred route-type with different identification.  The network
   administration scope is specified according to the network layer of
   logical architecture.  The different routing domains (means different
   routing protocol domain or instance/process) may have a same network
   administration scope identification, or may have different network
   administration scope identification.

3.2.  OSPF Redistribution Credibility ID Sub-TLV

   TBD

Wang                    Expires 3 September 2023                [Page 4]
Internet-Draft              Abbreviated-Title                 March 2023

4.  IANA Considerations

   This document requests that IANA allocates new IS-IS Route
   Redistribution Credibility ID sub-TLV types from the IS-IS "Sub-TLVs
   for TLVs 27, 135, 235, 236 and 237)" registry as specified.

+=========+===============================================+===============+
|  Value  |                   Description                 |  reference    |
+====================================+======+=============================+
|   TBD   | IS-IS Redistribution Credibility ID Sub-TLV   | This document |
+---------+-----------------------------------------------+---------------+
       Figure 3: IANA Allocation for newly defined Sub-TLVs

5.  Security Considerations

   This document introduces the Route Redistribution Credibility ID, The
   feature introduces the advertisement of avoiding routing Loop
   capability information to all routers in routing domain.  This
   information can be confirmed for discovery and verification that all
   routers in the routing domain support the capability before the
   feature is turned on.  Advertisement of the information defined in
   this document introduces no new security concerns.

6.  Acknowledgements

   The author would like to thank people for their comments on this
   work.

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

Author's Address

   Qiang Wang
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing,
   100095
   China
   Email: wangqiang88@huawei.com

Wang                    Expires 3 September 2023                [Page 5]