One document matched: draft-ginsberg-isis-route-preference-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ginsberg-isis-route-preference-00.txt"
ipr="pre5378Trust200902">
<front>
<title abbrev="draft-ginsberg-isis-route-preference-00.txt">IS-IS Route
Preference for Extended IP and IPv6 Reachability</title>
<author fullname="Les Ginsberg" initials="L" surname="Ginsberg">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>510 McCarthy Blvd.</street>
<city>Milpitas</city>
<code>95035</code>
<region>CA</region>
<country>USA</country>
</postal>
<email>ginsberg@cisco.com</email>
</address>
</author>
<author fullname="Stephane Litkowski" initials="S" surname="Litkowski">
<organization>Orange Business Service</organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country/>
</postal>
<email>stephane.litkowski@orange.com</email>
</address>
</author>
<author fullname="Stefano Previdi" initials="S" surname="Previdi">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Via Del Serafico 200</street>
<city>Rome</city>
<code>0144</code>
<country>Italy</country>
</postal>
<email>sprevidi@cisco.com</email>
</address>
</author>
<date day="02" month="July" year="2014"/>
<area>Routing Area</area>
<workgroup>Networking Working Group</workgroup>
<keyword>Sample</keyword>
<abstract>
<t>Existing specifications as regards route preference are not explicit
when applied to IP/IPv6 Extended Reachability 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 LSPs.
This document addresses these issues.</t>
</abstract>
<note title="Requirements Language">
<t>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].</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>[RFC5302] defines the route preferences rules as they apply to
Type/Length/Value(TLV)s 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 Link State
Protocol Data Units(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.</t>
</section>
<section title="Use of the up/down Bit in Level 2 LSPs">
<t>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:</t>
<t>"...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."</t>
<t>[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:</t>
<t>"If a prefix is advertised from one area to another at the same
level, then the up/down bit SHALL be set to 1."</t>
<t>However, the statement in [RFC5302] that the up/down bit is ignored
in Level 2 LSPs is not altered by [RFC5305].</t>
<t>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.</t>
</section>
<section title="Types of Routes in IS-IS Supported by Extended Reachability TLVs">
<t>[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. It is therefore useful to explicitly state the
supported route types for these TLVs.</t>
<section title="Types of Routes Supported by TLVs 135 and 235">
<t>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].</t>
<t>L1 intra-area routes: These are advertised in L1 LSPs, in TLV 135
or TLV 235. The up/down bit is set to zero. These IP prefixes are
directly connected to the advertising router. These routes are
indistinguishable from L1 external routes.</t>
<t>L1 external routes: These are advertised in L1 LSPs, in TLV 135 or
TLV 235. The up/down bit is set to zero. These IP prefixes are learned
from other protocols and are usually not directly connected to the
advertising router. These routes are indistinguishable from L1
intra-area routes.</t>
<t>L2 intra-area routes: These are advertised in L2 LSPs, in TLV 135
or TLV 235. The up/down bit is set to zero. These IP prefixes are
directly connected to the advertising router. These prefixes cannot be
distinguished from L1->L2 inter-area routes and/or L2 external
routes.</t>
<t>L1->L2 inter-area routes: These are advertised in L2 LSPs, in
TLV 135 or TLV 235. The up/down bit is set to zero. 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. These prefixes cannot be distinguished from L2
intra-area routes and/or L2 external routes.</t>
<t>L2 external routes: These are advertised in L2 LSPs, in TLV 135 or
TLV 235. The up/down bit is set to zero. These IP prefixes are learned
from other protocols and are usually not directly connected to the
advertising router. These routes are indistinguishable from L2
intra-area routes and/or L1->l2 inter-area routes.</t>
<t>L2->L1 inter-area routes: These are advertised in L1 LSPs, in
TLV 135 or TLV 235. The up/down bit is set to one. 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. These
routes are indistinguishable from L1->L1 inter-area routes.</t>
<t>L1->L1 inter-area routes: These are advertised in L1 LSPs, in
TLV 135 or TLV 235. The up/down bit is set to one. These IP prefixes
are learned from another IS-IS instance operating in another area.
These routes are indistinguishable from L2->L1 inter-area
routes.</t>
<t>L2->L2 inter-area routes: These are advertised in L2 LSPs, in
TLV 135 or TLV 235. The up/down bit is set to one but is ignored and
treated as if it were set to 0. These IP prefixes are learned from
another IS-IS instance operating in another area.</t>
</section>
<section title="Types of Routes Supported by TLVs 236 and 237">
<t>This section defines the types of route supported for IPv6 when
using TLV 236 [RFC5308] and/or TLV 237 [RFC5120].</t>
<t>L1 intra-area routes: These are advertised in L1 LSPs, in TLV 236
or TLV 237. The up/down bit is set to zero. The eXternal bit is set to
0. These IPv6 prefixes are directly connected to the advertising
router.</t>
<t>L1 external routes: These are advertised in L1 LSPs, in TLV 236 or
TLV 237. The up/down bit is set to zero. 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.</t>
<t>L2 intra-area routes: These are advertised in L2 LSPs, in TLV 236
or TLV 237. The up/down bit is set to zero. The eXternal bit is set to
0. These IPv6 prefixes are directly connected to the advertising
router. These prefixes cannot be distinguished from L1->L2 inter-
area routes.</t>
<t>L1->L2 inter-area routes: These are advertised in L2 LSPs, in
TLV 236 or TLV 237. The up/down bit is set to zero. 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. These prefixes
cannot be distinguished from L2 intra-area routes.</t>
<t>L2 external routes: These are advertised in L2 LSPs, in TLV 236 or
TLV 237. The up/down bit is set to zero. 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.</t>
<t>L1->L2 external routes: These are advertised in L2 LSPs, in TLV
236 or TLV 237. The up/down bit is set to zero. 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. These
prefixes cannot be distinguished from L2 external routes.</t>
<t>L2->L1 inter-area routes: These are advertised in L1 LSPs, in
TLV 236 or TLV 237. The up/down bit is set to one. 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. These routes are indistinguishable from L1->L1
inter-area routes.</t>
<t>L2->L1 external routes: These are advertised in L1 LSPs, in TLV
236 or TLV 237. The up/down bit is set to one. The eXternal bit is set
to 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.</t>
<t>L1->L1 inter-area routes. These are advertised in L1 LSPs, in
TLV 236 or TLV 237. The up/down bit is set to one. The eXternal bit is
set to 0. These IP prefixes are learned from another IS-IS instance
operating in another area. These routes are indistinguishable from
L2->L1 inter-area routes.</t>
<t>L2->L2 inter-area routes. These are advertised in L2 LSPs, in
TLV 236 or TLV 237. The up/down bit is set to one but is ignored and
treated as if it were set to 0. The eXternal bit is set to 0. These IP
prefixes are learned from another IS-IS instance operating in another
area.</t>
</section>
<section title="Order of Preference for all types of routes supported by TLVs 135 and 235">
<t>This document defines the following route preferences for IPv4
routes advertised in TLVs 135 or 235.</t>
<t>1. L1 intra-area routes; L1 external routes</t>
<t>2. L2 intra-area routes; L2 external routes; L1->L2 inter-area
routes; L2-L2 inter-area routes</t>
<t>3. L2->L1 inter-area routes; L1->L1 inter-area routes</t>
</section>
<section title="Order of Preference for all types of routes supported by TLVs 236 and 237">
<t>This document defines the following route preferences for IPv6
routes advertised in TLVs 236 or 237.</t>
<t>1. L1 intra-area routes; L1 external routes</t>
<t>2. L2 intra-area routes; L2 external routes; L1->L2 inter-area
routes; L1-L2 external routes;L2-L2 inter-area routes</t>
<t>3. L2->L1 inter-area routes; L2->L1 external routes;L1->L1
inter-area routes</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>No IANA actions required.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>None.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>TBD</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.5302'?>
<?rfc include='reference.RFC.5305'?>
<?rfc include='reference.RFC.5308'?>
<?rfc include='reference.RFC.5120'?>
</references>
<section title="Example Interoperability Issue">
<t>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.</t>
<figure>
<artwork><![CDATA[
L2 L2 L2 L2|L2 L2
10/8 - R0 ----- R1 ----- R2 ----- R3 ----- R4 ---- 10/8
|
Figure 1
]]></artwork>
</figure>
<t>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].</t>
<t>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.</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>When R1 or R2 try to send traffic to 10/8, packets are looping due to
inconsistent routing decision between R1 and R2.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:50:50 |