Internet DRAFT - draft-ietf-isis-route-preference
draft-ietf-isis-route-preference
Networking Working Group L. Ginsberg
Internet-Draft Cisco Systems
Updates: 5308 (if approved) S. Litkowski
Intended status: Standards Track Orange Business Service
Expires: April 18, 2016 S. Previdi
Cisco Systems
October 16, 2015
IS-IS Route Preference for Extended IP and IPv6 Reachability
draft-ietf-isis-route-preference-02.txt
Abstract
Existing specifications as regards route preference are not explicit
when applied to IPv4/IPv6 Extended Reachability Type/Length/Value
(TLVs). There are also inconsistencies in the definition of how the
up/down bit applies to route preference when the prefix advertisement
appears in Level 2 Link State Protocol Data Units (LSPs). This
document addresses these issues.
This document, if approved, updates RFC 5308.
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 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 April 18, 2016.
Ginsberg, et al. Expires April 18, 2016 [Page 1]
Internet-Draft isis-route-preference October 2015
Copyright Notice
Copyright (c) 2015 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
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use of the up/down Bit in Level 2 LSPs . . . . . . . . . . . 3
3. Types of Routes in IS-IS Supported by Extended Reachability
TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Types of Routes Supported by TLVs 135 and 235 . . . . . . 4
3.2. Types of Routes Supported by TLVs 236 and 237 . . . . . . 5
3.3. Order of Preference for all types of routes supported by
TLVs 135 and 235 . . . . . . . . . . . . . . . . . . . . 7
3.4. Order of Preference for all types of routes supported by
TLVs 236 and 237 . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informational References . . . . . . . . . . . . . . . . 8
Appendix A. Example Interoperability Issue . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
Ginsberg, et al. Expires April 18, 2016 [Page 2]
Internet-Draft isis-route-preference October 2015
1. Introduction
[RFC5302] defines the route preferences rules as they apply to TLVs
128 and 130. [RFC5305] introduced the IP Extended Reachability TLV
135 but did not explicitly adapt the route preference rules defined
in [RFC5302] for the new TLV. [RFC5308] defines the IPv6
Reachability TLV 236 and does include an explicit statement as
regards route preference - but the statement introduces use of the
up/down bit in advertisements which appear in Level 2 LSPs which is
inconsistent with statements made in [RFC5302] and [RFC5305]. This
document defines explicit route preference rules for TLV 135, revises
the route preferences rules for TLV 236, and clarifies the usage of
the up/down bit when it appears in TLVs in Level 2 LSPs. This
document is viewed as a clarification (NOT correction) of [RFC5302]
and [RFC5305] and a correction of the route preference rules defined
in [RFC5308] to be consistent with the rules for IPv4. It also makes
explicit that the same rules apply for the Multi-Topology(MT)
equivalent TLVs 235 and 237.
2. Use of the up/down Bit in Level 2 LSPs
The up/down bit was introduced in support of leaking prefixes
downwards in the IS-IS level hierarchy. Routes which are leaked
downwards have the bit set to 1. Such prefixes MUST NOT be leaked
upwards in the hierarchy. So long as we confine ourselves to a
single IS-IS instance and the current number of supported levels
(two) it is impossible to have a prefix advertised in a Level 2 LSP
and have the up/down bit set to 1. However, because [RFC5302]
anticipated a future extension to IS-IS which might support
additional levels it allowed for the possibility that the up/down bit
might be set in a Level-2 LSP and in support of easier migration in
the event such an extension was introduced Section 3.3 stated:
"...it is RECOMMENDED that implementations ignore the up/down bit in
L2 LSPs, and accept the prefixes in L2 LSPs regardless of whether the
up/down bit is set."
[RFC5305] addressed an additional case wherein an implementation
included support for multiple virtual routers running IS-IS in
different areas. In such a case it is possible to redistribute
prefixes between two IS-IS instances in the same manner that prefixes
are redistributed from other protocols into IS-IS. This introduced
the possibility that a prefix could be redistributed from Level 1 to
Level 1 (as well as between Level 2 and Level 2) and in the event the
redistributed route was leaked from Level 1 to Level 2 two different
routers in different areas would be advertising the same prefix into
the Level 2 sub-domain. To prevent this [RFC5305] specified in
Section 4.1:
Ginsberg, et al. Expires April 18, 2016 [Page 3]
Internet-Draft isis-route-preference October 2015
"If a prefix is advertised from one area to another at the same
level, then the up/down bit SHALL be set to 1."
However, the statement in [RFC5302] that the up/down bit is ignored
in Level 2 LSPs is not altered by [RFC5305].
The conclusion then is that there is no "L2 inter-area route" - and
indeed no such route type is defined by [RFC5302]. However,
[RFC5308] ignored this fact and introduced such a route type in
Section 5 when it specified a preference for " Level 2 down prefix".
This is an error which this document corrects. As changing the use
of the up/down bit in TLVs 236 and 237 may introduce interoperability
issues implementors may wish to support transition mechanisms from
the [RFC5308] behavior to the behavior specified in this document.
3. Types of Routes in IS-IS Supported by Extended Reachability TLVs
[RFC5302] is the authoritative reference for the types of routes
supported by TLVs 128 and 130. However, a number of attributes
supported by those TLVs are NOT supported by TLVs 135, 235, 236, 237.
Distinction between internal/external metrics is not supported. In
the case of IPv4 TLVs (135 and 235) the distinction between internal
and external route types is not supported. However the Prefix
Attribute Flags sub-TLV defined in [PFXATTR] reintroduces the
distinction between internal and external route types. The
definitions below include references to the relevant attribute bits
from [PFXATTR].
3.1. Types of Routes Supported by TLVs 135 and 235
This section defines the types of route supported for IPv4 when using
TLV 135 [RFC5305] and/or TLV 235 [RFC5120]. The text follows as
closely as possible the original text from [RFC5302].
L1 intra-area routes: These are advertised in L1 LSPs, in TLV 135 or
TLV 235. The up/down bit is set to 0. These IP prefixes are
directly connected to the advertising router. If the Prefix
Attribute Flags sub-TLV is included both the X-Flag and the R-Flag
are set to 0.
L1 external routes: These are advertised in L1 LSPs, in TLV 135 or
TLV 235. The up/down bit is set to 0. These IP prefixes are learned
from other protocols and are usually not directly connected to the
advertising router. If the Prefix Attribute Flags sub-TLV is
included the X-Flag is set to 1 and the R-Flag is set to 0.
L2 intra-area routes: These are advertised in L2 LSPs, in TLV 135 or
TLV 235. The up/down bit is set to 0. These IP prefixes are
Ginsberg, et al. Expires April 18, 2016 [Page 4]
Internet-Draft isis-route-preference October 2015
directly connected to the advertising router. If the Prefix
Attribute Flags sub-TLV is included both the X-Flag and the R-Flag
are set to 0.
L1->L2 inter-area routes: These are advertised in L2 LSPs, in TLV 135
or TLV 235. The up/down bit is set to 0. These IP prefixes are
learned via L1 routing and were derived during the L1 Shortest Path
First (SPF) computation from prefixes advertised in L1 LSPs in TLV
135 or TLV 235. If the Prefix Attribute Flags sub-TLV is included
the R-Flag is set to 1.
L2->L2 inter-area routes: These are advertised in L2 LSPs, in TLV 135
or TLV 235. The up/down bit is set to 1 but is ignored and treated
as if it were set to 0. These IP prefixes are learned from another
IS-IS instance usually operating in another area. If the Prefix
Attribute Flags sub-TLV is included the X-Flag is set to 1 and the
R-Flag is set to 0.
L2 external routes: These are advertised in L2 LSPs, in TLV 135 or
TLV 235. The up/down bit is set to 0. These IP prefixes are learned
from other protocols and are usually not directly connected to the
advertising router. If the Prefix Attribute Flags sub-TLV is
included the X-Flag is set to 1 and the R-Flag is set to 0.
L2->L1 inter-area routes: These are advertised in L1 LSPs, in TLV 135
or TLV 235. The up/down bit is set to 1. These IP prefixes are
learned via L2 routing and were derived during the L2 SPF computation
from prefixes advertised in TLV 135 or TLV 235. If the Prefix
Attribute Flags sub-TLV is included the R-Flag is set to 1.
L1->L1 inter-area routes: These are advertised in L1 LSPs, in TLV 135
or TLV 235. The up/down bit is set to 1. These IP prefixes are
learned from another IS-IS instance usually operating in another
area. If the Prefix Attribute Flags sub-TLV is included the X-Flag
is set to 1 and the R-Flag is set to 0.
3.2. Types of Routes Supported by TLVs 236 and 237
This section defines the types of route supported for IPv6 when using
TLV 236 [RFC5308] and/or TLV 237 [RFC5120].
L1 intra-area routes: These are advertised in L1 LSPs, in TLV 236 or
TLV 237. The up/down bit is set to 0. The external bit is set to 0.
These IPv6 prefixes are directly connected to the advertising router.
If the Prefix Attribute Flags sub-TLV is included the R-Flag is set
to 0.
Ginsberg, et al. Expires April 18, 2016 [Page 5]
Internet-Draft isis-route-preference October 2015
L1 external routes: These are advertised in L1 LSPs, in TLV 236 or
TLV 237. The up/down bit is set to 0. The external bit is set to 1.
These IPv6 prefixes are learned from other protocols and are usually
not directly connected to the advertising router. If the Prefix
Attribute Flags sub-TLV is included the R-Flag is set to 0.
L2 intra-area routes: These are advertised in L2 LSPs, in TLV 236 or
TLV 237. The up/down bit is set to 0. The external bit is set to 0.
These IPv6 prefixes are directly connected to the advertising router.
If the Prefix Attribute Flags sub-TLV is included the R-Flag is set
to 0.
L1->L2 inter-area routes: These are advertised in L2 LSPs, in TLV 236
or TLV 237. The up/down bit is set to 0. The external bit is set to
0. These IPv6 prefixes are learned via L1 routing and were derived
during the L1 Shortest Path First (SPF) computation from prefixes
advertised in L1 LSPs in TLV 236 or TLV 237. If the Prefix Attribute
Flags sub-TLV is included the R-Flag is set to 1.
L2 external routes: These are advertised in L2 LSPs, in TLV 236 or
TLV 237. The up/down bit is set to 0. the external bit is set to 1.
These IPv6 prefixes are learned from other protocols and are usually
not directly connected to the advertising router. If the Prefix
Attribute Flags sub-TLV is included the R-Flag is set to 0.
L1->L2 external routes: These are advertised in L2 LSPs, in TLV 236
or TLV 237. The up/down bit is set to 0. The external bit is set to
1. These IPv6 prefixes are learned via L1 routing and were derived
during the L1 Shortest Path First (SPF) computation from L1 external
routes advertised in L1 LSPs in TLV 236 or TLV 237. If the Prefix
Attribute Flags sub-TLV is included the R-Flag is set to 1.
L2->L2 inter-area routes. These are advertised in L2 LSPs, in TLV
236 or TLV 237. The up/down bit is set to 1 but is ignored and
treated as if it were set to 0. The external bit is set to 1. These
IP prefixes are learned from another IS-IS instance usually operating
in another area. If the Prefix Attribute Flags sub-TLV is included
the R-Flag is set to 0.
L2->L1 inter-area routes: These are advertised in L1 LSPs, in TLV 236
or TLV 237. The up/down bit is set to 1. The external bit is set to
0. These IPv6 prefixes are learned via L2 routing and were derived
during the L2 SPF computation from prefixes advertised in TLV 236 or
TLV 237. If the Prefix Attribute Flags sub-TLV is included the
R-Flag is set to 1.
L2->L1 external routes: These are advertised in L1 LSPs, in TLV 236
or TLV 237. The up/down bit is set to 1. The external bit is set to
Ginsberg, et al. Expires April 18, 2016 [Page 6]
Internet-Draft isis-route-preference October 2015
1. These IPv6 prefixes are learned via L2 routing and were derived
during the L2 SPF computation from prefixes advertised in TLV 236 or
TLV 237. If the Prefix Attribute Flags sub-TLV is included the
R-Flag is set to 1.
L1->L1 inter-area routes. These are advertised in L1 LSPs, in TLV
236 or TLV 237. The up/down bit is set to 1. The external bit is
set to 1. These IP prefixes are learned from another IS-IS instance
usually operating in another area. If the Prefix Attribute Flags
sub-TLV is included the R-Flag is set to 0.
3.3. Order of Preference for all types of routes supported by TLVs 135
and 235
This document defines the following route preferences for IPv4 routes
advertised in TLVs 135 or 235. Note that all types of routes listed
for a given preference are treated equally.
1. L1 intra-area routes; L1 external routes
2. L2 intra-area routes; L2 external routes; L1->L2 inter-area
routes; L2-L2 inter-area routes
3. L2->L1 inter-area routes; L1->L1 inter-area routes
3.4. Order of Preference for all types of routes supported by TLVs 236
and 237
This document defines the following route preferences for IPv6 routes
advertised in TLVs 236 or 237. Note that all types of routes listed
for a given preference are treated equally.
1. L1 intra-area routes; L1 external routes
2. L2 intra-area routes; L2 external routes; L1->L2 inter-area
routes; L1-L2 external routes;L2-L2 inter-area routes
3. L2->L1 inter-area routes; L2->L1 external routes;L1->L1 inter-
area routes
4. IANA Considerations
No IANA actions required.
Ginsberg, et al. Expires April 18, 2016 [Page 7]
Internet-Draft isis-route-preference October 2015
5. Security Considerations
None.
6. Acknowledgements
The authors wish to thank Ahmed Bashandy for his insightful review.
7. References
7.1. 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,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<http://www.rfc-editor.org/info/rfc5120>.
[RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix
Distribution with Two-Level IS-IS", RFC 5302,
DOI 10.17487/RFC5302, October 2008,
<http://www.rfc-editor.org/info/rfc5302>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
DOI 10.17487/RFC5308, October 2008,
<http://www.rfc-editor.org/info/rfc5308>.
7.2. Informational References
[PFXATTR] "IS-IS Prefix Attributes, draft-ietf-isis-prefix-
attributes-01(work in progress)", June 2015.
Appendix A. Example Interoperability Issue
This documents a real world interoperability issue which occurs
because implementations from different vendors have interpreted the
use of the up/down bit in Level 2 LSPs inconsistently.
Ginsberg, et al. Expires April 18, 2016 [Page 8]
Internet-Draft isis-route-preference October 2015
L2 L2 L2 L2|L2 L2
10/8 - R0 ----- R1 ----- R2 ----- R3 ----- R4 ---- 10/8
|
Figure 1
Considering Figure 1, both R0 and R4 are advertising the prefix 10/8.
Two ISIS Level 2 instances are running on R3 to separate the network
into two areas. R3 is performing route-leaking and advertises
prefixes from R4 to the other Level 2 process. The network is using
extended metrics (TLV135 defined in [RFC5305]). R0 is advertising
10/8 with metric 2000 and R3 advertises 10/8 with metric 100. All
links have a metric of 1. When advertising 10/8 in its Level 2 LSP,
R3 sets the down bit as specified in [RFC5305].
R1, R2 and R3 are from three different vendors (R1->Vendor1,
R2->Vendor2, R3->Vendor3). During interoperability testing, routing
loops are observed in this scenario.
o R2 has two possible paths to reach 10/8, Level 2 route with metric
2002, up/down bit is 0 (from R0) and Level 2 route with metric
101, up/down bit is 1 (from R3). R2 selects R1 as nexthop to 10/8
because it prefers the route which does NOT have up/down bit set.
o R3 has two possible paths to reach 10/8, Level 2 route with metric
2003, up/down bit is 0 (from R0) and Level 2 route with metric
101, up/down bit is 0 (from R4). R3 selects R4 as nexthop due to
lowest metric.
o R1 has two possible paths to reach 10/8, Level 2 route with metric
2001, up/down bit is 0 (from R0) and Level 2 metric 102, up/down
bit is 1 (from R3). 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.
Authors' Addresses
Les Ginsberg
Cisco Systems
510 McCarthy Blvd.
Milpitas, CA 95035
USA
Email: ginsberg@cisco.com
Ginsberg, et al. Expires April 18, 2016 [Page 9]
Internet-Draft isis-route-preference October 2015
Stephane Litkowski
Orange Business Service
Email: stephane.litkowski@orange.com
Stefano Previdi
Cisco Systems
Via Del Serafico 200
Rome 0144
Italy
Email: sprevidi@cisco.com
Ginsberg, et al. Expires April 18, 2016 [Page 10]
