Internet DRAFT - draft-litkowski-isis-ip-route-preference-issue
draft-litkowski-isis-ip-route-preference-issue
ISIS Working Group S. Litkowski
Internet-Draft Orange Business Service
Intended status: Informational June 27, 2014
Expires: December 29, 2014
IP Route preference specification issue
draft-litkowski-isis-ip-route-preference-issue-00
Abstract
This document details a potential specification issue in IP route
preference in ISIS. As a consequence, some implementations does not
interoperate correctly and leads to routing loops. Authors tries to
analyse if we need to fix current specification.
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 [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 http://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 December 29, 2014.
Copyright Notice
Copyright (c) 2014 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Litkowski Expires December 29, 2014 [Page 1]
Internet-Draft isis-route-pref-pb June 2014
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. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification analysis . . . . . . . . . . . . . . . . . . . 3
3. IPv6 and MT extensions cases . . . . . . . . . . . . . . . . 4
4. Enhancing the RFC5305 . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Problem statement
L2 L2 L2 L2|L2 L2
10/8 - R0 ----- R1 ----- R2 ----- R3 ----- R4 ---- 10/8
|
Figure 1
Considering the figure 1, both R0 and R4 are advertising the prefix
10/8. Two ISIS L2 process are running on R3 to separate network. R3
is performing route-leaking and advertise prefix from R4 to the other
L2 process. The network is using extended metrics (TLV135 defined in
[RFC5305]). Considering that R0 is advertising 10/8 with metric 2000
and R3 with metric 100, and all the links have a metric of 1. When
advertising route in L2, R3 set the down bit, according to [RFC5305].
During interoperability testings, authors observed some routing loops
in this scenario.
R1, R2 and R3 are from three different vendors (R1->Vendor1,
R2->Vendor2, R3->Vendor3).
o R2 has two possible paths to reach 10/8, L2 up route with metric
2002 (from R0), and L2 down route with metric 101 (from R3). R2
selects R1 as nexthop to 10/8 because it is an Up route.
o R3 has two possible paths to reach 10/8, L2 up route with metric
2002 from R1, L2 up metric 101 from R4. R3 selects R4 as nexthop
due to lowest metric.
Litkowski Expires December 29, 2014 [Page 2]
Internet-Draft isis-route-pref-pb June 2014
o R1 has two possible paths to reach 10/8, L2 up route with metric
2001 from R0, L2 down metric 102 from R2. R1 selects R2 as
nexthop due to lowest metric.
When R1 or R2 try to send traffic to 10/8, packets are looping due to
inconsistent routing decision between R1 and R2.
2. Specification analysis
[RFC5305] defines IP extended reachability (TLV135), it also defines
the notion of "Up/Down bit" that did not exist in [RFC1195] :
"The existing IP reachability TLVs (TLV type 128 and TLV type 130,
defined in [RFC1195]) carry IP prefixes in a format that is analogous
to the IS neighbor TLV from ISO 10589 [ISO-10589]. They carry four
metrics, of which only the default metric is commonly used. The
default metric has a possible range of 0-63. We would like to remove
this restriction.
In addition, route redistribution (a.k.a. route leaking) has a key
problem that was not fully addressed by the existing IP reachability
TLVs. [RFC1195] allows a router to advertise prefixes upwards in the
level hierarchy. Unfortunately, there were no mechanisms defined to
advertise prefixes downwards in the level hierarchy.
To address these two issues, the proposed extended IP reachability
TLV provides for a 32-bit metric and adds one bit to indicate that a
prefix has been redistributed 'down' in the hierarchy."
[RFC5305] does not provide any rule for taking into account up/down
bit in route preference.
[RFC5302] replaces [RFC2966] and defines extension to support optimal
routing in multi-level environment. It especially defines up/down
bit for IP prefix semantics defined in [RFC1195] (aka TLV
128,TLV130). Section 3.2 of [RFC5302] clearly specifies the order of
preference between IP route types in ISIS.
Litkowski Expires December 29, 2014 [Page 3]
Internet-Draft isis-route-pref-pb June 2014
"Based on these assumptions, this document defines the following route
preferences.
1. L1 intra-area routes with internal metric; L1 external routes
with internal metric
2. L2 intra-area routes with internal metric; L2 external routes
with internal metric; L1->L2 inter-area routes with internal
metric; L1->L2 inter-area external routes with internal metric
3. L2->L1 inter-area routes with internal metric; L2->L1 inter-area
external routes with internal metric
4. L1 external routes with external metric
5. L2 external routes with external metric; L1->L2 inter-area
external routes with external metric
6. L2->L1 inter-area external routes with external metric"
It is quite clear that for IP Reachability defined in [RFC1195], up
routes are prefered over down routes. It sounds that [RFC5302] does
not apply to TLV defined in [RFC5305] : section 5 of [RFC5302]
describes [RFC5305] as another proposal to deal with the issues
described.
3. IPv6 and MT extensions cases
[RFC5308] defines IPv6 Reachability extension for ISIS (TLV 236).
Section 5 of the RFC clearly defines the order of preference between
route types :
"The order of preference between paths for a given prefix MUST be
modified to consider the up/down bit. The new order of preference is
as follows (from best to worst).
1. Level 1 up prefix
2. Level 2 up prefix
3. Level 2 down prefix
4. Level 1 down prefix
If multiple paths have the same best preference, then selection
occurs based on metric. Any remaining multiple paths SHOULD be
considered for equal-cost multi-path routing if the router supports
this; otherwise, the router can select any one of the multiple paths."
Litkowski Expires December 29, 2014 [Page 4]
Internet-Draft isis-route-pref-pb June 2014
[RFC5120] defines Multitopology extension for ISIS and new IPv4 and
IPv6 reachability TLVs (TLV 235 and 237). No guideline are provided
in this RFC for route type preference but as MT extensions are based
on basic TLVs (135 and 236), we expect the same behavior as for the
associated TLVs.
4. Enhancing the RFC5305
[RFC5305] lacks of text regarding order of route preference compared
to [RFC5308] and [RFC5302]. [RFC5302] does not seem to apply to
TLV135 defined in [RFC5305]. As [RFC5302] and [RFC5308] are already
aligned in term of behavior, authors propose to enhance [RFC5305]
with a clear text stating the route preference order with the same
behavior described in the two other specifications.
5. Security Considerations
There is no security consideration.
6. Acknowledgements
7. IANA Considerations
There is no IANA consideration.
8. Normative References
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix
Distribution with Two-Level IS-IS", RFC 2966, October
2000.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix
Distribution with Two-Level IS-IS", RFC 5302, October
2008.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008.
Litkowski Expires December 29, 2014 [Page 5]
Internet-Draft isis-route-pref-pb June 2014
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October
2008.
Author's Address
Stephane Litkowski
Orange Business Service
Email: stephane.litkowski@orange.com
Litkowski Expires December 29, 2014 [Page 6]
