Internet-Draft | Loop detection for imported routes | September 2022 |
Yue, et al. | Expires 27 March 2023 | [Page] |
Mutual route import between two IGP instances is often involved in networking solutions. However, routing loops may occur when route are imported to an instance from another and cause critical problem. This document provides a way to detect routing loop and introduces new sub-TLVs to support advertisement IPv4 and IPv6 prefix extended attribute flags and the source router ID of the router which import the route and redistribute the route.¶
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 27 March 2023.¶
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 (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.¶
As dynamic routing protocols, IS-IS and OSPF are widely used on live networks. Mutual route import between two IGP instances is often involved in networking solutions. However, restricted routing policy need to be configred on the router, otherwise, routing loops may occur and cause critical problem.¶
When a route is imported to an IGP instance, if the IGP instance can recognize the route has already been redistributed by itself and notice that there might be routing loops in the network, the router can take some actions to avoid or fix futher potential routing problems.¶
Therefore, new sub-TLVs are introduced to support advertisement IPv4 and IPv6 prefix extended attribute flags and the source router ID of the router which has redistributed the prefix.¶
When a routing prefix is imported to an IGP instance and redistributed by the instance to other IGP areas, the router ID of this IGP instance will be added to the redistribute list of the prefix and advertised in IGP areas.¶
The following sections describe how the redistribute list for a route prefix is advertised in IGP areas.¶
This document registers a new IS-IS sub-TLV in the "Sub-TLVs for TLVs 135, 235, 236 and 237" registry. This new sub-TLV provides ways to advertise IPv4 and IPv6 prefix extended attribute flags and the router ID of the router which redistributed the prefix.¶
Type: 10¶
Length: 1 + Router-ID length.¶
Flags: 1 octet. The following flags are defined:¶
where:¶
S-flag: If set, the prefix has be redistributed by the router that generate the current LSP.¶
R-flag: If set, the prefix has be redistributed by the router other than the router that generate current LSP.¶
Router ID: 6 octets. IS-IS System-ID as defined in [ISO10589].¶
This sub-TLV is optional.¶
If the sub-Tlv length is equal to one, R-flag MUST be treated as if it is set to 0 on receipt. Undefined bits that are transmitted MUST be transmitted as 0 and MUST be ignored on receipt.¶
TBD.¶
Implementations MUST make it possible to enable or disable the sub-TLV based on configuration.¶
TBD.¶
This document requests that IANA allocates new sub-TLV types from the IS-IS "Sub-TLVs for TLVs 135, 235, 236 and 237)" registry as specified.¶
These extensions to IS-IS do not add any new security issues to the existing IGP.¶